Tag Management and the Chain of Responsibility Part 1

The Situation

Tag Management Systems like GTM allow to inject arbitrary bits of Javascript into a page. Of course JavaScript based tags have existed before (for starters web tracking systems like Google Analytics use JavaScript tags), but previous to TM systems they were integrated under the supervision of developers, so there was at least some vetting before they ended in the source code (or so one would hope). Now tags can be deployed by just anyone, and that’s a problem because third party JavaScript is dangerous.

It’s not just that it might slow down a website, or interfere with existing scripts, or overwrite variables. It is that by allowing a third party to run JavaScript on your site you effectively hand them the key to the city. The script runs in the context of the current page and now can change the content of the site, redirect users, invalidate your ssl encryption by loading insecure assets (browser warnings will ensue), read cookie data, send data (for example, but not limited to) credit card data to remote server or load additional scripts from external sources. The latter is often done purposefully by tag vendors.

What is actually happening

There are three major uses for this kind of tag injection, the innocent, the nefarious and the dumb.

An innocent use would be e.g. to load a tracking library from the vendors server; this makes sure you always have the most recent version of their code without checking for updates yourself. As long as the code comes from a server under your tag vendors control I don’t see anything wrong with this. Or they might have acquired another company, or have been acquired by another company, and want to spare you the trouble to re-tag your site while their are transitioning between two technology stacks.

By “nefarious” I do not mean anything illegal – tag vendors do not usually purposefully break the law. By nefarious I mean they do something legal that is still opposed to your (as in “you, the client”) best interest.

For example at an previous employer we ran a remarketing campaign with Google, but also tested a third party retargeting platform. When we examined their tag we found that they dynamically loaded a Google tag of their own (evidently their delivery network did not have the necessary coverage to generate enough clicks). Now prices are determined in a bidding contest, so the effect of this was that we paid a third party to bid against us for clicks from the same audience. Or rather that would have been the effect had we chosen to work with them (we did not).

By “dumb” I finally mean that sometimes the third parties are not quite aware of the consequences of their actions. Again a real life example, a startup that promised some exciting visitor recognition technology did not actually had their product ready when they started up and instead used a few jQuery plugins to do browser fingerprinting. That was not the main problem, however. The problem was that, so as not to waste their own expensive bandwidth, they pulled an complete and unminified version of the jQuery framework from the public jQuery CDN in the US into the clients page. They seriously did not understand why including third-party Javascript from an untrusted server whose operator is not bound by any kind of contract might be a bad idea (I’m convinced that John Resig does not want to steal my client’s cookies, but am eventual hacker who replaces the jQuery files with his own script might think different about the matter).

What aggravates the problem is that it affects not only you, it affects your tag vendor as well – every third party (or fourth- or fifth party rather) service your vendor uses to enhance his tags might itself load additional scripts, and these might load others, and so on and so on (this is not a theoretical concern btw., this happens in real life). Each of these tags can extract information from your page and send them god knows where.

So, the more tags are chained together in this fashion the harder it is to say who is responsible should user data go astray.

This is the point where you go and read your contracts and consult with your data protection officer (if you do not have one this might be the time to go looking for one).  I’ll leave you to it until the second installment of this series where we take a look at possible solutions to the problem.

Read Part 2 here

Leave a Reply

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