Do-Not-Track: The Key to Compliance with the ePrivacy and General Data Protection Regulations

Do-Not-Track: The Key to Compliance with the ePrivacy and General Data Protection Regulations

The European Commission’s recent proposal for the new ePrivacy Regulation (EPR), like the ePrivacy Directive which it will replace, creates rules on how websites or service providers should process communication data and access to storage in users’ equipment.

It requires that users’ “freely given, informed, specific & unambiguous” consent must be obtained before websites store or use personal identifiers such as tracking cookies[i], and that users should be able to revoke their consent at any time.

This will now be debated in the European Parliament over the next 6 months or so, and the text is expected to be amended, but it is possible to have an insight into its final shape.

Big Fines and International Reach

EU Regulations automatically apply to every EU Member State as soon as they come into force, while Directives have to be implemented by each separate legislature, creating delay and inconsistency in how they were implemented, so that has been fixed. In addition, many of the definitions in the EPR correspond to those in its sister legislation the General Data Protection Regulation (GDPR) and importantly, when they both come into force in May 2018, the same high level of fines (up to 4% of a company’s turnover[ii]) can be imposed.

The rules will also now apply to any company wherever in the world it is based, if it processes the personal data of, or provides software for “permitting electronic communications” to, European residents and to any EU based company that provides electronic communications services to people anywhere. The rules for obtaining and acting on consent now also apply to "providers permitting electronic communications, including the retrieval and presentation of information on the internet", i.e. browser companies such as Microsoft, Opera, Mozilla, Apple and Google.

If a website, or an embedded web resource such as an online advertisement, does not use personal identifiers, or only uses them to enable the underlying communications channel or fulfil a service requested by the user (such as saving the state of a “shopping basket” or remembering a user log-in), then consent was never required by the old Directive and is similarly not necessary under this proposal.

The draft Regulation is slightly more permissive in this regard because consent is no longer required for identifiers used to identify unique users for analytics purposes, so long as they are only processed by the first-party site (the site that the user has explicitly visited and displayed in the browser’s “location bar”). This means that analytics systems such as the open-source Piwik can be used without having to get user consent, while third-party analytics such as Google Analytics cannot.

The Role of Browsers is Changing

The main innovation in the new Regulation is the obligation it places on browsers. The motivation for this seems to have been to allow many smaller businesses to "do away with" cookie banners and notices which, although never required by the 2009 Directive, many assumed these often elaborate but irritatingly ineffective banners absolved them of the need to obtain and act on consent. The introductory section in the Regulation casts this as a cost reduction measure for many small businesses which can in future rely on browsers to take on the consent responsibility, though it points out that many businesses will still want to do this themselves, especially as now non-consensual tracking will be impossible:

"By centralising the consent in software such as internet browsers and prompting users to choose their privacy settings and expanding the exceptions to the cookie consent rule, a significant proportion of businesses would be able to do away with cookie banners and notices, thus leading to potentially significant cost savings and simplification. However, it may become more difficult for online targeted advertisers to obtain consent if a large proportion of users opt for "reject third party cookies" settings. At the same time, centralising consent does not deprive website operators from the possibility to obtain consent by means of individual requests to end-users and thus maintain their current business model. Additional costs would ensue for some providers of browsers or similar software as these would need to ensure privacy-friendly settings." 3.4 Impact assessment

Article 9.2 says “consent may be expressed by using the appropriate technical settings of a software application enabling access to the internet” [iii]. The setting will have to be communicable to the relevant servers, especially as it “should be binding on, and enforceable against, any third-parties” [iv]. Consent must be “freely given, informed and specific”, i.e. users should be able to allow or deny access to cookies and other information on a per-domain basis. Browsers are also required to take an active role in safeguarding users’ privacy[v] by blocking access by third-parties to users’ information and ability to be tracked when they have not given their consent [vi] [vii]

Third-Party Cookie Blocking is NOT Sufficient

In practice browser protections must improve on the partial “third-party cookie blocking” already supported by some browsers, which can be easily circumvented through the inclusion of third-party script on first-party sites. This script can use standard APIs to arrange for values encoded in first-party cookies to be communicated to third-party servers. It can stop third-party cookies from being blocked by fooling the browser into seeing them as first-party, for example by editing internal links to redirect requests via third-party servers. Much tracking of iOS Safari users is now done this way.  

The requirement in Article 10 is to make best efforts to stop all illegal third-party data access, not just blocking cookies, so browsers should inhibit access to localStorage, indexedDB, MediaStream device Ids, Token-Binding Ids etc., and the inhibition to the maximum extent of browser fingerprinting, as the TOR browser has proven is feasible.

