Your website is only as private as its third-party scripts

Tue, 25 Aug 2026 00:00:00 GMT

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.

RSS never died. It just stopped being marketed.

Tue, 11 Aug 2026 00:00:00 GMT

Every so often someone declares a feed technology dead, usually because a large company stopped supporting it. The technology in question carries on regardless, because it does not depend on any large company. RSS, the simple format that lets a site publish a machine-readable list of what it has recently published, is a case study in how open standards outlive the products built on top of them.

What it does

An RSS feed is a file. It lists a site’s recent items with a title, a link, a date and usually a summary or the full text. A reader application fetches that file periodically from every site you follow and shows you what is new, in the order it was published, with nothing hidden and nothing promoted.

That is the whole feature, and it is the opposite of a modern feed in almost every respect. There is no ranking. There is no engagement metric deciding what you see. There is no platform between the publisher and the reader. If you subscribe to a site, you see what it publishes, and if you unsubscribe, it stops.

Why it faded

RSS lost its mainstream moment for ordinary reasons. It required a separate app and a little setup. Social platforms offered discovery as well as following, and discovery is what most people wanted most of the time. Publishers found that social distribution reached more people, even if it reached them less reliably. And the format itself was never a product with a marketing budget; nobody’s revenue depended on you knowing it existed.

Why it is back

Three things changed. Platform feeds became noticeably worse at showing people what they had asked to see, and the reasons became widely understood. Podcasts, which run entirely on RSS, became one of the largest media categories in the world, demonstrating that the model scales. And a new generation of reader apps made subscribing as easy as pasting a link, with polished interfaces that no longer feel like a developer tool.

There is also a quieter driver. Anyone building a tool that needs to know what a site has published, whether that is a search engine, a research project, an archive or an assistant, uses feeds if they exist. A site with a good feed is a site that participates in the wider web. A site without one is a site that can only be reached through whichever platform happens to be ascendant.

What a good feed looks like

Full text rather than truncated teasers, so that reading does not require a click-through. Correct dates, so items appear in order. A stable link per item. Enclosures for media, so that audio and video feeds work in podcast apps. Category feeds for readers who want one subject and not the others. And a link in the page’s head so that reader apps find the feed automatically.

None of this is difficult. It is simply a matter of treating the feed as part of the publication rather than a legacy checkbox.

Where OCXLY stands

This site publishes a full feed and category feeds, and the video and audio sections have their own. If you would rather follow us through a reader than through a platform, that is exactly what they are for. The open web is not a nostalgia project. It is the part of the internet that still works the same way regardless of who owns it this year.

OCXLY Digital Media House — Internet