W3C

Site Navigation

Nearby

Results of Questionnaire [Call for Objections] Tri-part choice requirement for user agents

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: w3c@aleecia.com,mts-std@schunter.org,npdoty@w3.org

This questionnaire was open from 2012-08-15 to 2012-08-29.

17 answers have been received.

Jump to results for question:

  1. Objections to Option A: Silence
  2. Objections to Option B: Three choices with equal effort

1. Objections to Option A: Silence

Option A: Silence

(Keep just the existing text that MUST reflect the user's preference etc. User agents -- general purpose browsers or extensions -- do not have to provide a DNT:0 option that is equally easy to turn on as DNT:1.)

If you have an objection to this option, please describe your objection, with clear and specific reasoning.

Details

Responder Objections to Option A: Silence
Shane Wiley To provide a fair balance in the marketplace consumers should be provided all possible options when activating DNT. By limiting the options and not providing DNT:0 as a clear choice, the resulting standard is biased towards the activation of DNT and doesn't give equal weight to exceptions. This bias will undermine the validity of the standard and lower adoption rates.
Brooks Dobbs Per the spec "The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP". Quite simply, this goal is not achieved where only one of the two fundamental choices is offered.
Roy Fielding I am assuming that this poll only refers to DNT:0 as a global option (meaning send DNT:0 to all websites); i.e., this decision should not have an effect on whether the exception API is required to implement.

If we had a definition of DNT:0 that would be effective for compliance with EU law (enables consent for a specific set of purposes), then I would object to Option A for general-purpose browsers because being able to provide such consent is exactly what the EC requested as a solution to the ePrivacy Directive for citizens that do not want to be annoyed by consent dialogs at every site. However, I consider this objection to be weak because UAs are under no obligation to be useful within the EU and, if the option is useful to their users, then I would expect the UAs implement it voluntarily.

I do not object to Option A for browsers or extensions where the choice of using that UA implies that user's preference for DNT:1.

Also, I do not think that the specification should include a requirement on user agents that is inconsistent with the actual or planned implementations of user agents that wish to comply. If none of the major browser implementers indicate a willingness to implement such an option, then I would consider that a stronger objection.
David Singer
Jeffrey Chester
Sid Stamm
Ian Fette I believe that keeping the existing text is insufficient. In particular, I believe that we need to make it clear that user agents must provide functionality for DNT to be "on" or "off". The notion of a distinction between "unset" and "off" is a nice one, but is one that no browser has successfully come up with UI for. From looking at their bug tracker, Mozilla is certainly trying but frankly it seems to be a battle to come up with strings that convey the distinction to users in a meaningful way, and it's very hard to understand why a user would ever choose "unset". No other browsers seem to be showing signs of implementing tri-state choice mechanisms. We (google) have gone through the exercise of trying to come up with a good UI and set of strings, and having gone through that, do not believe that forcing the distinction between "off" and "unset" on the user via a tri-state UI is a good idea. We do believe that it's important users be able to exercise a choice to turn DNT on or off, and so the existing text is not necessarily sufficient in that it would allow a UA to only have an "on" state, but do not want to go as far as to require three distinct states configurable in the UA, merely two.
David Wainberg I object to Option A for the following reasons:

If the objective of DNT is to allow a user to express their preference about data collection and use, then only option B is effective and consistent with our objectives. Only in the context of the other DNT options, adequately described, would the choice to turn DNT on make sense to the user, and only in this context can users even arguably make an informed choice. Option A does not accomplish this.

While Option B does not alleviate concerns that users may not be able to understand DNT, Option A -- silence -- seems to ensure that users can't understand the alleged choices they are being directed to make.

Silence also seems to leave too much discretion for user agents, a serious concern for most commercial stakeholders in the online ecosystem. UA's should not be allowed to limit, discourage, or inhibit user's choices. We should ensure that UA's are not limiting information about or access to some of the options, and thereby discouraging users from making informed choices. We can do this by requiring, as in Option B, that UA's provide equal access to all of the DNT options. Even the perception that user agents are intentionally skewing users' choices will likely ensure that the standard is not widely adopted.

Finally, in contrast to Option A, I can see no downside to presenting users with more transparency and more choice in this case. Given the opportunity, we should err on the side of requiring that all options be fully available to users.

Clearly, Option A is not adequate for meeting the objectives of the standard, and therefore should not be the choice of the working group.
Adrian Bateman We are considering this question only in the scope of the part of ISSUE-149 related to the tri-part choice or not. We may make other proposals for parts of ISSUE-149 depending upon the outcome of this survey.

Option A (silence on the options that may be presented) is Microsoft’s preference.
Haakon Bratsberg
Alan Chapell This option does not give enough granularity of choice to the User.
Brendan Riordan-Butterworth The current draft Section 3.2 (http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#def-user-agent) “User Agent” defines a user agent as “any of the various client programs capable of initiating HTTP requests.” A user agent may include a rendering engine (as in, a web browser), but needn’t (as in, CURL or WeGet). A program that modifies the HTTP requests made by a user agent (be it a browser plugin, proxy server, or other program) but that does not initiate the HTTP request is not a user agent. This means that Fiddler2 (debugging proxy) and AVG (with their opt-out plugin) are not user agents. This means that the tri-part choice requirement only applies to tools like the web browser, and not to plug-ins that simply modify existing HTTP requests.

This means that the explanatory text for Option A is flawed, as it indicates a different definition for user agent, specifically “User agents -- general purpose browsers or extensions”, and that therefore the discussion around this option has been misinformed. This is the first part of the objection.

The current charter (http://www.w3.org/2011/tracking-protection/charter) of the Tracking Protection working group is to create “specifications for a simple machine-readable preference expression mechanism ("Do Not Track") and technologies for selectively allowing or blocking tracking elements.” While Section 6 (http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions) “User-Granted Exceptions” enables the selective allowing of blocked elements, it is not an “exceedingly straightforward way for users to gain transparency and control over data usage and the personalization of content and advertising on the web” (Section 2 (http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#scope-and-goals) “Scope and Goals”, Substantial Outcome #2) – specifically, in those jurisdictions where opt-in is required, a user would need to enabled DNT:1 and then also configure exceptions for all visited sites.

This means that Option A creates a situation where compliancy of user agents means implementations that do not meet the goals laid out in the working groups Charter and in the Tracking Compliance and Scope specification. This is the second part of the objection.

The current principles of the W3C (http://www.w3.org/Consortium/mission#principles) specify a “Web for All” that “enables human communication, commerce, and opportunities to share knowledge.” By not requiring that DNT:0 option that is equally easy to turn on as DNT:1, a user behavior that limits commerce is promoted, which is counter to the W3C principle with regards to commerce. Additionally, the deliverables of the Tracking Protection working group (http://www.w3.org/2011/tracking-protection/charter.html#deliverables) are to create a specification that promotes specific technical behavior (“defines the technical mechanisms”), and not specific human behavior (IE, that the user select DNT:1 and not select DNT:0).

This means that Option A creates a situation where a specific user behavior is promoted, which is counter to both the current principles of the W3C and the deliverables of the Tracking Protection working group. This is the third part of the objection.
Ninja Marnau
Peter Eckersley
John Simpson Consumer Watchdog strongly supports the Option A: Silence
Justin Brookman
Jonathan Mayer

2. Objections to Option B: Three choices with equal effort

Option B: A user agent MUST require equal effort to configure their agent to each of a minimum of three choices for a Do Not Track preference: 1, 0 or unset.

(This would add to, not replace, existing requirements.)

If you have an objection to this option, please describe your objection, with clear and specific reasoning.

Details

Responder Objections to Option B: Three choices with equal effort
Shane Wiley Fully supportive of this approach.
Brooks Dobbs While I "favor" this option, I believe that it is not phrased correctly.

1) It does not make sense (and would not be consistent with the spec as currently written) that an unset option would require the same effort to configure as an affirmative statement of preference either 1 or 0. Requiring unset as an equal option would require a fair bit of redrafting as well as differentiating it from 0, which I suspect will not be an easy undertaking for many in the group.

2) With respect to the "effort" required to set 1 vs 0, I would argue that this will be very difficult to address without getting into UA design, but with that said the question really isn't about the physical mechanism that denotes choice but rather the underlying requirement that either choice (1 or 0) must reflect a user's preference relative to the manner that "allow[s] each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties". This presupposes that whichever election is made can only be valid to the extent which the user has been provided a basis for understanding how each choice may cause a server to adjust its behavior. This is where "effort" must be expended. Simply offering two alternatives "Tell websites I do not want to be tracked" or "Tell websites I don't mind being tracked" does NOT accomplish this requirement irregardless of the relative ease of finding or checking either box.

A requirement that implies obtaining a 1 preference MUST be as onerous as obtaining a 0 preference does not make sense, because they each cause potentially different outcomes.

All three options MUST be equally available, but the "effort" to obtain a preference is determined by what that preference implies relative to the user making such election.
Roy Fielding I object to the wording here, though not the intent. Unset shall require no effort (it is the default). I think it should be:

A user agent that offers a configuration option to enable DNT MUST allow the user to choose equally from DNT:1 or DNT:0 in each context in which that configuration is offered.

This is not necessarily a tri-part option; it is two binary options: unset/set and then (if set) 0/1. That is common in all UA configs and not a burden to implement.
David Singer We object; we believe that this option mandates a significant complication in the user-interface, and do not see a matching compelling reason to compel all UAs to offer this choice. Turning an option on or off is a 'toggle', which can be expressed in many simple UIs (checking a check-box, enabling a menu item, and so on). Tri-state UIs are more complex both to offer and explain.

We do not object to allowing UAs to offer it; we object to requiring that they offer it.

We also believe that the specification should be defining a protocol, and not designing either user agents, or web sites, and that this kind of mandate would represent a significant expansion of scope, which, if adopted, should also place in scope mandating the behavior of sites with respect to users.

DNT:0 was introduced in order to satisfy the exception mechanism; though it may serve as a general user-preference there is no need to mandate it. Even in hypothetical jurisdictions where 'unset' means some kind of 'less tracking', the availability of DNT:0 as a general option (e.g. to avoid prompting the user for exception on many web sites) should be a question of product differentiation, not specification mandate. The only possible reason would be a hypothetical general (global) rule that 'unset' means 'less tracking' and I do not see industry accepting that.

We are currently mostly silent on what both sites and user-agents must offer to or tell users, and we believe strongly that this is correct; define the protocol and what it means, not the user experience.

Finally, the charter only envisages "guidelines that define the user experience or user interface", not mandates.
Jeffrey Chester This proposal does not help users at all.
Sid Stamm We believe that placing such requirements about UI presentation on UAs causes a number of problems.

First, it reduces the ability for UAs to design a UI in ways that benefits our users. We want to be able to implement the TPE specification and need flexibility in UI design to do this -- we must be able to change our UI if we find that we can design a better way to elicit our users' preferences.

Second, this requirement excludes simple single-purpose tools that have no (or limited) UI, and moreover would prohibit all existing deployed DNT implementations -- even those being embraced by Web users today.

Third, the language as written adds an ambiguous, untestable requirement that leaves the spec open to a wide variety of interpretations; this could result in some groups claiming an implementation is compliant and others claiming the same implementation non-compliant. This conflict risks an even worse experience for users, or having their preferences ignored. We would like to avoid this.

In particular, we do not understand how to measure if something is "equally easy to exercise" short of standardizing UI implementation details, which is out of scope for the working group, and which we would strongly oppose, for reasons stated above.

Fourth, the charter says that the TPE spec "... defines the technical mechanisms for expressing a Do Not Track preference, for example as an HTTP header or a DOM property. It may include mechanisms for sites to signal whether and how they honor this preference." This does not include representation to users; it is a protocol specification and should only describe the structure of communication between user agents and web servers.

Fundamentally, the goal of this new language is to enforce that a DNT signal actually represents user choice. We already have that requirement, and making the specification more ambiguous or specifying UI design is unnecessary. This type of UI requirement is not part of the protocol, and introduces risk to a successful deployment so it should be left out of the TPE spec.
Ian Fette I believe that keeping the existing text is insufficient. In particular, I believe that we need to make it clear that user agents must provide functionality for DNT to be "on" or "off". The notion of a distinction between "unset" and "off" is a nice one, but is one that no browser has successfully come up with UI for. From looking at their bug tracker, Mozilla is certainly trying but frankly it seems to be a battle to come up with strings that convey the distinction to users in a meaningful way, and it's very hard to understand why a user would ever choose "unset". No other browsers seem to be showing signs of implementing tri-state choice mechanisms. We (google) have gone through the exercise of trying to come up with a good UI and set of strings, and having gone through that, do not believe that forcing the distinction between "off" and "unset" on the user via a tri-state UI is a good idea. We do believe that it's important users be able to exercise a choice to turn DNT on or off, and so the existing text is not necessarily sufficient in that it would allow a UA to only have an "on" state, but do not want to go as far as to require three distinct states configurable in the UA, merely two.
David Wainberg
Adrian Bateman Microsoft objects to a requirement that user agents MUST show three choices. We see no reason to require implementers to always support these options (although we have no objection to user agents choosing to offer these three options if they wish to).

Requiring three options adds complexity to the way options are presented to users in the UI. As David states, an on/off setting is intuitively denoted with a checkbox or similar control. Both browsers and web sites should be free to innovate in how to obtain consent without being tied to a particular set of options by the specification. Being this prescriptive about both user agents and web sites strays too far into dictating user experience, which we expect may be refined and improved over time.

Microsoft has consistently opposed constraining innovation by adding this type of UI requirement to W3C platform specifications. If somebody wishes to write a separate “best practices” guide for Tracking Protection User Interfaces then they may do so but this should not be part of the normative specification for implementing DNT.
Haakon Bratsberg
Alan Chapell
Brendan Riordan-Butterworth
Ninja Marnau I object the current wording of option B.
The wording "equal effort to configure" does not reflect that the UA provider has considerable more effort to explain to the user the meaning and outcome of DNT:0 compared to DNT:1. To make an informed choice or give meaningful consent the user must be enabled to get information on what it could mean to opt in into tracking if he wants to. Therefore, for the UA provider and interested user it is not equal effort to configure these three options - organisationally (though it may be technically the same effort).
My concern is that the current wording may imply this.
Peter Eckersley We don't like Option B. We're OK with Mozilla using 3-state (anyone can under the current approach) but it's not obvious why it needs to be in the standard and why every browser other than Mozilla should be out of compliance because it doesn't do 3 states. In the US no DNT header effectively = DNT:0. In the EU, user-agents need to be able to send DNT:0 to allow tracking, and they will.

Also, notions of symmetry or equality or neutrality seem weird in the UI context. I look at my Safari browser and under "Privacy" it has these "Block cookies" options: (1) from third parties and advertisers; (2) always; (3) never. My version of Chrome has more complicated privacy settings, with "(recommended)" and so on. Neither browser is "symmetrical" or "equal" in how it presents choices to the user. Obviously there are issues of "what do users want" combined with "what's good for our business"; a formal criterion like equality doesn't seem to serve either.
John Simpson Consumer Watchdog strongly objects to option B, requiring three choices: 1, 0, or unset.

Since Do Not Track discussions began the goal was always about how the user through the UA would simply convey the user's preference not to be tracked.

The FTC, for example offered five principles for an effective Do Not Track system:

"First, a Do Not Track system should be implemented universally to cover all parties that would track consumers. Second, the choice mechanism should be easy to find, easy to understand, and easy to use. Third, any choices offered should be persistent and should not be overridden if, for example, consumers clear their cookies or update
their browsers. Fourth, a Do Not Track system should be comprehensive, effective, and enforceable. It should opt consumers out of behavioral tracking through any means and not permit technical loopholes. Finally, an effective Do Not Track system should go beyond simply opting consumers out of receiving targeted advertisements; it should opt them out of collection of behavioral data for all purposes other than those that would be consistent with the context of the interaction." -- Page 53, Protecting Privacy in an Era of Rapid Change

In other words, a UA that meets those criteria to send a DNT 1 message should be deemed compliant with the specification. We have a consensus that it should not be enabled by default.

Should a particular UA opt to offer the ability to send DNT 0, that's fine, they MAY do it. It MUST NOT be a requirement. Mandating a particular UI is beyond the WG's scope and this option goes down that slippery slope.

We should be designing a spec that offers the user the ability to simply send the Do Not Track message. It seems extremely unlikely that users will take advantage of sending a "I want to be tracked everywhere, by everyone, all the time" option. DNT: 0 as I understand it, is designed to facilitate particular exceptions.

Sending a global DNT:0 is probably meaningless. In the U.S. companies can track when there is no header. In Europe a global DNT: 0 would be an inadequate form of consent.

Nothing in the spec would prevent a UA from choosing to offer a global DNT: 0. It seems to me the burden is on those who want to mandate it to explain why it's a MUST.

In sum a UA that simply offers the ability to send a persistent DNT:1 when enabled -- and is not enabled by default -- is all that the specification MUST require.
Justin Brookman Requiring that user agents offer equally weighted choices for Do Not Track is unduly presriptive and would impose needless burdens on user agents to present an option to users that they are unlikely to want. This working group was created in response to public calls for a persistent, global mechanism for users to convey to websites that they do not wish to be tracked. As far as I am aware, there has been no parallel call for for users to be able to send a persistent message to sites that they want to allow all tracking. While I am fine with standardizing such an instruction, mandating that users must be presented with an option to persistently allow tracking whenever they are offered the choice to send a Do Not Track signal would for the most part only clutter user interfaces and annoy users.

Further, the standard currently envisions that DNT:1 may be set when a user makes a pro-privacy selection, such as installing a Pro-Privacy Browser or configuring a global pro-privacy setting. Apple, for example, recently announced that it would set DNT:1 to be sent whenever a user engages "Privacy Mode" on a device. It seems facially absurd to mandate that the maker of any privacy tool must also offer an equally weighted "publicness" tool or setting that would convey to the world a preference to be tracked. Such a requirement would impose unnecessary costs on developers and deter the development of privacy tools.

It is also not clear how 1, 0, and unset can be equally weighted where *something* must be the default, unless the working group is going to mandate a first-run wizard for any UA that could send a DNT header. Again, while this could result in more users setting DNT:1 signals (arguably a positive result for privacy), it is overly prescriptive to user agents who may simply wish to make available DNT tools for the users who seek them out.
Jonathan Mayer For the following reasons, I strongly object to mandating a three-way universal DNT choice.

1) There is no apparent use case for a universal "DNT: 0" signal. In the United States, there already is no prohibition on tracking. In the European Union, policymakers have repeatedly indicated that a universal signal lacks sufficient specificity to establish opt-in consent. A universal "DNT: 0" would, in fact, be a full step backwards in facilitating ePrivacy Directive compliance: websites could no longer rely on the in-band exception mechanism for opt-in consent, since a "DNT: 0" signal might arise from a browser's universal setting. (One engineering fix: distinguish between a universal "DNT: 0" and an exception "DNT: 0.")

2) Surveys have not demonstrated any sizable user demand for a universal "DNT: 0" signal. How many consumers do you know who would choose "I'm totally cool with anyone tracking me, anywhere, all the time"? Similarly, policymakers who have backed Do Not Track have consistently emphasized the component that would stop tracking.

