W3C

Results of Questionnaire [Call for Objections] Limitations for add-ons

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: team-tracking-chairs@w3.org

This questionnaire was open from 2014-01-15 to 2014-01-29.

9 answers have been received.

Jump to results for question:

  1. Objections to Option A: editors' draft text
  2. Objections to Option B: UA that permits add-ons jointly responsible

1. Objections to Option A: editors' draft text

Option A: editors' draft text

A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as "SuperFred", but might imply a preference if invoked as "SuperDoNotTrack" or "UltraPrivacyFred". Likewise, a user agent extension or add-on MUST NOT alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that tracking preference.

A user agent extension or add-on MUST NOT alter the user's tracking preference setting unless it complies with the requirements in this document, including but not limited to this section (Determining a User Preference). Software outside of the user agent that causes a DNT header to be sent (or causes existing headers to be modified) MUST NOT do so without ensuring that the requirements of this section are met; such software also MUST ensure the transmitted preference reflects the individual user's preference.


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

Details

Responder Objections to Option A: editors' draft text
Mike O'Neill I prefer the new text under Option B because it encourages browsers and add-ons to co-operate in offering a user more control over tracking, but without trying to limit the ability of add-ons to change headers.
Walter van Holst
Rob van Eijk Although the issue is openened against the TPE, I object to this draft text. Because of the purpose of this CFO, which is to get us nearer to Last Call status, the nature of 'getting to a close' is about how much the TPE document needs to stand on itself. For that reason, some of the key defenitions are ported over from the compliance document.

I object, because these paragraphs belong in the compliance document, not in the TPE. Normative requirements about the default setting of a user agent and/or user agent extention are at the core of the question what tracking means in a W3C DNT standard. The answer to that question should be dealt with in the compliance document, not in the technical protocol specification i.e., TPE.

I also object because a TPE without this draft text can be used just fine for testing and implementation. The draft text does not add anything that would make testing and implementation impossible.
Chris Mejia I object to Option A: When it comes to user choice, I believe it would be irresponsible to hinge the decision of whether an informed choice was made explicitly by the user, on a standard that allows for the user agent to decide (for the user) that it is "implied" that using that agent indicates that DNT should equal 1 by default-- that's far too subjective. We should absolutely require that the user make this setting themselves (in ANY agent that affects the sending of DNT header signals); that they express their choice directly and explicitly via a setting mechanism that must be changed from the default state of un-set.

I believe it's necessary to ensure that browser plug-ins and browser extensions are held to the same compliance standard and requirements as the browser itself. Otherwise, plug-ins or extensions could be used to manipulate a user's tracking preference signal, without the user having made an informed and educated choice, or without even notifying the user of the change.
Jeff Wilson We object to option A. What might "imply" a preference is subjective. Experiences will be unpredictable and inconsistent, and tracking options will likely be set without informed choice.
Brad Kulick I strongly object. See my response to option B please.
Shane Wiley I strongly oppose this option. This approach opens the door for non-compliant bad actors to inject DNT signals in an unchecked and undiscoverable manner (no way to detect who the setter was in the current architecture). If we desire industry adoption and healthy implementation rates, Servers must be provided some level of confidence that DNT signals are set by users through appropriate disclosure and meaningful control.
Jack Hobaugh I object to Option A only to the extent that Option A precludes Option B.

Option B is necessary to insure that to the extent possible, browser plug-ins and browser extensions are held to the same degree of compliance with the TPE as is the user agent itself. Without such language, plug-ins or extensions could be used to circumvent compliance with the TPE.
Berin Szoka In theory, this option seems reasonable. But in practice, it seems likely that this option will allow non-compliant user agents to game the system by having the authority to decide when a user preference to turn on DNT is "implied by the decision to use that agent." I do not see how that part of the standard could be given practical effect: what would stop a user agent from simply asserting that their users wanted DNT on? Is this not what Microsoft, for instance, has already done with its "general-purpose browser?" Given this reality, this option could derail the entire consensus upon which DNT rests and thus seriously undermine industry adoption of the standard. Against that cost, the relatively minor hassle of having to check a box to turn on DNT after setting up / adding a privacy-friendly user agent seems relatively trivial and well-worthwhile. We cannot expect the DNT standard to be completely costless to users.

2. Objections to Option B: UA that permits add-ons jointly responsible

Option B: UA that permits add-ons jointly responsible

Add to current language:

A user agent that permits an extension or plug-in to configure or inject a DNT header is jointly responsible, with the plug-in or extension, for ensuring compliance to the extent possible.

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

Details

Responder Objections to Option B: UA that permits add-ons jointly responsible
Mike O'Neill I support this option.
Walter van Holst This option adds unnecessary legalese to a technical specification. The editor's draft is, despite being somewhat more verbose, clear to implementers. Also, this option is ambiguous in the sense that it can be interpreted as an obligation to UAs to police their extensions, which is not conductive to an open web.
Rob van Eijk I object, in conjunction with my reasoning in Option A and along the same line as Walter: "This option adds unnecessary legalese to a technical specification."
Chris Mejia I support Option B: I believe it's necessary to ensure that browser plug-ins and browser extensions are held to the same compliance standard and requirements as the browser itself. Otherwise, plug-ins or extensions could be used to manipulate a user's tracking preference signal, without the user having made an informed and educated choice, or without even notifying the user of the change.
Jeff Wilson We support option B, as it is more likely to provide a consistent experience and ensure that the preference is explicitly set by the user. Reliable signals are more likely to be honored.
Brad Kulick I strongly support reasonable efforts, such as this, that continue to support the balance in the application of this technical specification. User agents (UA) provide platforms by which extensions or plugins can be built to do a variety of tasks, including altering user DNT signals. Unfortunately, extensions' and plug-ins' alterations of DNT settings are not transparent and, therefore, open for unchecked abuse. Coupling responsibility to the parties that provide the platform for such access to DNT signal modification, and who are visible participants, fosters a more compliant ecosystem with which a greater confidence in DNT signals can be placed.
Shane Wiley I strongly support this option. It's critical that appropriate technical support mechanisms, where possible, be leveraged to reduce the likelihood of bad actors falsifying user preference signals. This approach provides the most balanced and thoughtful approach to a weak technical architecture that can be easily abused by bad actors. It's for this reason that this language appropriately belongs in the TPE.
Jack Hobaugh I strongly support this option, Option B.
Berin Szoka I strongly support this option. This is essential to ensuring DNT adoption and thus the viability of the standard.

More details on responses

  • Mike O'Neill: last responded on 22, January 2014 at 03:34 (UTC)
  • Walter van Holst: last responded on 29, January 2014 at 20:13 (UTC)
  • Rob van Eijk: last responded on 29, January 2014 at 22:36 (UTC)
  • Chris Mejia: last responded on 29, January 2014 at 22:56 (UTC)
  • Jeff Wilson: last responded on 29, January 2014 at 23:43 (UTC)
  • Brad Kulick: last responded on 30, January 2014 at 02:03 (UTC)
  • Shane Wiley: last responded on 30, January 2014 at 03:53 (UTC)
  • Jack Hobaugh: last responded on 30, January 2014 at 03:59 (UTC)
  • Berin Szoka: last responded on 30, January 2014 at 04:13 (UTC)

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