Link preview privacy matters because a pasted URL can make a private chat talk to the outside web before anyone taps the link. The message body may be end to end encrypted, but a preview system still has to fetch metadata, images, titles, or oEmbed data from somewhere. The practical question is simple: who fetches the URL, what does the website see, what does the messenger operator learn, and can the user stop the preview before it becomes a record? That is the test I use for UmbrellaX.
Most people think of previews as small convenience cards. I do not. I see them as a metadata feature with a nice face. A preview can expose timing, IP address, URL paths, private document links, website interest, cache state, and sometimes content that was meant only for the sender and recipient.
I am building UmbrellaX so small convenience features do not quietly undo the larger privacy model. Link previews are a good example because the feature looks harmless until you trace the network path.
The answer first
Link preview privacy is not about whether preview cards are useful. They are useful. It is about whether a messenger generates those cards without creating a second disclosure channel. A private messenger should avoid fetching previews on the recipient’s device before consent, should avoid sending private URLs to an operator-readable preview server, should hide the sender’s IP from the previewed website where possible, should fetch only the minimum metadata needed, should limit preview caching, and should let the sender remove the preview before sending.
My UmbrellaX rule is that a link preview must be treated like message-adjacent metadata. If the product cannot explain the fetch path in one plain paragraph, the default should be off or ask first. I would rather ship a quieter preview feature than let a pretty card tell an outside website what a private room is discussing.
Why link previews are different from notification previews
A notification preview exposes information on the lock screen or through Apple and Google push paths. I wrote about that separately in push notification privacy. A link preview has a different leak shape.
The link preview happens because the app wants context for a URL. To build the card, something has to inspect the link. That “something” might be the sender’s phone, the recipient’s phone, the messenger’s server, a proxy, or a third-party unfurling service. Each choice moves risk.
If the sender’s device fetches the preview directly, the website can see the sender’s IP address and timing. If the recipient’s device fetches it automatically, a hostile sender can learn something about the recipient before the recipient taps anything. If the messenger server fetches it, the operator may learn the URL or cache content from a private chat.
None of those outcomes are the same as “message text is not encrypted.” The message can remain encrypted while the preview still leaks the surrounding facts.
The three preview models I actually care about
When I evaluate messaging app link previews, I ignore the screenshot first and ask how the preview is generated.
| Preview model | Privacy risk | My view |
|---|---|---|
| Sender device fetches the preview | The previewed website may see sender IP, timing, and interest. | Acceptable only with clear user control and sensitive-link warnings. |
| Recipient device fetches automatically | A sender can cause a receiver-side network request without a tap. | I would reject this as a default for a private messenger. |
| Server or proxy fetches the preview | The operator or proxy path may see the URL, cache data, or fetch too much. | Acceptable only if the design hides URLs from the operator or keeps retention very narrow. |
Signal’s public writeup is useful because it shows a privacy-aware direction: optional previews, HTTPS-only support, IP shielding through a proxy, and constraints around what the service can see. Mysk’s research is useful for the opposite reason: it shows how the same feature can leak IP addresses, send links from encrypted chats to servers, or make preview servers download far more data than a user expects.
My takeaway is not “all previews are bad.” My takeaway is that previews are a protocol surface. Treating them as pure UI is how the leak starts.
Open Graph makes the feature easy and tempting
Open Graph metadata is one reason link previews spread everywhere. A web page can expose title, description, image, and other structured fields so another product can render a rich card. Slack’s robot documentation is a clear example from the business-chat world: link-expanding robots fetch pages, look for oEmbed, Twitter Card, and Open Graph data, then cache responses for a short period.
That is a reasonable product feature in many work contexts. It is also a reminder that link preview generation is crawling on behalf of a user action.
Private messengers have a stricter job. A business collaboration tool can decide that workspace convenience is worth predictable unfurling. A privacy-first messenger should start from the opposite question: what is the minimum outside contact needed to help the user understand a link?
For UmbrellaX, I would rather make previews smaller and more deliberate than inherit every social-media convention around rich cards. If a link points to a private file, a health portal, a legal document, a political article, or a server controlled by an adversary, the preview is not decoration. It is evidence.
What I would not trust
I would not trust a messenger that says “end to end encrypted” and then quietly sends every pasted URL to a server for preview generation.
I would not trust receiver-side automatic previews for sensitive rooms. A malicious sender should not be able to drop a tracking URL into a chat and make the recipient’s device fetch it before the recipient has chosen to open it.
I would not trust unlimited preview downloads. A preview needs a title, small image, and a few metadata fields. It does not need a whole document, a video file, a large archive, or unbounded JavaScript execution.
I would not trust vague cache language. If a service caches previews, it should say what is cached, for how long, under which key, and whether the cached object can connect back to the chat, account, phone number, device, or IP address.
And I would not trust a design where a phone number becomes part of the preview record. I wrote the broader identity case in messenger without phone number, but previews make the point concrete: a URL interest signal is more dangerous when it is attached to a telecom identifier.
How UmbrellaX should handle the tradeoff
UmbrellaX is pre-launch, so I am not going to pretend there is production evidence yet. What I can state is the design bar I am willing to build against.
My preferred default is conservative:
- Do not generate a rich preview until the sender chooses to keep it.
- Never make the recipient fetch a link automatically before a tap.
- Prefer a privacy-preserving proxy for supported preview fetches.
- Fetch only small metadata and image ranges needed for the card.
- Strip query parameters where doing so does not change the destination meaning.
- Keep cache lifetimes short and unlinkable from account identity.
- Make preview disablement easy, not buried.
There are real tradeoffs here. A proxy can hide the user from the website, but now the proxy has to be designed carefully. Client-side fetching can keep the operator out of the URL, but it may expose the sender to the website. Turning previews off is clean, but users lose useful context and may tap more dangerous links because they cannot inspect them.
My rule is to keep the power visible. The product should tell the user what happens before a preview appears. A private messenger should not require reverse engineering for that answer.
Link previews and operator knowledge
The broader topic is private messenger metadata. Link previews are one small but useful test case inside it.
If the operator learns that a user pasted a URL, the exact URL path, the time it happened, whether the preview was generated, whether the link was in a group, and which cache object was returned, the operator has learned facts around the conversation without reading the message body. Those facts may be low risk for ordinary links. They may be high risk for legal help pages, medical portals, whistleblowing forms, blocked media, or private cloud documents.
I do not promise zero metadata for UmbrellaX. That would be fake certainty. I do want metadata to be deliberate. If a field exists, I want a reason. If a cache exists, I want a limit. If a proxy exists, I want it designed as privacy infrastructure rather than convenience infrastructure.
That is also why link previews belong near messaging app permissions and photo metadata privacy in the cluster. All three are small edges where a user can think the chat is private while a nearby feature creates a different exposure path.
The practical test before trusting a messenger
Here is the question I would ask any messenger before I enabled link previews in a sensitive chat:
- Are previews optional at the account and per-message level?
- Does the recipient ever fetch a preview before tapping?
- Does the operator ever receive the full URL?
- Are query strings, tokens, and private document links handled differently?
- Are preview images and metadata size-limited?
- Is JavaScript from the previewed site blocked?
- How long are preview results cached?
- Can preview events be linked to account identity, phone number, group, or IP address?
If the product cannot answer those questions, I would not use previews for sensitive links. I might still use the messenger. I would just treat that feature as outside the trust boundary.
For UmbrellaX, I want the answer to be boring and inspectable: previews are controlled by the user, fetched through a narrow path, minimized before storage, separated from phone-number identity, and documented in the privacy policy as part of the product’s metadata posture.
Bottom line
Link previews are not harmless just because they are small. They are a network request, a metadata parser, a cache object, and a product default wrapped in a friendly card.
The safest private messenger is not the one that removes every useful feature. It is the one that knows which features create outside signals and designs them with restraint.
My UmbrellaX position is straightforward: keep previews optional, never let a recipient be tracked before a tap, avoid operator-readable URL collection, limit cached preview material, and treat every preview event as part of the metadata budget. That is how a private messenger earns the right to make convenience feel normal.
Sources
- Signal: I link therefore I am official
- Mysk: Link Previews: How a Simple Feature Can Have Privacy and Security Risks research
- Open Graph protocol official
- Slack API: Slack Robots official
- IETF RFC 6973: Privacy Considerations for Internet Protocols official
- UmbrellaX privacy policy official