Privacy/TPWG/TPE Last Call Comments
List of commenters
- Anne van Kesteren
- Aaron Williamson, Tor Ekeland, P.C.
- Charles McCathie Nevile, Yandex
- Art. 29 (.pdf)
- Rachel Glasser, GroupM
- Lee Tien, EFF
- Alan Chapell
- Jack Hobaugh, NAI
- Mike O'Neill, Baycloud Systems
- Peter Kosmala, American Association of Advertising Agencies (4A’s) (.docx)
- Lou Mastria, DAA
- Brooks Dobbs, KBM Group
- Chris Mejia
- David Wainberg , Appnexus
- Max Ochoa, Turn Inc.
- Lindayan, Tencent (.doc) (still missing)
- Tim Stoute, eyeReturn Marketing (still missing)
- Mike Zaneis, IAB (still missing)
- Ari Levenfeld, Rocketfuel
- Vivek Narayanadas, Rubicon Project (.pdf)
- Addison Phillips, W3C I18N WG
- Julian Reschke
Comments by topic
Editorial comments
Top-level origin concepts
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#processing-model needs to be rephrased in terms defined by HTML. E.g. "top-level origin is the domain name of the top-level document origin of this DOM: essentially the fully qualified domain name in the address bar." is all kinds of wrong. An origin is more than a domain name. A top-level document means nothing. Did you mean top-level browsing context? What's a fully qualified domain name? What does that mean for a data URL?
"The document origin of a script is the domain of origin of the document that caused that script to be loaded (not necessarily the same as the origin of the script itself)." A document's origin is already a defined concept. Let's not redefine it. And for scripts you want to look at settings objects.
-> David
Typos
By Aaron Williamson, Tor Ekeland, P.C.
I noticed a couple of typos in this document[1], one of which is substantive.
1) Section 5 ("Third Party Compliance"), says:
Outside the permitted uses and explicitly-granted exceptions listed below, a third party to a given user action *MUST* collect, share, or associate with related network interactions any identifiers that identify a specific user, user agent, or device. For example, a third party that does not require unique user identifiers for one of the permitted uses *MUST NOT* place a unique identifier in cookies or other browser-based local storage mechanisms.
I believe the first "MUST" is intended to be "MUST NOT."
2) In the definition of "Graduated Response" (2.13), the word "is" is missing: "A graduated response [is] a methodology..."
Priority of local legislation
By Art. 29 (.pdf)
The Working Party suggests including the following normative language in the Draft TPE Specification, Section 2, Terminology: This specification does not override regulatory terminology, and as such, compliance with this specification does not mean compliance with regulations.
Accessibility
By Art. 29 (.pdf)
There are users for whom giving prior consent is not obvious. To address users with special needs, the Working Party suggest to add the following text to section 7.7 ‘User interface guidelines’: Special consideration must be given to ensure that no group of web users are treated less favourably or are otherwise discriminated against, for example, as a result of a disability. This will be particularly important for those devices which have limited, or no, display and configuration capabilities.
User granted permissions
By Mike O'Neill, Baycloud Systems
I would like to ask that the term User Granted Exception be changed to User Granted Permission. The term “exception” is currently in widespread use in computer programming especially in Java, C/C++/C# and JavaScript as a term for a type of control structure for program flow. This term will cause confusion amongst implementers who will probably defer to the less confusing but ugly UGE epithet.
User Granted Permission is easier for users to understand and less annoying for developers. It can be shortened to Permission and the meaning is still clear. It also aligns well with other terms in the document like Permitted Use.
HTTPbis draft references
Please update the HTTPbis draft references (the RFCs have been published a few weeks ago).
Section 5.2 use of %31 and %30 for characters 1 and 0
By Addison Phillips, W3C I18N WG
Section 5.2 use of %31 and %30 for characters 1 and 0
[Editorial][Nit] In this section, the characters "1" and "0" are referred to using ABNF %31 and %30 respectively. Generally when referring to characters, we prefer to see the Unicode U+NNNN notation used also so that it is clear that you are referring to the character value and not a byte value.
Section 5.2: DNT-extension excludes should spell out control, space, double quote
By Addison Phillips, W3C I18N WG
In Section 5.2: The names of the characters for control, space, and double quote should be spelled out and/or include the Unicode code points (U+0020 SPACE, for example). The abbreviations CTL, SP, and DQUOTE are not necessarily clear.
Section title for 6.2.7 doesn't match earlier description
By Addison Phillips, W3C I18N WG
Section 6.2.7: "Potential Content" doesn't match the earlier description "tracking only if consented"
Technical comments
DoNotTrack API feedback
1. This API needs to be on window.navigator. No further polluting of the global object. (This is also how it appears to be implemented.)
2. It needs to return an string enum rather than a string. (With values "", "yes", and "no" or some such.)
3. It should not return null. No need to vary type.
4. It should be exposed in workers.
Exception API's feedback
Both http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-javascript-api and http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-ww-javascript-api are inadequate. They need to allow for an asynchronous permission check. In other words, return a promise.
Also, within platform APIs we call "URI" URL.
You have not defined cookie-like domain string.
To back up a bit, has this API been discussed with people familiar with other permission APIs? We generally avoid things like "explanationString" or "siteName" as they are open to abuse. Also, putting "String" in the member name seems redundant.
This API does not seem ready at all. Are there any implementations of it?
Answer by Adrian Bateman: Yes. It is implemented in IE11. The design of the API was explicitly chosen to not use a promise pattern. Given the expectation that few browsers would provide a UI and that exceptions could be revoked soon after the UI prompt it is incumbent on sites to check what exception status exists using the query methods.
ABNF to define a JSON based format
The use of ABNF to define a JSON based format is ultra-fishy. Don't. Really. Seriously. Just state that the format *is* JSON, define the extensibility model (I'll assume "must-ignore"), and define the individual field names and values *after parsing as JSON*.
ABNF for extension is wrong
Except it's not even a subset, it's a “schema” (plus if you follow the ABNF, you'll produce invalid JSON, re. extension)
Roy says:
extension = object
should be
extension = member
Non-ASCII extensions
By Addison Phillips, W3C I18N WG
Non-ASCII characters are not permitted in extensions. There is a note:
The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (section 6.5 Tracking Status Representation). At most one DNT header field can be present in a valid request [HTTP].
It's unclear why this restriction exists? Non-ASCII characters are useful in many contexts and they work in a JSON string (they can be encoded further using \u escape, but don't have to be). The limitation to ASCII-only may be helpful for other reasons, of course, but these are no spelled out. Can you clarify why extension names have a limited character set?
IRI/non-ASCII not permitted
By Addison Phillips, W3C I18N WG
Section 6.3.2: The grammar doesn't allow %, so the path to the DNT value cannot include non-ASCII characters that are percent encoded. Neither can the path be an IRI or non-ASCII string value. A tracking resource might be named for some actual resource that uses non-ASCII characters in its name. Not permitting non-ASCII directly or via URI percent escapes limits what can be represented and this appears to represent a problem later for features such as requesting the status for a specific resource.
Section 6.4.2: restriction to "URI-safe characters"
By Addison Phillips, W3C I18N WG
Section 6.4.2: Use of "URI-safe characters" (non-ASCII support). Since a site may wish to associate the tracking status with specific resources and since these resources might be named using non-ASCII characters, this appears to limit usage in a non-helpful way? This is similar to our comment 350.
Request for additional features
Automatic expiration of a tracking preference
By Art. 29 (.pdf)
With regard to some parallel initiatives, such as notice-and-choice programs, the Working Party acknowledges that they can function as supporting measures to remind users that they can withdraw their tracking preference at any time. But the Draft TPE Specification currently lacks a building block that ensures the automatic expiration of a tracking preference. Under European data protection law, personal data must be adequate and accurate, and stored no longer than necessary. In order to comply with these requirements, the introduction of an automatic expiration feature is necessary to allow users to exercise effective control. Therefore, the Working Party recommends adding this requirement to the building blocks.
Public statement for TSVs
By Lee Tien, EFF
To the extent that one objective of the TPE standard is to ensure that a server’s communication of its tracking status value is enforceable under Section 5 of the FTC Act or another similar regulatory regime, the TPE specification should require the server to describe within its privacy policy or other public-facing documents the meaning of its TSV and how the server responds to users’ tracking preferences.
The Last Call Document already requires an analogous explanation in a similar context.
"6.2.8 Disregarding (D)
A tracking status value of D means that the origin server is unable or unwilling to respect a tracking preference received from the requesting user agent. An origin server that sends the D tracking status value must detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from specific user agents (or via specific network intermediaries) that are deemed to be non-conforming, might be collecting additional data from specific source network locations due to prior security incidents, or might be compelled to disregard certain DNT requests to comply with a local law, regulation, or order."
It therefore appears reasonable and within scope of the TPE specification to require the same level of public, human-readable disclosure as to a server's response policy when it respects a tracking preference.
Obviously, servers may respond in different ways depending on the nature of the incoming request; the major variations would, in our view, be sufficient. The point is that there must at least be a public representation of the response policy.
Validation of DNT signal
By Alan Chapell
The TPE does little to ensure the validity of a DNT signal Imagine attempting to board a plane at an airport where anyone with a computer could instantly alter flight patterns; imagine a marketplace where credit card companies were unable to authenticate their cardholders; or think about driving a car where anyone could use a police siren to push their way through traffic on the city streets. We sometimes take for granted how important it is to trust the validity of signals in life. If you can¹t trust the signal, the entire framework is left open to question. And that¹s exactly where we are with DNT. Per the TPE, there¹s no requirement on user agents to ensure that the DNT signal is valid. And as a result, there¹s no mechanism for anyone in the digital media ecosystem to trust any DNT signal they receive. One of the largest browser manufacturers has already been reported to have violated the spirit of the TPE - so this isn¹t mere speculation. And then there are any number of plugins, routers, anti-virus software and other entities that are turning on DNT without the user¹s knowledge. As a result, the entire framework is open to question. In any other group, this issue would result in a full stop until the questions are addressed. Conversely, this working group treats this fundamental flaw as a bug that may (or may not) be addressed in future revisions a bizarre outcome to say the least.
_______________________
By Peter Kosmala, American Association of Advertising Agencies (4A’s) (.docx)
The specification lacks a reliable method for validating and ensuring that each DNT signal is set as the result of an actual, informed choice by the end user. This means that routers, antivirus software, browser plugins, proxies, or ISPs, can all insert a DNT signal into the browser’s HTTP request, and the recipient server has no way of knowing whether it reflects the user’s choice or that of another entity entirely. That is not an authentic expression of consumer preference. Instead, it will create confusion when users attempt to manage their privacy and exercise their privacy choices relating to data collection.
_______________________
By # Jack Hobaugh, NAI
The technical approach of the TPE lacks a method by which the origin of the DNT signal can be validated to ensure that the signal was set as the result of an informed user choice. The stated goal of the TPE protocol “is to allow a user to express their personal preference . . . .” “The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.” (TPE Section 4). NAI agrees with this stated principle but the TPE does not provide the necessary requirements for enforcing this principle within the protocol or for determining a rogue DNT signal. Without a locked down DNT signal, the server cannot determine whether the DNT signal is a valid signal. NAI respectfully requests that this issue be addressed before moving forward with the TPE.
_______________________
By Brooks Dobbs, KBM Group
Chairs have communicated that W3C rules dictate that any MUSTs used in the specification must be testable. The primary goal of this specification is to communicate a user's preference with respect to Tracking. Unfortunately, the specification in its current form allows for user preference signals that are not realistically testable. While it is true that a UA may test the setting it maintains internally, it cannot test the preference received by an origin server, nor can the origin server test if the signal it received is in keeping with the actual preference of the user or even the preference recorded by the UA. Current market implementations show this to be beyond a hypothetical problem. The middle man alteration of signals in the market today and the failure for their to be a technical means for either party to have the ability to verify a common understanding of user preference is a fundamental flaw.
In addition to the injection of signals by the intermediaries, the TPE’s lack of more specific guidance to the UAs with respect to how to ascertain a user’s preference also makes testing that preference against the protections offered by any individual compliance regime nearly impossible. End users are unlikely to be aware of the complicated definition of “Tracking”, its exceptions (which may vary by compliance regime) and its scope with respect to covered parties. Where it is likely that users will have wide ranging expectations of what a choice means, testing any given signal’s meaning with respect to a given compliance regime may not be possible.
_______________________
By Chris Mejia
Entities receiving the DNT:1 signal cannot rely on its validity. Because there is no strict requirement in the TPE on how and when user agents set/send DNT signals on behalf on properly informed users, the signal itself cannot be relied on as a consistent message (an expression of individual user choice) to those who receive it. We have already seen examples of DNT:1 being sent by default, where users did not take an affirmative action to enable its sending, and where in most cases, the user had no idea it was being sent‹ this is simply unacceptable for a standard that proposes user choice as one of it¹s core tenants. In order for this specification to be successfully adopted, entities receiving the signal must have confidence that the signal received represents an individual user¹s properly informed choice. This requires an educational component‹ users must be informed (transparency), and that educational component must be validated by the specification so that those receiving the signal can differentiate when it¹s been set/sent appropriately, vs. the the ³noise² created by user agents that insist on sending it by default for all of their users. Furthermore, because there is no real cost for user agents and intermediaries to ³turn-on² DNT:1, we can see that it¹s being insincerely deployed (under the guise of user protection) as a competitive tort in commercial competition wars, rather than as a functional tool for individual user choice. By allowing unfettered flooding of un-checked DNT signals into the wild, the actual user-set/sent DNT signals will become effectively lost signals in the noise of machine-generated signals‹ this practice of bastardizing the signal does not help to advance user privacy controls, and is thus inconsistent with the TPWG Charter.
_______________________
By David Wainberg, Appnexus
It is non-controversial that for a signal to be valid it must reflect a user's informed and explicit choice. However, the TPE provides no mechanism for a recipient server of a DNT:1 signal to ensure that a signal is valid. Experience already demonstrates that there will be a high rate of invalid signals as a result of the signals being set by default or injected by intermediaries. The high rate of invalid signals, with no means to distinguish them, will pollute the space, undermine the meaning of the signal, and make it impossible for implementers to support the specification.
The W3C, the working group chairs, and the primary authors of the specification are indifferent, and seemingly willing to accept of a high rate of invalid signals, regardless of the source or user intent, regardless of the business impact, and regardless of the overall negative impact on the Internet. (It's worth noting that nearly all of the working group, including the primary authors of the specification and the co-chairs, would not be subject to DNT under this specification's definition of tracking, so would not be negatively impacted by a proliferation of invalid signals.)
_____________________
By Max Ochoa, Turn Inc.
The TPE does not guarantee that the do not track (DNT) preference is that of the user. It is impossible to discern if the DNT state was set by the user or by an intermediary (e.g., plug-in integrated into browser, separate software, operating system, ISP or wifi provider, home routers). Without this guarantee, the entire framework fails.
- If an intermediary alters the preference originally set by the user (e.g., from 0 to 1, or 1 to 0), how can downstream recipient servers know?
- In the case of conflicting preferences between multiple user agents (e.g., toolbar plug-in + browser), which preference wins?
- In the case of conflicting preferences between multiple user agents on the same device (e.g., browser_1 + browser_2), which preference wins for information collected at the device level?
_____________________
By Vivek Narayanadas, Rubicon Project (.pdf)
As others have observed, the TPE provides no way for responding servers to confirm that a received DNT signal was actually set by the user agent. The lack of any available authenticating mechanism means that a responding server must respond to a DNT signal blind, simply assuming such a signal was intentionally sent by the end user. Such a result is at odds with the stated intent of the TPE, which is to empower end users (and not other third parties) to informedly state a preference as to tracking.
Without any authentication mechanism, intermediaries in the data stream between the user agent and the responding server have the ability and incentive to insert themselves into the data stream and state a preference purportedly on behalf of a user agent. ISPs, routers, add-ons, etc. have incentive to change all DNT signals to “1” in order to position themselves in their respective marketplaces as more “privacy-friendly” regardless of whether the user is even aware of the third party’s practice, and regardless of the user’s actual tracking preferences. Rubicon Project requests that the Working Group add some authentication mechanism to the TPE—for example, by requiring the use certificates to confirm the user agent’s DNT selection, or a central repository storing user agent preferences—to ensure that responding servers honor the end user’s actual preferences, rather than the skewed preferences of third parties trying to game the system to their benefit. Such an authenticating mechanism will also allow third parties receiving a DNT signal to ensure that the actual signal-setting agent is properly presenting the end user his or her choices, in accordance with the TPE, rather than making the decision unilaterally for the end user.
_____________________
By Ari Levenfeld, Rocketfuel
The specification also contains no mechanism to ensure that DNT signals actually do reflect consumer choice. There is no mechanism to prevent multiple contradictory signals from being sent, and no means to identify whether a DNT signal was set by someone other than the consumer. Thus, it is impossible for service providers receiving the signal to know whether the signal reflects informed consumer choice. Under the TPE, a DNT signal may be communicated by a browser, a browser plugin, router or other piece of software that automatically sets or communicates a DNT signal without consumers’ knowledge or consent. These signals may be set by vendors for their own competitive purposes and have nothing to do with an expression of consumer choice. Thus, the TPE provides multiple avenues for abuse of Do Not Track browser settings without serving, and even to the detriment of, consumer interests.
Making the support of UGE a MUST requirement
By Chris Mejia
This TPE does not require user agents to support the user-granted-exception (UGE) protocol developed by this TPWG. The decision to not make UGEs a required technical requirement of user agents that wish to comply with the DNT specification will create an inconsistent user experience across the ecosystem, causing confusion, but more importantly, taking away the choice of an informed user to make granular exceptions to his/her DNT preference. User choice should be well balanced in this specification‹ just as we make daily exceptions to our overriding personal presets, users of DNT will want to make certain exceptions to their overriding DNT:1 choice. Forcing a user into an ³all or nothing² proposition to set/send DNT:1 does not help to advance user privacy controls, and is inconsistent with the TPWG Charter.
_______________________
By David Wainberg, Appnexus
The protocol cannot succeed if it does not provide elements necessary for a dialog between users and servers. The signal is meant to express a user's preference. Currently the TPE requires UAs to offer only a binary choice, but user preferences are typically not binary, and may vary depending on context and the parties involved. To remedy this gap, a recipient server must be able to request and reliably store a user granted permission, but the TPE currently does not provide for this.
Guidance as to when a server must respond
By Vivek Narayanadas, Rubicon Project (.pdf)
The TPE does not provide any guidance as to when a server must respond to a valid GET request for tracking status. Timing may not matter for many parties in the ecosystem, but it is particularly important for third parties like Rubicon Project that operate or use automated exchanges that allow real-time bidding. Because only a bid winner can adequately respond to the GET request, the specific tracking status resource (“TSR”) response will change depending on whether the GET request is sent immediately upon loading a page (i.e., before bidding on an impression is complete), or instead is sent after bidding is complete and the winner is determined. Rubicon Project is concerned that such a system could actually increase end user confusion and uncertainty, by providing different responses at different times. To the extent that user agents, plug-ins, or add-ons rely on the TSR to inform the an end user of a responding server’s tracking practices, the fact that the content of the notice to the end user would change depending on the timing of the request could undermine consumer confidence in the DNT mechanism and actually cause consumer confusion. Accordingly, Rubicon Project requests that the Working Group include some guidance as to how responding servers should deal with such timing issues.