ISSUE-260: method for validating DNT signal from user

method for validating DNT signal from user

State:
PENDING REVIEW
Product:
TPE Last Call
Raised by:
Jack Hobaugh
Opened on:
2014-07-13
Description:
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0005.html (Comment #2. Also present in some form in comments of Alan, Peter, Brooks, Chris Mejia, David Wainberg, Max, Vivek, Ari, Tim, Mike Zaneis.)


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.
Related Actions Items:
Related emails:
  1. Agenda for December 17 TPWG call (from npdoty@w3.org on 2014-12-16)
  2. Re: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from fielding@gbiv.com on 2014-12-16)
  3. Agenda for December 10 TPWG call (from npdoty@w3.org on 2014-12-09)
  4. Agenda for December 3 TPWG call (from npdoty@w3.org on 2014-12-02)
  5. tracking-ACTION-465: Respond to issue-260 regarding validating dnt signal (from sysbot+tracker@w3.org on 2014-11-19)
  6. Re: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from singer@apple.com on 2014-09-23)
  7. RE: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from michael.oneill@baycloud.com on 2014-09-23)
  8. Re: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from singer@apple.com on 2014-09-23)
  9. RE: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from michael.oneill@baycloud.com on 2014-09-23)
  10. Re: tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from fielding@gbiv.com on 2014-09-22)
  11. tracking-ISSUE-260: method for validating DNT signal from user [TPE Last Call] (from sysbot+tracker@w3.org on 2014-07-13)

Related notes:

For completeness, here are the other last call comments applicable to this issue:

===
Rachel Glasser
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0001.html

The TPE is designed to be express user's choice preference regarding tracking. However, the protocol lacks a method to identify and validate the origin of the signal, which means other variables, (for example routers, antivirus software, browser plugins) may all insert a DNT signal. This signal inserted by this variable is not necessarily reflective of the user's preference. Furthermore, the only companies that would have to honor DNT are those who do not currently have any information about you in the first place. As such, users will have a very difficult time understanding when DNT applies. This will create confusion when users attempt to manage their privacy and exercise choice when it comes to data collection.

===
Alan Chapell
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0003.html

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.

===
Peter B Kosmala (American Association of Advertising Agencies (4A's))
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0007.html

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.

===
Brooks Dobbs
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0009.html

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.

===
Chris Mejia
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0010.html

1. 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.

===
David Wainberg
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0011.html

The signal cannot be verified.

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.

===
Max Ochoa (Turn, Inc.)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0012.html

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.

a. 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?

b. In the case of conflicting preferences between multiple user agents (e.g., toolbar plug-in + browser), which preference wins?

c. 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?

===
Tim Stoute (eyeReturn Marketing)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0014.html

There are technical hurdles associated with the DNT proposal for which
there are no enshrined workarounds in the proposal. For example, since the
DNT HTTP header value can be set by network devices and software, it
therefore does not directly reflect users choice. For example, in the case
of a proxy server setting the DNT signal, there could be hundreds or
thousands of individuals behind the equipment, which is broadcasting a
signal that none of them explicitly chose.

===
Mike Zaneis (IAB)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0015.html

* The origin and validity of the signal cannot be confirmed, thus putting in doubt whether a consumer actually chose to turn it on or whether a company has made that decision for them.
* Legitimate DNT flags should reflect a user's choice to affirmatively turn on that signal. However, the TPE provides no means to ensure who turned on the signal and what point in the supply chain.
* We have already seen extensive "gaming" of the DNT:1 signal, as it is sent by default by some routers, plugins, and other intermediaries that have access to the setting or the HTTP headers.
* There is essentially no cost for intermediaries to turn on the DNT signal, thus companies can utilize this practice for their own profit motive to be seen as "competing on privacy". The signal can quickly proliferate without ever being set by consumers.

===
JoAnn C. Covington (Rocket Fuel Inc.)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0016.html

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.

===
Vivek Narayanadas (The Rubicon Project, Inc.)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0019.html

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.

===
Nadine Stocklin (PubMatic)
http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0020.html

Another concern is that, although the TPWG prohibits any intermediary or agent other than the user from setting a DNT preference expression, a party receiving a DNT signal is not able to discern who set the signal. Therefore, a DNT:1 signal set by an intermediary such as a router, proxy, or anti-virus software, may be honored when the user’s true preference is DNT:0. Thus, though the TPWG wishes that the signal reflect solely the user’s informed choice, the technical spec does not require that. PubMatic is concerned about the very real possibility that these intermediate services might see it as an advantage to advertise that they insert a DNT:1 signal on behalf of their users, as a type of privacy protection. In reality, this would be a disservice to users who have consciously chosen a preference expression, and would impede the ability of servers to accurately read users’ preferences.

Roy Fielding, 22 Sep 2014, 20:54:00

Display change log ATOM feed


Matthias Schunter <matthias.schunter@intel.com>, Chair, Bert Bos <bert@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.325 2014-09-10 21:42:02 ted Exp $