When Cookies Attack, or Why Compliance Requires Continued Vigilance
If you want your business to be transparent about your use of cookie technology, and ensure that what you say you are doing is actually what you are doing, it is really important to pay attention to the detail of what is going on in your website.
This means that you have to keep a good look out for changes to your site, and run rigorous testing in real world use scenarios. The truth of this was brought home to us recently when we discovered that our very own website was setting and retrieving third party cookies that we were not aware of.
It started with a comment made by someone on one of our previous posts, claiming that our site was not compliant – that we were in fact setting cookies on visitors machines without their consent, and these were cookies not listed in our own disclosure statement.
My first reaction was that this could not be true – we had tested very carefully and knew absolutely we were in the clear. I was determined to prove the commenter wrong, so tested some more – and then discovered that the person was in fact right – in certain circumstances.
A very innocuous script, hosted by Microsoft, turned out to be the culprit. The script is part of a recently updated blog package that runs the pages this very article is written on. Its sole purpose is to provide simple form validation when someone posts a comment on one of our articles.
We had tested this specifically for cookies before – but had not seen any. We’d cleared out all cookies in the browser, run it over the site, and seen nothing unexpected show up. None of our cookie audit tools showed any sign of the guilty cookies being set by the site. Yet we had evidence that someone else had seen them.
I went to find some information about these cookies – including going to various sources on Microsoft’s own sites. Then on going back to our own site – suddenly we could see the cookies being set and it all became clear.
Having visited www.microsoft.com – my browser had picked up a number of cookies from them. Due to the way that cookies work, when going back to our page with a microsoft.com hosted script – those cookies were automatically sent by the browser to the host domain. What the Microsoft site then appeared to do, was react to the presence of its cookies and set updated values as well as planting one or two more through the hosted script.
We hadn’t detected any of this in testing simply because of the artificially ‘clean’ browser we had created for the test. This normally makes sense in most testing – as it eliminates the ‘noise’ of pre-existing data, but by creating this artificial environment we created conditions that guaranteed these particular cookies would not be set.
We have now changed the site so that the script in question is now hosted on our own domain, and as a result cookies will no longer be set by it. I would like to acknowledge and thank the person who originally pointed the problem out to us so we could correct it. However we have also learnt some important lessons.
The first is that it is really important to look very hard at any third party scripts placed in a website. Especially when they are hosted by big companies or big data collectors (like ad networks). Even if the script on its own is not setting cookies – any script can open up a window to the host servers, through which other cookie activity might occur, either incidentally or by design.
However, it also highlights the importance of both regular auditing, which we have talked about before, and real-world auditing.
Many cookie audit services use automated spidering or scanning techniques to discover cookies being set. This enables them to offer extremely low cost services because it eliminates a lot of work. We have long known that this is not sufficient to uncover certain types of cookies that are only set through user interaction. However, this story also highlights the potential inadequacy of such solutions even when it comes to cookies that might be set automatically on page loading.
Automated cookie audit solutions generally rely on technology to simulate browsing, but at high speed to collect data more quickly. However this cannot fully replicate the browsing of a human, and therefore will not pick up certain types of cookie activity. In particular they do not take into account the ‘real-world’ scenario of a browser with a history of existing cookies. In this respect automated scanning is more like using the ‘clean’ browser that would typically be used in testing.
Time and again we have seen automated cookie audits that uncover nothing like the number of cookies that our own services and tools do. This is because we don’t rely on artificial, simulated browsing technologies.
Instead we record real browsing and real cookie interactions taking place, and our plug-in technology allows the contributions of many people to be brought together in a single report, spreading the effort for bigger sites.
The other major advantage of the Optanon Cookie Auditor is that it enables customers to continually monitor their site for new cookies, simply by browsing it, which most site editors do anyway when making changes. This means being able to pick up and report on new cookies as they are spotted, which as we have seen, is vital for maintaining continual compliance.
January 13, 2017
Future of EU Cookie Compliance Webinar: ...
GDPR and now the proposed E-Privacy Regulation mean a stricter regime for cookie compliance, web governance and use of online tracking technologies. Join p...View Article →
December 14, 2016
Draft EU ePrivacy Regulation Leaked...
A draft of the proposed legislation to replace the outdated EU ePrivacy Directive was leaked on the Politico.eu (PDF) website this week. The proposal is fo...View Article →
November 3, 2016
GDPR Compliance Means Cookie Notices Mus...
Are you one of those people that ticked the cookie law box ages ago and not thought about it since? Well the game has changed and now is the time to re-vis...View Article →