Pasting a link into a private conversation can cause another system to fetch a public page. The card that appears beneath the message has to come from somewhere: a title, an image and a description are retrieved or supplied. The privacy question is who performs that retrieval, when it happens and what the destination can observe.
Follow the fetch, not just the finished card
Imagine a synthetic link created for an authorised test. Its destination records requests without identifying real visitors. The sender pastes it into a draft but does not press Send. If a request arrives at that point, it belongs to the drafting workflow. A request arriving only when the recipient opens the conversation belongs to a different workflow. The distinction matters even if both interfaces eventually display the same picture.
Several designs are possible. A sending client might retrieve the material and include a prepared card in the encrypted message. A service might fetch it. A receiving client might load an external image. This article does not assert which path UseCrypt or any other application uses. Each path creates different parties, logs and timing to examine.
HTTPS does not hide a request from its destination
A server receiving a request can handle the requested resource and the information the requester actually supplies. That does not mean it necessarily sees the recipient’s address: a proxy or another component may be the requester. Nor does it mean that generating a preview reveals the surrounding private conversation.
The MDN reference for the HTTP Referer header explains that a request can include information about the referring resource, subject to referrer policy. It does not establish that a messenger sends this header, or that every request includes a complete originating URL. A test must inspect actual behaviour rather than importing assumptions from ordinary web browsing.
A switch needs a precise meaning
Signal’s current link-preview help page says sending previews is optional, describes a setting that synchronises to linked devices and allows removal of an individual preview before sending. This is evidence about the documented control. The help page does not, by itself, specify the complete network architecture behind it.
For any application, ask whether “disable previews” stops generation, display or both. Does removing a card cancel a fetch that already happened? Does a linked desktop follow the same setting? A user-facing control can be useful while still needing those operational details. The right answer is the measured behaviour of the identified version, not a conclusion from the label.
Message encryption and preview retrieval need separate evidence
The existing UseCrypt Messenger explanation of local data and keys covers a different boundary: protection of stored conversation records. It does not document the origin of link-preview requests. Linking to that explanation provides context without pretending it answers a question outside its source material.
This distinction also prevents an exaggerated security finding. Observing a request for a public page is not evidence that a service can decrypt all messages. Conversely, encrypted message transport is not evidence that the destination receives no request when a draft is composed. Both statements require their own observation.
Use a harmless destination and a written expectation
A controlled test can distinguish pasting, sending, receiving and opening the destination. Use unique test URLs for those steps so cached results do not disguise a later fetch. Compare preview-enabled and preview-disabled states, then repeat on a linked device where the product supports one. Do not send a tracking link to an unsuspecting person.
Publish the outcome with the app version, settings, observation point and limits. If a request passed through infrastructure the tester could not identify, say so. A useful privacy explanation follows the request far enough to define the boundary, without turning an unknown into either a guarantee or an accusation.