3) The proposed language gerrymanders a particular - and bad - user interface. Three-way options aren't passé. They were never in.

4) The language would render every shipping implementation of Do Not Track non-compliant. That would put even greater pressure on one of the most difficult remaining questions, whether a website has to respect Do Not Track signals from a non-compliant browser.

I also don't believe the arguments in favor of mandatory three-way choice withstand serious scrutiny.

1) Some advertising industry participants have suggested that a user preference mechanism inherently ought to be symmetric. Nonsense. Interactive services are littered with options, including for security and privacy, that lack any symmetry. The online advertising industry's own consumer preference websites aren't even symmetric - they only offer an opt out! Let's be honest about what's going on here: Some participants in the group want to minimize the number of "DNT: 1" users. But nobody will make that argument openly. Instead, participants turn to intuitively appealing but intellectually shallow cover arguments. In the context of "DNT: 1" by default, this phenomenon manifested itself as an outpouring of concern for "the user's voice" and "true choice." Now, in the context of the "DNT: 1" choice mechanism, we're suddenly hearing arguments about the importance of symmetry.

2) Decades of behavioral psychology contradict the notion that we can create a choice architecture with equal weighting. It's particularly rich hearing the importance of unencumbered user choice from the staunchest advocates of no-"DNT: 1"-by-default - a position that would have far greater impact on Do Not Track uptake. The best we can do is take guidance from user preferences and sound policy.

More details on responses

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.