Delta between EU regulatory context, DNT

Introduction

The Global Considerations Task Force had its kick off meeting in Berlin. During the meeting, Participants were unsure about how many changes would be required to make DNT work in the European context. The guesses were ranging from not much to impossible. This document tries to identify the areas where the current Tracking Protection Expression Specification and the Tracking Compliance Specification have gaps to achieve compliance with the ePrivacy Directive (2002/58/EC as amended by 2009/136/EC) and the General Data Protection Directive 95/46EC.

It is understood that the current document does not constitute legal advice and is not binding upon those who have written it. It is a mere summary of the common assessment of the relation between the Tracking Protection work and the existing regulation on the EU level.

1. DNT:1 are the permitted uses consistent with EU law?

In the regulated environment, DNT:1 can be a secured implementation guide that is accepted by the authorities as a common practice. If a service has implemented the DNT protocol and does not use personal data beyond what is allowed by the permitted uses unless there is a DNT:0, this service would be recognized as not infringing the EU regulation on data protection. So the DNT:1 is a cookbook on what one can do in the absence of consent.

As long as there is:

• No Secondary Use
• Data Minimization and Transparency
• Reasonable Security
• No Personalization

Those principles are key to a recognition for permitted uses within the EU regulation framework, especially data minimization and principle of finality (no secondary use)

1.1 Short term collection and use, where information is not transmitted to a third party or used to profile or personalize a user's experience

Currently, the short term collection and use is not covered by legislation. Nevertheless, the short term collection and use is common practice and justified mainly under the following exceptions in the ePrivacy Directive:

• Art. 5 paragraph 1 last sentence: This paragraph shall not prevent technical storage which is necessary for the conveyance of a communication without prejudice to the principle of confidentiality.

We could submit the short term storage under this exception.

1.2 Contextual content or ad delivery;

The question is in how far information and protocol chatter can be used by the service to adapt the personal browsing experience by the user. Content may be adapted to a certain browsing context. This mostly happens if a certain advertisement is served in the context of a certain page. In this scenario, the first party has to share the fact that somebody calls this page and the ad-network will deliver an ad according to the content browsed to the user.

Whether this is permitted even under DNT:1 is not sufficiently clear and disputed. In the discussion there was some feeling that while the contextual content delivery be the first party may work out, ad delivery by third parties may break EU compliance

1.3 Frequency capping with unique ID

Currently, there is still a dispute on this permitted use. While everybody agrees that frequency capping is a good thing, people differ on the collection practices that would be allowed. The Seattle - Meeting offered this option:

Server-side frequency capping is allowed if the tracking identifier is only retained in a form that is unique to each super-campaign (e.g., one-way hashed with a campaign id) and does not include retention of the user's activity trail (page URIs on which the ads were delivered) aside from what is allowed for other permitted uses.

With the Seattle definition, we may argue that the super-campaign ID is sufficiently wide so that the information is not personal data anymore and thus the storing into the terminal equipment (browser) isn't subject to the limitations of Art. 5.3.

1.4 Financial Logging and Auditing

Article 1.2 of the ePrivacy Directive points to 95/46/EC for all the things are not dealt with: The provisions of this Directive particularize and complement Directive 95/46/EC for the purposes mentioned in paragraph 1. The legal grounds for financial logging and auditing can be found in national law and the laws of accounting.

1.5 Security and Fraud Prevention

Legal grounds for this could be found in Art. 4.1 of the ePrivacy Directive:

The provider of a publicly available electronic communications service must take appropriate technical and organizational measures to safeguard security of its services, if necessary in conjunction with the provider of the public communications network with respect to network security. Having regard to the state of the art and the cost of their implementation, these measures shall ensure a level of security appropriate to the risk presented.

1.6 Aggregate Reporting

This is only a bullet point. There is not even text in the TCS concerning this exception. If this is elevated to a permitted use it is rather an implementation guidance as - depending on the level of aggregation - the data isn't personal data anymore. So this is connected to the de-identification and will further lose importance if the short term storage is accepted.

1.7 Debugging

This could also fall under Art. 5.1 of the ePrivacy Directive as a necessary collection for the conveyance of the service. Perhaps there are other legal grounds or legitimate business interest.

1.8 Compliance With Local Laws and Public Purposes

If local law requires data collection, it provides the legal reason for collection, thus this permitted use is not problematic.

1.9 audience measurement

Audience measurement is tricky. Everybody agrees that it is somewhat necessary for the eco system. Audience measurement under DNT:1 with enhanced privacy features could gain exceptions under the de-identified field. (For the moment, the legal grounds are unclear to me)

2. DNT:0 -- what can be consented to in a standard contract?

With the introduction of the DNT:0 header, the Group tried to also allow the user to signal if and when data collection is OK. At the Princeton Workshop the idea to signal consent with DNT:0 was born. The legal grounds for this idea are:

Art. 5.3. of the Directive 2009/136/EC: Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

Recital 66 of the Directive 2009/136/EC: (66) Third parties may wish to store information on the equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certain types of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. The enforcement of these requirements should be made more effective by way of enhanced powers granted to the relevant national authorities.

With DNT:0 as consent, a service would fulfill the requirements of the Article 5.3 of the ePrivacy Directive and express the user's consent to storing information on her terminal equipment.

2.1. The nature of consent

The European system knows a clear approach to consent. Consent has to be free, specific and informed. This means that consent is always unambiguous, and when processing sensitive data, explicit. Consent of the data subject is one of the legal grounds for processing. The Art. 29 Working Party insists that it is absolutely necessary to ensure consent cannot be misused. Therefore, where consent is used as the legal ground, it must be sufficiently clear. Consent can be expressed in many different ways, for instance through a statement or an affirmative action, but it should be an essential requirement that it is explicit. To truly enable data subjects to exercise their rights, especially on the internet where there is now too much improper use of consent, requiring it to be explicit is an important clarification of the notion and should therefore not be deleted from the text. Furthermore placing the burden of proof on the controller and introducing safeguards in the context of a written declaration, greatly strengthen the rights of individuals. In addition, the Working Party would like to stress that consent cannot be a valid legal basis if there is a significant imbalance between the position of the parties concerned.

