A link preview can trigger a network request before you click; but who sends that request and what the destination site sees depends on the messenger’s design. A thumbnail in a chat does not establish that both the sender’s and recipient’s IP addresses have been exposed.
End-to-end encryption protects the message along its path between the participants in a conversation. Fetching a website’s title and image follows a separate path and must be assessed separately.
Three different ways to build a preview
| Method | What does the destination site see? | Key question |
|---|---|---|
| Direct fetching by the device | The requesting connection’s IP and information accompanying the request | Does the request occur while typing, sending, or receiving? |
| Fetching through an intermediary or proxy | Usually the intermediary’s IP rather than the user’s direct IP | What does the intermediary itself see and retain? |
| The sender creates the preview and sends it in the message | The recipient may not connect to the destination to display the card | Are the images in the card local, or fetched from the web again? |
These methods can be combined. For example, Signal described using a proxy for previews in its 2019 technical explanation. This document is an example of a design; it should not be generalized to all versions or all apps without checking. Signal’s current guide explains how to disable preview generation and remove a card before sending.
An IP, a link identifier, and an identity are not the same thing
The destination site sees the IP of the party establishing the network connection; this may be a device, VPN, or proxy. An IP alone is usually not a person’s name or precise home address, but together with request timing and other data it can be used to correlate events.
A link with a unique identifier may also show that the particular URL was requested. That observation alone does not prove who read it: the request could come from a preview, a security tool, the sender, the recipient, or someone to whom the link was forwarded.
An IP address is not necessarily a field within HTTP, either; it is part of the network communication. The types and values of headers such as User-Agent depend on the requesting software.
Fetching a page title differs from fully executing the page
Some previews only fetch and process HTML and images. This does not necessarily mean executing JavaScript or opening the page in a browser. By contrast, preloading or displaying a page in a web environment can behave differently.
Ask two separate questions: “Is a request sent to the site?” and “Is the page’s active content executed?” The answer to one does not determine the answer to the other.
Practical settings for sensitive conversations
- If you do not need a preview card, check the app’s automatic preview setting. Removing a card after it has been generated does not undo the earlier request.
- Treat unknown links and personalized login, recovery, or file-sharing links as sensitive data. Do not submit them to public URL-analysis services for testing.
- Do not arbitrarily remove parameters from a signed link; you may break its access or validity. Where possible, obtain a public, non-personalized version of the page from the original source.
- Do not confuse disabling previews with preventing all network connections. Opening links, external images, and other features each have their own paths.
- For an organizational assessment, use a harmless URL under your control and a test device to check when requests are generated; do not generalize results from one version to every device.
What can be said about Livara?
Livara’s threat model explains the boundaries of private-content protection and device and network limitations. This general explanation does not establish that every preview in every version necessarily uses either a direct connection or a proxy. Such a claim requires documentation of the feature or examination of that particular version.
For link privacy, the request’s path matters more than the appearance of the preview card.
