Tag Management and the Chain of Responsibility, Part 2

(Read the first part here)

Attempts at a Solution

The most obvious solution is to not allow Javascript tags at all. Make do with image pixels and maybe iframes (which are not able to interact with the page they are hosted in). This is not completely foolproof – even an image pixel can be redirected, and the redirected pixel might reveal information such as the users IP address (which in Germany is considered personally identifiable information, so it must be anonymized by each party). But at least images tags and iframes give you a huge measure of control about what data is being sent, since they cannot extract data from the browser.

Google Tag Manager actually helps you a great deal here – when integration the GTM code you can blacklist certain tags, or categories of tags, and variable types. There is rather good documentation on this. It’s not rocket science, either, but you should thoroughly plan what you need and what can be banned.

Summarily banning JavaScript tags might not be an option, though. There are many valid uses for JavaScript tags, and sometimes you actually want your vendors to extract information, or insert their own special logic into your page. In those cases blacklists might be too broad in their application.

Another, more contemporary way to contain the proliferation of third part scripts would be a Content Security Policy. CSPs are a new-ish (as in: in the works for quite some times, but not yet broadly implemented by developers) feature that allows you a high level of control over what ressources can be loaded (dynamically or otherwise) into your website. A “script-src” CSP would allow you to whitelist specific domains that are allowed to inject scripts, all others would be prohibited (HTML5  Rocks has an, albeit 3 years old article on CSP 1 that gives you a good rundown on the subject ). There were already two successor specifications before the first one was even supported on all major browser, and to come up with a usable solution that will work in all scenarios will be a bit of a challenge. But still this is something you should have a good look at.

What really is to do

For somebody working in implementation it hurts to admit this, but technological solutions will only bring you only so far. After all this should not be some sort of race where you have to always stay one step ahead of somebody who, at the end of the day, is working for you. Just talk to them (and by “them” I mean someone reasonably high in the food chain. The implementation helpdesk is usually inhabited by some poor sod who does their six month in the hot chair before they are promoted away to a proper job, so there is a good chance you already know more about the technology than they do).

They should easily be able to give you a list of what scripts, images and iframes they are going to integrate in your page, what data they collect to what purpose, and which additional parties and services are involved; and if there are additional parties involved there should be guarantees that they act in accordance with the law of your country (that’s the German in me speaking, we have particularly strict privacy laws) and that opt-out from the original tags also opts out from any piggybacked tags. You should be informed how data is processed and stored by these parties and who is legally responsible if data is misused, or handled in a way that violates the law. Most of your tag vendors should have watertight agreements in any case. But if your tracking is going to include multiple tags you will want to make sure that, from the first to the last link, there is a chain of responsibility enabled that safeguards your visitor’s data from abuse and you from legal troube.

Leave a Reply

Your email address will not be published. Required fields are marked *