In the Berlin meeting of the Global Considerations Task Force, the question came up what type of consent DNT:0 could be. This is important as the nature of consent determines how much collection can carried out the ultimate thing being the informed and explicit consent.

Art 5.3. conditions consent to the user having been provided with clear and comprehensive information. Recital 66 already indicates that a browser setting could be sufficient. 

2.2 DNT:0 as a standard contract

A good definition of DNT:0 with a standard contract may create a shortcut in two ways:

First it would allow the user to signal consent without being annoyed by opening pop-ups or JavaScript window shades. Because the service receives already a DNT:0 with a header in the first GET request, it can determine that further interaction is not necessary before storing information client - side (on the terminal equipment). This would include all kinds of storage, not only cookies. As HTML5 comes with a big emphasis on distribution and offline processing, the importance of normal client side storage beyond the mere setting of cookies can't be overestimated.

Second, the definition of DNT:0 as a standard contract with very common uses of stateful data would allow for the famous 80/20 solution. Legally, the DNT:0 token would represent the declaration as defined by the Tracking Compliance Specification from the user/client to the service thus delivering legal grounds for processing as defined by the TCS definition of DNT:0. The definition would say that at least those collections and uses are allowed to not preclude further processing in less regulated environments. In the EU, purposes and data classes not mentioned in the standard contract do not have consent and thus remain prohibited unless they have another legal ground for processing. They would then be subject to additional requirements out of scope for DNT. (If we want those additional purposes, e.g. for sensitive data in the sense of Art. 8 of the 95/46EC to be addressable by DNT, we would need a different, higher qualified type of exception stored in the exception store, maybe one can imagine that for version 2.0)

Taking into account that recital 66 allows for the context to be taken into account to determine how informed a consent is and taking into account that the definition of DNT:0 by the Tracking Compliance Specification adds additional information, it can be stated with some confidence that DNT:0 can express consent in terms of Art. 5.3 of the ePrivacy Directive. Note that not taking into account the browsing context would mean that the data controller would have to describe the context in a policy or other document. Given the enormous variety of situations on the Web and within web services, the non-acceptance of context will result in huge incomprehensible privacy policies that not even DPAs will read.

Standard contract as term of the DNT:0 definition was coined by Peter Swire. The idea is to collect the most common data collections and uses in conjunction with cookies. To do this, data classes can defined and a list of purposes can be enumerated. This should allow for:

1. Stateful services
2. Online Behavioral Advertisement (re-targeting being a topic to discuss, whether it is included)
3. Market research (discussions ahead as purpose limitation and out-of-band-consent are interlinked)

3. Using DNT with First Parties

If DNT:0 can be used to express consent and if DNT:1 can be used as an implementation guide for web services, those are things that help to make the regulation in the EU more viable and easier to implement. But the regulation does not distinguish between first and third parties. This means that in the EU, DNT can be as useful for first parties as it already is generally for third parties.

In the Berlin meeting, we noted that making DNT available for first party would require an additional statement in the Tracking Preference Expression Specification concerning first parties. Those additional statements will have to define the optional meaning of the DNT signals for a first party and the optional response by the first party that it also respects limitation to permitted uses. Furthermore, also first parties would need to collect consent to store information on the terminal equipment of the user. This means, first parties must be able to use the exception API and trigger DNT:0 sending to the first party. Justin Brookman suggested the following wording:

Instead of re-purposing DNT:0 as web-wide (or more granular) agreement to a set of less controversial uses (such as first-party analytics, first-party personalization, or audience measurement), we could edit the TPE (and to a lesser extent to allow for *any* party (first or third) to take advantage of the exception-API mechanism to ask for consent if that party believes that adhering to the DNT standard alone will not be sufficient for legal compliance in a particular jurisdiction. Thus, if a first party believes it needs consent to do first-party analytics despite the TCS exemption of first parties from compliance obligations, that first party could call the exception-API to get permission to engage in tracking on its own domain. Or if market research was deemed a permitted use, an audience measurement company could still trigger a call to the API for consent to track around the web even if the TCS allowed for market research.

Allowing first parties to use the full wealth of the TPE mechanism raises additional issues. Namely, the TPE would have to specify how first parties indicate that they honor 3rd party restrictions and only do permitted uses unless they get DNT:0. This would require an additional status message.

4. Service Providers / Data Processors

There are some people wanting to have the service provider matching the definition of data processor in Directive 95/46EC. The Directive's definition is:

Article 2 of Directive 95/46EC: (e) 'processor' shall mean a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller;

The definition in the of the Tracking Compliance Specification

Text from David Singer: Outsourced service providers are considered to be the same party as their clients if the outsourced service providers only act as data processors on behalf of that party in relation to that party, silo the data so that it cannot be accessed by other parties, and have no control over the use or sharing of that data except as directed by that party.

The text above is not consensus yet. A text giving the data processor own rights for data processing not under the control of the data controller will raise a gap. So far, even people of the industry were happy with the processor definition provided the processor can also use the permitted uses for security and financial reporting. A difficult point will be the aggregate reporting from a stream that a single processor acquires from serving a large variety of data controllers. Because there is own benefit and processing in creating statistics out of the entire stream. But it is an interesting use case that should be discussed further with the authorities. Maybe that data de-identified on the fly and put into the statistical buckets is so benign that there is no reason to prevent that from happening.