- From: Kevin Smith <kevsmith@adobe.com>
- Date: Fri, 1 Jun 2012 13:53:16 -0700
- To: "ifette@google.com" <ifette@google.com>, Lauren Gelman <gelman@blurryedge.com>
- CC: Shane Wiley <wileys@yahoo-inc.com>, Justin Brookman <justin@cdt.org>, "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <6E120BECD1FFF142BC26B61F4D994CF309994C09BF@nambx07.corp.adobe.com>
A better question would be, does a compliant entity have to respect a signal sent from a non-compliant entity. If IE, or any other user agent defines DNT to mean something different than the spec and you choose to ignore it, are you non-compliant to the spec, or non-compliant to that user agent’s setting. I think the latter, but I think Aleecia is correct that we have to clearly state what a browser must do to be compliant to the spec. Browsers will innovate and try to provide improved functionality to their users, so our docs need to clearly state that a site need not meet additional or different requirements provided by the UA but not included in the spec to be compliant to the spec. These recent developments make very real the concerns expressed by many back in Cambridge when we first discussed default settings. Many expressed the views (which I share) that they would define a setting which defaults to ‘ON’ very differently than a setting which must be turned on. This is because two such settings inherently have two very different meanings. A setting which must be turned ON means ‘Improved Privacy Control and Potentially Limited Functionality for Those More Conservative (or more aware) than the Masses’. While a setting turned on by default means ‘Improved Privacy Protection (not control) for the Masses’. Both are admirable objectives, but they are very different. Our doc is built largely on the first objective From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com] Sent: Wednesday, May 30, 2012 5:05 PM To: Lauren Gelman Cc: Shane Wiley; Justin Brookman; public-tracking@w3.org Subject: Re: tracking-ISSUE-150: DNT conflicts from multiple user agents [Tracking Definitions and Compliance] I think the desire though is that DNT is a representation of a user's explicit preference. If a browser set it by default, for instance, would a site be obligated to respect it? -Ian On Wed, May 30, 2012 at 3:33 PM, Lauren Gelman <gelman@blurryedge.com<mailto:gelman@blurryedge.com>> wrote: I don't see the parity here. One is a user's affirmative action being overruled by another entity. The other is the user opting to change a default setting. Lauren Gelman BlurryEdge Strategies 415-627-8512<tel:415-627-8512> On May 30, 2012, at 3:22 PM, Shane Wiley wrote: Justin, If companies are expected to achieve “informed and explicit” consent to turn off DNT, then it is only fair that User Agents also achieve “informed and explicit” consent to turn on DNT. Do you disagree? - Shane From: Justin Brookman [mailto:justin@cdt.org<mailto:justin@cdt.org>] Sent: Wednesday, May 30, 2012 3:17 PM To: public-tracking@w3.org<mailto:public-tracking@w3.org> Subject: Re: tracking-ISSUE-150: DNT conflicts from multiple user agents [Tracking Definitions and Compliance] What problem? You honor the header by doing what the spec says. There is no need for you to try to discern user intent, and indeed, no way for you to do so. Ad networks cannot be and are not expected to be responsible for every UI or every possible bit of misinformation someone saw in a comment thread on Reddit to get them to turn on DNT in the first place. Today, if someone sets their browser to block third-party cookies, you don't try to circumvent that on the theory that someone maybe didn't understand what cookies did in the first place. Nor do we dictate to the user agents how and when to surface and describe those capabilities. If there are conflicting headers, that's a different issue, and Ian and Jonathan are putting together draft text on that issue. Justin Brookman Director, Consumer Privacy Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 tel 202.407.8812<tel:202.407.8812> fax 202.637.0969<tel:202.637.0969> justin@cdt.org<mailto:justin@cdt.org> http://www.cdt.org<http://www.cdt.org/> @CenDemTech @JustinBrookman On 5/30/2012 3:34 PM, Chris Mejia wrote: I believe new Issue-150 is closely related to open Issue-143. If the user's intent in turning on/off DNT is not clear (especially in cases where the user doesn't even know they are specifically sending a DNT:1 header), there is no way for publishers to understand how to accurately "honor" any consumer's DNT header flag— it's a fundamental flaw with this scope of this proceeding. I laid out the concern in some detail in my previous email to the group ("In Support of Issue-143"); so I'll just give the brief version here: if publishers do not understand the context of the user's DNT expression (was the user properly informed about what setting does/means, before it was set) how are publishers to determine what the user actually intended, or if they user is even aware that a DNT flag is being sent? If any question/statement in any UI can lead to the sending of DNT:1 or DNT:0, where is the integrity of the system/solution? To give just one example (there are many) of how a DNT mechanism that lacks a uniform informed consent requirement might be abused, consider the theoretical yet plausible scenario where an email is sent to (millions of) users informing the users that they should "click here to prevent evil doers from knowing who you are" or even worse, "click here if you think blue is a pretty color" (replace with a variety of malware tactics), the user's click leading to a programatic setting of DNT, without the user's informed consent under uniform compliance rules. When that happens (some zealot decides to abuse the system), I'm sure we'll eventually learn about it, after some amount of damage being done. When it becomes known that users were deceived into sending a DNT expression (no uniform informed consent), here's what the end-game of publishers might be: without a way of discerning how DNT was set (which program; who owns the program; being able to inspect the program), and under which auspices it was set (what did the user agree to when they clicked?), when learning of a set of users who were deceived into setting DNT, publishers may be forced to consider if they should honor any DNT header requests at all, in an effort to protect the web experience of all users. Under this scenario, publishers may be compelled to issue public statements outlining the fatal flaws of this W3C DNT mechanism, citing the specific abuses, and walking away from compliance on the grounds that being "compliant" with such a system would be harmful to the majority of its users. Is that really the result that this working group is looking for? If not, I strongly suggest that we all get on board with defining a system where the actual intent of the user is absolutely clear— the only way I can think to accomplish this is to require compliance with a uniform requirement to properly educate/inform the user about their choice, at the point user choice is made. Of course I'm open to hearing other suggestions for solving this problem, but I feel that "it's out of scope/Charter for this project" is not an acceptable solution— that answer does not solve the problem described here and in open Issue-143. Please, let's solve the actual problem. Chris Mejia, IAB/DAA On 5/30/12 1:35 PM, "Tracking Protection Working Group Issue Tracker" <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>> wrote: tracking-ISSUE-150: DNT conflicts from multiple user agents [Tracking Definitions and Compliance] http://www.w3.org/2011/tracking-protection/track/issues/150 Raised by: Aleecia McDonald On product: Tracking Definitions and Compliance Due to multiple addons that support Do Not Track, there could be conflicts. For example, a user could turn off DNT (not unset, actually off, sending DNT:0) in Firefox, yet install Abine's "Do Not Track Plus" addon (which sends DNT:1). More fun, users could have three different addons, each with a different value. Do we have either best practices or requirements for user agents here? Created from original issue-148, with actions taken by ifette and jmayer to write proposals.
Received on Friday, 1 June 2012 20:54:09 UTC