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.
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:
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)
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:
We could submit the short term storage under this exception.
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
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.
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.
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.
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.
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.
If local law requires data collection, it provides the legal reason for collection, thus this permitted use is not problematic.
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)
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.
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.
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:
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.
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.