- From: Jeffrey Chester <jeff@democraticmedia.org>
- Date: Sun, 03 Jun 2012 10:15:39 -0400
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Justin Brookman <jbrookman@cdt.org>, public-tracking@w3.org
- Message-id: <D072BD14-7C94-4D4D-801E-7755880CD30A@democraticmedia.org>
I believe having DNT:1 turned on from the start is appropriate for users. The industry has created a ubiquitous data collection system by default (which it terms an "ecosystem"). Users have little choice in an online world shaped by immersive and invisible strategies designed to trigger conversion, viral social marketing, lead gen and related data techniques (let alone a person sold to highest bidder on exchanges). The cross-platform measurement systems being put in place, which mirror the unified marketing platforms, is another example of a world where users have no real choices. With DNT on from the start, a user can make more informed decisions about their data collection practices and then decide how to proceed. Groups such as mine have already taken key issues off the table--such as the need to control first parties. We believe we can have both monetization and privacy. But we need to make DNT meaningful--to stop tracking and collection. I know that the consumer and privacy community is committed to strike the right balance. I look to the industry leaders in this group to help make DNT a reality. Jeffrey Chester Center for Digital Democracy 1621 Connecticut Ave, NW, Suite 550 Washington, DC 20009 www.democraticmedia.org www.digitalads.org 202-986-2220 On Jun 2, 2012, at 10:45 PM, Roy T. Fielding wrote: > On Jun 2, 2012, at 6:29 PM, Justin Brookman wrote: > >> Roy, this precise issue came up on the weekly call on Wednesday, and Aleecia concluded that there was disagreement among the group on the precise question of whether DNT:1 could be on by default, and that we would discuss the issue in Seattle. > > What we talked about was whether a non-specific add-on (AVG) can > set the header field (ISSUE-149) and the impact of conflicting > extensions and configuration (ISSUE-150). > >> You can obviously do whatever you like to the document, but I just wanted to point out that the editors seem to disagree with your statement that we have reached consensus on this point. The minutes from the last call (http://www.w3.org/2012/05/30-dnt-minutes) seem to back up my argument, but perhaps I am confused and misunderstood what was said on Wednesday --- guidance from the chairs on this point would be helpful. (Also, FWIW, there is also another raised ISSUE-143 on whether "activating a tracking preference must require explicit, informed consent from a user" . . .) > > I believe 143 is about additional requirements on user awareness > of the new setting when DNT is enabled by an add-on/extension. > >> In the meantime, if you or anyone else could shed some light on why DNT:1 on by default would make the standard more challenging to implement, I would very much like to hear substantive arguments about how that would not be workable. > > It isn't more challenging to implement. It just won't be > implemented because it obscures the user's choice. The essence > of any Recommendation is to encourage deployment of a given > protocol because it is good for everyone to do so, and we already > established that most of industry will deploy DNT if it accurately > reflects an individual user's choice. We already discussed this > and made a decision. It has not yet been reopened to further > discussion, so I am not going to explain it further. > >> Thus far, I have only heard assertions by fiat that we can't discuss the issue and tautological interpretations of the word "preference." If there are technical reasons by DNT:1 on by default would pose problems, what are they (I'm not saying they don't exist, I just don't know)? > > The technical reason is that it wouldn't match the defined > semantics for the field. That could obviously be fixed by > changing the definition of the field, but since that is one > of the few things we have agreed to already, we have a process > that must be followed to reopen the issue. Otherwise, we have > no chance of finishing anything. > > ....Roy
Received on Sunday, 3 June 2012 14:16:23 UTC