Users must be given the choice to express their general privacy preference when they first install a browser, and at least every 6 months thereafter. 

How Do-Not-Track Support is Crucial

The technical definition of Do-Not-Track, the W3C Tracking Protection Group’s Tracking Preference Expression document, fits these requirements like a glove.

  1. There is a dedicated request header for indicating user consent for tracking, or lack of it, to any server, including those handling embedded third-party sub-resources. This signal is immediately available and does not require another roundtrip. 
  2. Consent is signalled with a dedicated header, and does not need the Cookie header. This allows separate cache management for content depending on consent (difficult to arrange otherwise) leading to major performance gains. 
  3. The General Preference can be enabled at any time e.g. at installation so the user can specify that they object to tracking by default to all servers. All browsers now support the DNT general preference. 
  4. A JavaScript API that allows first-party sites to either register when a user has given their agreement to be tracked by that server by a named subset of servers of embedded sub-resources but only within the context of the first-party site. Consent can be revoked at any time, by the browser or the site that obtained it, and can be given an automatic expiry time. 
  5. Consent can be given or revoked independently of servers by allowing the user to change settings within their browser at any time.
  6. A standardised and transparent way to deliver information about the identity, policies and other information about any web resource, including third-party sub-resources, which can be varied dynamically per context.

The value of the DNT header, “0” to accept tracking and “1” to decline it, is generated by the browser depending on whether the user has given consent to the relevant server. The browser can then act on the state of this header itself, either unconditionally or contingent on how a server responds to it. This lets browsers meet the requirement in Article 10 to safeguard users’ privacy by preventing “third-parties from storing information on the terminal equipment of an end-user or processing information already stored on that equipment” unless consent had been given. Although the current draft does not specify that the default setting in browser should send DNT set to "1" the Parliamnent will probably deal with this in its amendments.

Many websites and third-parties will still need to be able to ask users for consent, this cannot be left entirely to browsers. The Do-Not-Track JavaScript API has been purpose designed to help them do this, especially the site-specific variant of it, because users can give their consent on the site and revoke it any time either on the site or within their browser.

Users are more likely to give their consent if they know their online activity is shared only within the site requesting it, which is made possible by the site-specific API.

The Tracking Protection Working Group has now received the go-ahead to take the TPE to final Recommendation by Summer 2017, with the main focus being “to demonstrate the viability of TPE to address the requirements for managing cookie and tracking consent that satisfies the requirements of EU privacy legislation”[viii]. This will now include the new ePrivacy Regulation.

Baycloud System’s Mike O’Neill has been an active contributor to the TPWG since 2012, and we have implemented the Do-Not-Track API and Tracking Status Resource both client-side in a browser extension which can actively enforce the signal, and server-side on many thousands of websites, including over 4,000 production sites for major consumer brands in over 30 counties.

We are pleased to see our work now helping to extend user control over personal data across and beyond Europe.

  


[i] The prohibition against access to storage without consent is laid down in Article 8.1: 

  1. The use of processing and storage capabilities of terminal equipment and the collection of information from end-users’ terminal equipment, including about its software and hardware, other than by the end-user concerned shall be prohibited, except on the following grounds:

(a) it is necessary for the sole purpose of carrying out the transmission of an electronic communication over an electronic communications network; or

(b) the end-user has given his or her consent; or

(c) it is necessary for providing an information society service requested by the end-user; or

(d) if it is necessary for web audience measuring, provided that such measurement is carried out by the provider of the information society service requested by the end-user.

 Data emitted by a terminal to connect with another, i.e. Internet Protocol (IP) and Media Access Control (MAC) addresses must also not be processed, unless a clear notice and prominent notice is displayed and the user can have control over its collection. Article 8.2 says: 

  1. The collection of information emitted by terminal equipment to enable it to connect to another device and, or to network equipment shall be prohibited, except if:

(a) it is done exclusively in order to, for the time necessary for, and for the purpose of establishing a connection; or

(b) a clear and prominent notice is displayed informing of, at least, the modalities of the collection, its purpose, the person responsible for it and the other information required under Article 13 of Regulation (EU) 2016/679 where personal data are collected, as well as any measure the end-user of the terminal equipment can take to stop or minimise the collection.

This still leaves the possibility that IP addresses can be used to “single-out” a user without consent or meaningful control, which will become more important as the new version of Internet Protocol (IPv6) enables the fine grained addressability of devices. This incongruity should be clarified when the European Parliament debates the proposal.

