Most privacy policies are written by lawyers and read by nobody. Most websites are assembled by developers under deadline, adding a script for analytics, another for a chat widget, another for an embedded video, another because marketing asked for it. The policy describes what the organisation intends. The scripts describe what actually happens in the reader’s browser, and only one of those documents is enforceable by the browser itself.
What a third-party script can do
When a page loads a script from another domain, that script runs with the same authority as the page’s own code. It can read everything the page can see, including form fields as they are typed. It can set identifiers that follow the reader across every other site that loads the same script. It can load further scripts from further domains, none of which the site owner chose. And it can change its behaviour at any time, because the site owner is loading whatever the third party serves today.
That last point is the one that surprises people. A script that was harmless when it was added can become a tracker, a miner or a payload after a supply-chain compromise, and the site will serve it faithfully until someone notices.
The measurable gap
Because scripts are visible, the gap between policy and practice is easy to audit. Load the page with the network panel open and count the domains. Check which ones set cookies and which run before any consent has been given. Look for pixels that fire on form submission. Compare the list to the policy’s description of “trusted partners”.
On most commercial sites the count runs into dozens, the policy names a handful, and several of the scripts run regardless of what the consent banner says. That is not usually malice. It is the accumulation of individually reasonable decisions with no one responsible for the total.
The defensive tools
Browsers now provide the site owner with real controls. A Content Security Policy tells the browser which domains are allowed to run code, load images or connect to servers; anything else is blocked and reported. Subresource integrity lets a page verify that a script has not changed since it was reviewed. Permissions policies deny access to cameras, microphones and location to any frame that does not need them. Referrer policies limit what the site leaks about its own readers to the destinations they click.
None of these is difficult to deploy. All of them are rarely deployed, because they require someone to write down what the site actually needs, and that inventory is the work nobody has done.
The editorial version of the problem
For a publisher, the question is sharper. Readers extend a degree of trust to a publication that they do not extend to a shop. A news site that loads twenty trackers is monetising that trust in a way the reader did not agree to and would not recognise from the masthead.
The alternative is not to have no analytics. It is to choose tools that measure without identifying, to host what can be hosted, to load embedded media only when the reader asks for it and to write a policy that matches the network panel.
A simple test
Open your own site. Open the developer tools. Load the page. If you cannot explain every domain in the list, your privacy policy is describing a website you do not have.
