Another method allowing targeted advertisers to avoid Safari third-party cookie blocking has been found on a UK website, implemented by a French AdTech company.

I have pointed out before that an early decision by the Tracking Protection Working Group (TPWG) was that servers could take different action on receipt of a Do Not Track (DNT) signal depending on whether they were accessed as a first-party, i.e. used the domain of the website a user had explicitly visited, or a third-party such as Facebook like button or an invisible behavioural tracker. As I have blogged about before, this decision was wrong and introduced confusion into the process leading to much of the delay in reaching consensus, but the W3C process and the power of its big funding companies made it impossible to dislodge; even so the standard DNT compliance document complements European Data Protection and Privacy law especially in its recognition of the need for explicit consent.

Last year (2014) some of us in the TPWG successfully argued that link shorteners like bitly.com and behavioural trackers such as Google that used redirection for “cookie synching” should have to comply with DNT in the same way as the servers of embedded third-parties. The compromise text we eventually agreed on is the 3rd paragraph under section 2.8.

During the debate I pointed out that redirection of an internal website page link could be hijacked in such a way that the request would be sent to an external server, i.e. not one controlled by the website the user thought they were interacting with. Clicking on a link is regarded by the browser as deliberate access to a first-party site, so setting a third-party cookie block would not stop them. The external service would then return a “redirect” status value to the user’s browser with a location header pointing to the link the user had originally clicked. 

The fact that Safari blocks third-party cookies by default is one of the reasons many people feel more comfortable browsing the web with Apple devices. This was why the US Federal Trade Commission fined Google $22.5 million for implementing clever technology to circumvent the block, with Apple subsequently having to fix the loophole that allowed Google’s technique to work. Apple’s browser is still the only one whose default setting is to block third-party cookies, and some in the surveillance marketing industry are determined to defeat it.

Recently John Lettice, the Editor of The Register, noticed that his Safari browser, which he had set to always block third-party cookies, was receiving criteo.com cookies when he visited the  website of Furniture manufacturer Heals. He pointed this out in a tweet and we decided to take a closer look.

I was amused to find that the redirection technique predicted last year had in fact been implemented.

Basically what is happening is that script, supplied by Criteo, is being inserted in-line on to the heals.co.uk page. This script checks for the presence of a first-party cookie to find out if the Heals site had been visited within the last 24 hours and whether UID cookies have been already been placed in the criteo.com domain. It then causes a banner to be displayed informing the user that if they click on the page (actually only on anchor tags pointing to other web pages on the site) their consent for third-party cookies will be implied so that cookies can be deployed into the criteo.com domain.

This script simultaneously sets up a JavaScript “click” event handler on the page. When triggered by the user clicking one of the menu items, i.e. they are navigating further into the site; the target of the menu item link is changed on the fly to point to the r.criteo.com subdomain, with the original link URL appended as a query parameter to the newly created r.criteo.com link URL.

The r.criteo.com resource that is now visited is effectively accessed as a first-party and is able to place cookies into the criteo.com domain by returning set-cookie headers in the response along with a “302 Found” redirect back to the original healss.co.uk menu item resource. Here is a screenshot showing the request to r.criteo.com being triggered when the “Furniture” menu item is clicked just before the request to the correct heals.co.uk page. Criteo is basically intercepting the first-party navigation to another page on the site, and is able to place cookies because it is being accessed as a first-party.

The code is only triggered when you use Safari, though in principal the technique should work in any browser.

Once cookies have been placed in a domain they will be always be sent in every request to that domain, irrespective of whether it is to a third-party or first-party resource. In fact the HTTP standard does not include a way to tell the difference. Safari will even allow a third-party to change the value or other attributes of a cookie once it has been placed, even with third-party cookie blocking.

The Criteo implementation appears to be designed to align with the CNIL’s version of “implied consent” announced in December 2013, in that user consent (for server’s use of browser storage as per the EU’s ePrivacy directive) can be assumed if the user is shown an explanatory banner before they navigate round the site.

In our opinion it does not comply with CNIL’s guidance because the “implied” consent interpretation only applies to the setting of first-party cookies, and consent, whether “implicit” or explicit, needs to be easily revocable at any time, (the Criteo banner is shown “once only” although the fact that their “uid” cookie expires after one year probably means it complies with the CNIL’s minimal sunset requirements).

Because third-party cookies are used to track people across the whole web it should not be possible for a user to accidentally have their consent implied (say by not noticing the information banner before navigating further into a site) then end up being tracked on countless other sites that also use the Criteo service, while at the same time not being given a way to easily revoke it. The standard Do Not Track compliance document requires such explicit consent before third-party tracking when the browser’s general DNT preference has been set, and this must be assumed to be the default in the EU.

It would not be hard for Criteo to implement explicit consent, i.e. the user would be given clear information on the purpose of tracking which would only occur if they specifically clicked on an “Agree” button or checkbox. We think this should always be required for third-party tracking cookies, along with a permanent revocation facility, as we have enabled in our general purpose CookieQ consent product. We would be glad to help them with that, along with extending the consent capability to all the embedded third-party servers referenced on the Heals website without annoying the the visitor with multiple one-time banners.

There is also a danger that less scrupulous companies will develop similar script that circumvents third-party cookie blocking without explaining at all to users what they are doing. Regulators and privacy watchdogs should be on their guard for this. It is also worth noting that could be impossible for browser extensions like Ad Blockers to spot third-party cookie placement through redirection, because the interception is only visible for a very short time, and could be implemented completely using in-line script.

But kudos to Criteo for showing that is possible to use the technology of the web platform to give people control over how they are tracked; joining the project we have been engaged in since 2011. While we believe they are wrongly basing web-wide cookie consent acquisition on the “implied” consent interpretation, this still belies the myth that regulation conflicts with innovation, showing that advertisers, publishers and brands can re-establish consumer’s trust by respecting the rule of law and protecting the fundamental right of privacy through the creative and innovative use of technology.

Check out our other blog posts