How File-Sharing Links Quietly Leak Through Analytics

When you share a file through a privacy-focused tool, the link is the password. Anyone who has it can open the file, and in the better tools the key that decrypts the file is baked right into the link. That design is a good thing - it is what lets a service host your file without ever being able to read it. But it raises a question almost nobody asks: once you create that link, who else gets to see it?

On a surprising number of file-sharing sites, the answer is “whatever analytics the site happens to run.” The link people think is private quietly ends up in a tracking dashboard - and sometimes the secret key comes along for the ride. This is not usually the result of anyone trying to spy on you. It is almost always an accident of default settings. Let's walk through how it happens, and what a design that can't leak looks like.

Where the secret actually lives

A modern share link has more structure than it looks. Take a link like drop.example.com/f/AbC123#KEY. The part before the # tells the server which file you want. The part after the # - called the fragment - is special: browsers never send it to the web server. It stays in your browser.

That single rule is the foundation of zero-knowledge sharing. Privacy-first tools put the decryption key in the fragment precisely because the server hosting your file never receives it. The server can hand over an encrypted blob, but it never sees the key, so it can never decrypt your file. Good so far.

How the link leaks anyway

Here's the catch. The server may never see the fragment - but any JavaScript running inside the page can read the whole address, fragment included. And the most common JavaScript on the average website is analytics and tracking code.

A typical analytics snippet records the URL of every page someone visits. Dropped onto a file-sharing site without a second thought, that snippet sits on the share and download pages too - the exact pages whose URL contains the secret. When it records “page viewed,” it can capture the full address, including the file identifier and the key, and ship it off to a dashboard. The key that was carefully kept away from the server now sits in an analytics database, readable by whoever runs it - and by the analytics vendor.

It does not even need to be classic page-view analytics. Tag managers, advertising and measurement pixels, and especially session-replay scripts (which record what happens on the page) can all observe the address bar. The richer the tracking, the more of your secret link ends up somewhere you never agreed to.

It's usually an accident, which is the scary part

Most sites that leak links this way are not malicious. They added a standard analytics tag to every page during setup, the way almost every site does, and never considered that one of those pages carries a secret in its own URL. The default behavior of a perfectly ordinary tool, applied to a page that happens to hold a password, is all it takes.

That is what makes it dangerous: it is invisible. The person sharing the file sees a clean link. The recipient sees a clean link. Nobody sees the copy quietly accumulating in a dashboard.

What a leak-proof design looks like

Stopping this is not complicated. It comes down to three rules, applied to any page that might carry a secret link.

The third rule closes a quieter side door. Even without analytics, browsers can pass the page you came from to the next site you visit. The fragment is stripped from a referrer automatically, so the key is safe there - but the file identifier could still travel. A no-referrer policy makes sure even that stays put.

How PrivDrop is built to see nothing

This is exactly the standard we hold PrivDrop to. The pages that handle a shared file carry no analytics, no ads, and no third-party scripts whatsoever - there is simply nothing in the page that could read a link and send it anywhere. The decryption key lives in the URL fragment and never reaches our server, and the whole service sends a no-referrer policy so links don't leak when a recipient clicks away.

We didn't want to take this on faith either, so our research team measured it. In a PrivLab study on telemetry exposure, we ran a model share link through a matrix of common tracking configurations and watched what each one transmitted. In most setups the link path was captured, and in roughly half the configurations the secret key itself left the browser. The only configuration that leaked nothing was the one with no tracking on the page at all.

What to ask of any sharing tool

You don't need to read source code to gauge whether a sharing tool respects this. A few honest questions go a long way:

• Does the share or download page load any analytics, ads, or other third-party scripts?
• Is the decryption key kept in the URL fragment, so the server never receives it?
• Does the service avoid tracking who opens which link?

If the answer to the first question is “yes,” the rest barely matters - the secret link is being read by code whose whole job is to send data somewhere else. Privacy that depends on a tracker behaving itself is not privacy at all.

Part of a privacy-first toolkit

PrivDrop is one of several tools topriv builds around the same principle: your data stays yours.

Convert a file with PrivConvert, encrypt it with the .priv format, and share it with PrivDrop - without your link, your file, or your key ever ending up in someone's dashboard.

topriv builds privacy-first digital tools. Follow us on X, Telegram, YouTube, and TikTok.