Why previews are a privacy concern

Fetching a link preview creates a network request that reveals the sender’s IP, the URL being shared, and the timing. Signal mitigates this in two ways: previews are disabled by default, and all requests go through a privacy proxy.

The privacy proxy

All preview requests are routed through a TLS privacy proxy. The connection is encrypted end-to-end from the sender’s device to your server, so the proxy itself can’t read the content. Your server sees the proxy’s IP, not the sender’s.

In practice:

• Your server can’t identify the sender, since you see proxy IPs, not user IPs
• The proxy can’t see what’s being fetched because TLS prevents content inspection
• Link tracking pixels are less effective because IP and timing data is masked

Impact on analytics

Signal preview requests all come from proxy IPs with the user agent WhatsApp/2. You can count total Signal preview fetches, but you can’t segment by user, device, or location.

Impact on rate limiting

Many Signal users share the same proxy IPs. Aggressive per-IP rate limiting can block legitimate preview requests. Consider whitelisting the WhatsApp/2 user agent or applying higher thresholds for it.

Geo-blocking and IP reputation services may also flag proxy IPs as suspicious due to high request volumes from a single address.

Link tracking

Preview fetches aren’t clicks. They happen automatically when the URL is pasted, before the message is sent. Tracking services that rely on the viewer’s IP will record the proxy’s IP instead. Signal preview traffic will skew your click analytics.

The WhatsApp/2 masquerade

Signal uses WhatsApp/2 specifically to avoid differential treatment. If servers blocked a Signal user agent, it would harm the user experience. Using the WhatsApp agent ensures Signal users get the same responses as WhatsApp users.