Removing “barnacle trackers”

A privacy-by-design method to prevent undesired trackers from accumulating on your website.

A barnacle tracker is a third party resource (script, font, style, video, etc.) attached to a website, often violating the site’s privacy policy and slowing the loading time.

The problem

Fig. 1: Barnacles on a log.
Organic accumulation of life, as found on a beach.

The web was not designed with reader privacy in mind. Each interaction with a website can be observed by the site’s publisher. Worse still, most websites nowadays include dozens of resources from other companies, such as embedded videos, images, fonts, and ‘like’ or ‘share’ buttons. Each of those companies are *also* able to track the readers — and are doing so en masse.

The website publisher exposes its visitor to such companies’ malpractice. The GDPR speaks of joint data controllers with shared responsibility, and recent court cases have held website publishers responsible for enabling data collecting by a third party (see e.g. CoJ case C 40/17, July 2019).

The owner of a website carries responsibility to not expose its visitors to trackers.

How trackers accumulate

Fig. 2: Barnacles that log.
Organic accumulation of trackers, as found on a popular news website.

Even if an organization has a good privacy policy and does its best to enforce it, it might be difficult typically any coworker able to edit the site content can add a third-party plugin, embed a youtube video, use external fonts or other illegitimately user-tracking third-party tool. Thus, breaking the privacy policy is considerably easier than enforcing it.

All of this makes it easy for a website to accrue a large number of trackers that not only cause the website to load more slowly and work more sluggishly, but also cause serious privacy headaches for readers and compliance problems for website admins. And much like real barnacles, barnacle trackers are often found in places that are hard to reach and inspect. Under the waterline of the website, so to speak.

A self-enforcing privacy policy

The Content Security Policy web standard can help enforce a privacy policy in a transparent, verifiable way.

Content Security Policy is a web standard proposed in 2012 and gradually implemented in browsers. Its original purpose was to provide “a workable defense against XSS on pages that must allow user submitted HTML and JavaScript” (source: Mozilla’s Content Security Policy · Robert Hansen · 1 July 2009).

We are proposing that CSP could also offer an elegant solution to barnacle trackers: a CSP header could be added to the whole website that tells the browser exactly which third parties a page may connect to. This secures against malicious scripts and cross site scripting exploits. But also it enforces the privacy policy in a way that can be verified and that is hard to go around.

Advantages for readers

Readers (or regulators) can check if privacy policies are being implemented and enforced simply by looking at the headers. A malicious site admin could of course work around the CSP, but that requires considerably more work than just embedding a random tracker.

So, if the CSP matches the site’s privacy policy, a reader can be reasonably sure that the privacy policy is being enforced.

Advantages for organizations

In many larger organizations the website’s developers, and people running it are in different teams. Quite often developers will not be fully aware of organization’s privacy policy or will not nuderstand how their work can clash with it.

This puts admins (and the DPO, if there is one) in a difficult position of having to check the whole site (or every change pushed to production) against the privacy policy. This takes time and potentially creates unnecessary tensions between developers, and admins/DPO/legal when the former want to push changes that work and the latter block them.

Privacy policy enforced by CSP solves this organisational issue. Admins and the DPO/legal do not have to manually check every new version of the code, and for developers it is not some people blocking their deployment on a whim, but rather a bug in code that needs a fix.

Every change to the CSP has to be granted by the DPO/legal, who should anyway keep a list of processing partners. In many cases this could be automated.

Advanced mode

For third-party processing based on consent, a server-side configuration could make CSP content dependent on the existence of a consent-storing cookie.

Again, this enforces the privacy policy (and the requirement for user consent) in a way that is easy to verify by readers, admins/DPO/legal, and regulators, and hard to work-around by developers, or a malicious person with access to the CMS.