[ii] Infringements of Article 8 (Consent) and Article 10 (Information and options for privacy settings to be provided) are subject fines of €10M or 2% of turnover whichever the larger. This can also apply to software providers “permitting electronic communications” e.g. browser companies.

 [iii]  Article 9 Consent

  1. The definition of and conditions for consent provided for under Articles 4(11) and 7 of Regulation (EU) 2016/679/EU shall apply.
  2. Without prejudice to paragraph 1, where technically possible and feasible, for the purposes of point (b) of Article 8(1), consent may be expressed by using the appropriate technical settings of a software application enabling access to the internet.
  3. End-users who have consented to the processing of electronic communications data as set out in point (c) of Article 6(2) and points (a) and (b) of Article 6(3) shall be given the possibility to withdraw their consent at any time as set forth under Article 7(3) of Regulation (EU) 2016/679 and be reminded of this possibility at periodic intervals of 6 months, as long as the processing continues.

 [iv]  Recital 22: 

(22) The methods used for providing information and obtaining end-user's consent should be as user-friendly as possible. Given the ubiquitous use of tracking cookies and other tracking techniques, end-users are increasingly requested to provide consent to store such tracking cookies in their terminal equipment. As a result, end-users are overloaded with requests to provide consent. The use of technical means to provide consent, for example, through transparent and user-friendly settings, may address this problem. Therefore, this Regulation should provide for the possibility to express consent by using the appropriate settings of a browser or other application. The choices made by end-users when establishing its general privacy settings of a browser or other application should be binding on, and enforceable against, any third parties.

 [v] Recital 22 goes on:

 Web browsers are a type of software application that permits the retrieval and presentation of information on the internet. Other types of applications, such as the ones that permit calling and messaging or provide route guidance, have also the same capabilities. Web browsers mediate much of what occurs between the end-user and the website. From this perspective, they are in a privileged position to play an active role to help the end-user to control the flow of information to and from the terminal equipment. More particularly web browsers may be used as gatekeepers, thus helping end-users to prevent information from their terminal equipment (for example smart phone, tablet or computer) from being accessed or stored.

[vi] Article 10 Information and options for privacy settings to be provided

  1. Software placed on the market permitting electronic communications, including the retrieval and presentation of information on the internet, shall offer the option to prevent third parties from storing information on the terminal equipment of an end-user or processing information already stored on that equipment.
  2. Upon installation, the software shall inform the end-user about the privacy settings options and, to continue with the installation, require the end-user to consent to a setting.
  3. In the case of software which has already been installed on 25 May 2018, the requirements under paragraphs 1 and 2 shall be complied with at the time of the first update of the software, but no later than 25 August 2018.

[vii] This is further described in Recitals 23 and 24:

 (23) The principles of data protection by design and by default were codified under Article 25 of Regulation (EU) 2016/679. Currently, the default settings for cookies are set in most current browsers to ‘accept all cookies’. Therefore, providers of software enabling the retrieval and presentation of information on the internet should have an obligation to configure the software so that it offers the option to prevent third parties from storing information on the terminal equipment; this is often presented as ‘reject third party cookies’. End-users should be offered a set of privacy setting options, ranging from higher (for example, ‘never accept cookies’) to lower (for example, ‘always accept cookies’) and intermediate (for example, ‘reject third party cookies’ or ‘only accept first party cookies’). Such privacy settings should be presented in an easily visible and intelligible manner.

(24) For web browsers to be able to obtain end-users’ consent as defined under Regulation (EU) 2016/679, for example, to the storage of third party tracking cookies, they should, among others, require a clear affirmative action from the end-user of terminal equipment to signify his or her freely given, specific informed, and unambiguous agreement to the storage and access of such cookies in and from the terminal equipment. Such action may be considered to be affirmative, for example, if end-users are required to actively select ‘accept third party cookies’ to confirm their agreement and are given the necessary information to make the choice. To this end, it is necessary to require providers of software enabling access to internet that, at the moment of installation, end-users are informed about the possibility to choose the privacy settings among the various options and ask them to make a choice. Information provided should not dissuade end-users from selecting higher privacy settings and should include relevant information about the risks associated to allowing third party cookies to be stored in the computer, including the compilation of long-term records of individuals' browsing histories and the use of such records to send targeted advertising. Web browsers are encouraged to provide easy ways for end-users to change the privacy settings at any time during use and to allow the user to make exceptions for or to whitelist certain websites or to specify for which websites (third) party cookies are always or never allowed.

[viii] Tracking Protection Working Group Charter https://www.w3.org/2016/11/tracking-protection-wg.html

Check out our other blog posts