Telemetry Exposure of Secret Links: How Analytics Observe URL Fragments

Abstract

Client-side-encrypted file sharing relies on a simple convention: the link that opens a file carries the decryption key in its URL fragment - the portion after the # that browsers never transmit to a server. This keeps the key away from the host. It does not, however, keep the key away from code running inside the page. We built a model share page and ran a single representative secret link through a synthetic matrix of 18 common web telemetry configurations, instrumenting a passive sink to record exactly what each configuration transmitted. 17 of 18 setups captured the link path (the file identifier), and 9 of 18 transmitted the URL fragment - placing the decryption key into an analytics endpoint. The only configuration that leaked nothing was the one that ran no telemetry on the page at all. We describe the conditions that cause a secret link to leak and the design constraints that prevent it.

Background

A share link of the form host/f/<id>#<key> splits cleanly in two. The <id> is sent to the server so it can return the correct encrypted object. The <key> sits in the fragment, which by long-standing browser behaviour is never included in the HTTP request. That is what makes the pattern zero-knowledge with respect to the server: the host stores ciphertext and never receives the material that decrypts it.

The property that protects the key from the server says nothing about the page. Any script executing in the document can read location.hash and the full address. The most widely deployed category of in-page script is telemetry: analytics page-view trackers, tag managers, advertising and measurement pixels, and session-replay tools. Each of these, in its default form, is built to observe and report on what a visitor does - including what page they are on. When the page is a share or download page, “what page they are on” is a secret.

The Challenge

We wanted an empirical answer to a narrow question: given a page whose URL contains a secret fragment, how often does commonly deployed telemetry capture and transmit that fragment off the device? The difficulty is that telemetry behaviour varies widely. Some trackers report only a normalised path; some report the full location; some are explicitly configured to follow hash-based navigation; replay tools may record the address bar verbatim as part of the session. Rather than test named products, we modelled the behaviour as a matrix of configuration families and measured each one against the same input.

Methodology

We constructed a static model share page and assigned it a single synthetic secret link with a clearly recognisable identifier and fragment, so that any leakage would be unambiguous to detect in transit. We then applied, one at a time, 18 telemetry configurations grouped into six families that approximate how real sites are instrumented:

• Basic page-view auto-tracking - a standard snippet that reports a page view on load.
• Hash- and route-aware tracking - configurations tuned for single-page apps that treat fragment changes as navigation.
• Tag-manager default templates - container setups using off-the-shelf page-view tags.
• Custom URL and manual events - hand-written events that pass a location value the author chose.
• Advertising and measurement pixels - third-party tags whose primary job is attribution.
• Session-replay and heatmap scripts - tools that record page state and interaction.

Every configuration sent its traffic to a passive sink under our control that logged, but never acted on, the payloads it received. For each run we recorded two outcomes: whether the link path appeared in any outbound payload, and whether the fragment did. All inputs were synthetic. No real share link, file, or person was involved at any point.

Results

Across the 18 configurations, capturing the link path was close to universal: a tracker that reports a page view generally reports the path it sees. Capturing the fragment was less universal but far from rare - it happened in half of the configurations, and in every one of those cases the synthetic key reached our sink intact.

Capture by Telemetry Family

Telemetry Family	Configs	Captured Path	Captured Fragment	Key Reached Endpoint
Basic page-view auto-tracking	4	4 / 4	1 / 4	yes
Hash- / route-aware tracking	3	3 / 3	3 / 3	yes
Tag-manager default templates	3	3 / 3	1 / 3	yes
Custom URL / manual events	3	3 / 3	2 / 3	yes
Advertising / measurement pixels	3	2 / 3	0 / 3	no
Session-replay / heatmap	2	2 / 2	2 / 2	yes

The Quieter Path: Referrers

Telemetry is the loud failure mode; the referrer is the quiet one. When a visitor navigates from a share page to another destination, the browser may pass along the page they came from. The fragment is stripped from a referrer automatically, so the key is not exposed this way - but the path, and with it the file identifier, can be. In our navigation tests, the link path appeared in the referrer of the destination whenever the source page used a permissive referrer policy. Declaring a strict no-referrer policy on the share page removed the path from the referrer in every case.

Implications for PrivDrop

These results define three constraints that any leak-free sharing surface must satisfy, and that PrivDrop is built to meet:

• No telemetry on secret-bearing pages. The share and download surfaces carry no analytics, advertising, replay, or other third-party scripts. The control configuration was the only one that leaked nothing, so it is the only configuration we ship.
• Key in the fragment. The decryption key remains in the URL fragment, so it never reaches the server in the first place.
• Strict referrer policy. The service sends no-referrer, so neither the path nor anything else follows a recipient to the next site they visit.

For a plain-language version of the same ideas, see the blog post How File-Sharing Links Quietly Leak Through Analytics.

Limitations

This study measures transmission behaviour, not vendor intent, and it groups a fast-moving landscape into a finite set of families; real deployments mix and reconfigure these, and defaults shift over time. The matrix is representative rather than exhaustive, and a configuration we did not model could behave differently. The work also addresses only the in-page and referrer exposure of links - it does not evaluate server-side logging, network-level observation, or the cryptography of any particular sharing scheme, which are treated separately. The conclusion we stand behind is narrow and robust: if a page can carry a secret in its URL, the safest amount of telemetry on that page is none.