- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Mon, 16 Jan 2012 16:20:51 -0800
- To: Jonathan Mayer <jmayer@stanford.edu>
- CC: Kevin Smith <kevsmith@adobe.com>, Tom Lowenthal <tom@mozilla.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Jonathan, I don't believe all that you've stated in "non-controversial" - please see my comments below: - Shane -----Original Message----- From: Jonathan Mayer [mailto:jmayer@stanford.edu] Sent: Monday, January 16, 2012 5:10 PM To: Shane Wiley Cc: Kevin Smith; Tom Lowenthal; public-tracking@w3.org Subject: Re: meaning of DNT 1 and DNT 0 when sent by user agents [ISSUE-78] In responding, I'm going to try to give some shape to the issues in this thread (both explicit and implied). I believe what I'm saying here is, for the most part, non-controversial. 1. Should there be non-protocol content in the TPE document? No. The TPE document specifies a protocol. The TCS document specifies a policy. That clear boundary has existed since at least the Princeton workshop, and it has served us well in advancing the protocol despite deep policy differences. I see no reason to blur the protocol-policy divide now. Especially not the unsupported concern that developers will have trouble with two documents instead of one. [There will need to be some language that outlines what specific elements of the TPE are referencing and within this will come some context. For example, what does DNT:0/1/2/3 mean?] 2. Can the TPE protocol only be used with the TCS policy? While we can't forcibly prevent websites from implementing TPE with a non-TCS policy, we can include strong language condemning the practice (e.g. MUST NOT). A fragmented policy is bad for consumers, implementers, and policymakers. Moreover, the ability to blithely ignore the Do Not Track policy, cloaked by a facade of implementing the Do Not Track protocol, effectively grants third parties a costless ex post veto over the hard work we're doing here. The TCS is much more than a statement of how the W3C "feels" TPE should be used - it's a deeply interrelated, partner standard that reflects a consensus of industry, advocates, researchers, and policymakers. [Disagree - there may be industry groups that decide to go further to provide clarity where areas are not as specific or clear in the TCS.] I would note that this issue is independent of whether the TPE protocol can or should have legal side effects that do not contradict the TCS policy (e.g. satisfying the ePrivacy Directive's consent requirement). [As agreed previously at the Santa Clara f2f, the W3C should not be attempting to develop a Legal standard with DNT. Please reference Aleecia's emails on this point.] 3. Should there be a "baseline" policy in the TPE document? Absolutely not. First, for the reasons above - this is policy content in the TPE document and use of a non-TCS policy with the TPE protocol. Second, developing a "baseline" policy would unnecessarily add delay to this process. [I agree on the term "policy" but definitions will be somewhat difficult to avoid so we'll need to be mindful of providing some context in the TPE.] 4. Is the use of the term "cross-site tracking" in the TPE document a "minor editorial decision?" If the text is clarified that "cross-site tracking" is an arbitrary term with no substantive policy meaning, then I would agree. Otherwise, the term has policy implications - intentionally or not. That's 1) policy content in the TPE document, and 2) policy content that many don't agree with. [Policy implications cut both ways here - hence the reason there has been so much discussion here. Terminology will carry optics and external perceptions and therefore must be considered carefully.] 5. Should the TCS policy be legally enforceable? I believe the consensus is yes. We have not resolved how it may be enforced, by whom, and against whom. [Disagree strongly as a stand-alone vehicle (as this could be interpreted as you saying the TCS should be turned into US law). If the corporate entity should be legally responsible to support whatever claims it makes to consumers. Only in this context should the TCS Policy be legally enforceable.] On Jan 16, 2012, at 2:43 PM, Shane Wiley wrote: > I agree with Kevin here and believe providing based-line functionality language in the TPE is the appropriate path forward. The compliance document is a companion document to the TPE that articulates how the W3C feels the TPE technical specification and functional guidelines should be applied. > > - Shane > > -----Original Message----- > From: Kevin Smith [mailto:kevsmith@adobe.com] > Sent: Friday, January 13, 2012 1:58 PM > To: Tom Lowenthal; public-tracking@w3.org > Subject: RE: meaning of DNT 1 and DNT 0 when sent by user agents [ISSUE-78] > > I personally think that's the least of our problems. The two docs are two halves to a whole. Neither have identity or meaning without the other. If they disagree, that's a problem. Otherwise, I think we are a little early in the process to worry about minor editorial decisions. Eventually, it probably makes the most sense to combine the docs. > > However, as a frequent consumer of technical docs, I would be (and have been) frustrated by a doc that instructs on how to configure a setting without providing adequate detail on what that configuration means. As a potential implementer, I plead with you to leave the description of the setting, next to the setting. After all, the intent of the second doc is to provide definition of compliance, not definition of functionality. > > -----Original Message----- > From: Tom Lowenthal [mailto:tom@mozilla.com] > Sent: Friday, January 13, 2012 12:22 PM > To: public-tracking@w3.org > Subject: Re: meaning of DNT 1 and DNT 0 when sent by user agents [ISSUE-78] > > I completely agree with you that we should define the meaning of the > DNT:1/DNT:0 in the compliance document not the expression document. I would much rather not have any normative explanation of what behavior is associated with on/off/not-sent in the TPE doc. But, if there is a short blurb, I'd prefer if it were accurate rather than inaccurate. > > I think that we've made some good progress on defining the "who" when we introduced the first/third party definition Jonathan and I worked on, the group responded positively, and gave some really specific, constructive suggestions. I hope to be able to incorporate the suggestions by Monday. What do you think of our progress so far? > > Would folks be opposed to cutting the compliance-related summary from the TPE spec all together? > > On 01/13/2012 01:28 AM, Rigo Wenning wrote: >> Tom, >> >> while I like your definitions of DNT:1 and DNT:0, I maintain that the >> DNT Specification should say that DNT is enabled/disabled/unset. And >> not saying anything about "First parties not sharing information". >> >> The difficult part is IMHO then the definition of scope of the user's >> DNT- declaration. You say "who receives it" This was my initial take >> to scope it, namely simply by the GET request. People thought that >> this wouldn't be sufficient. Then we talked about "origins" and first and third parties. >> >> So one of the weaknesses of the DNT - definitions is still the exact >> circle of addressees. We have tried corporation law rules (affiliate), >> social rules (first, third parties), browser habits (origins), user >> expectations (theoretic horizon). But as in the real world, if one >> speaks out, it is difficult to determine for all others what she >> really meant and to whom he was really talking to. At some point the >> choice ends up having something arbitrary that best fits the needs and >> integrates into web architecture. Because once this technology is out, >> it will create the user expectations we are trying to anticipate. But it may be hard to anticipate the non-existing. >> >> IMHO we haven't yet really found a good addressee (or multitude >> thereof) and should discuss this further. Once we have the addressee, >> we can discuss about how the preference expression is perceived and what it is supposed to mean. >> "Supposed to mean" is a topic for the compliance specification IMHO. >> >> Best, >> >> Rigo >> >> >> On Thursday 12 January 2012 15:36:48 Tom Lowenthal wrote: >>> Correction: "All parties" in the DNT:0 blurb should be "Both first >>> and third parties". The header only imparts >>> information/permission/preferences to the party receiving it, not to >>> anyone else. That was just sloppy writing on my part. >>> >>> Does anyone have any suggestions for modifications to this? Roy, if >>> we don't get any suggested changes, could you incorporate this before >>> the "let's read it on the plane" document freeze? >>> >>> On 01/12/2012 03:02 PM, Roy T. Fielding wrote: >>>> On Jan 12, 2012, at 12:52 PM, Tom Lowenthal wrote: >>>>> On 01/10/2012 06:12 PM, Roy T. Fielding wrote: >>>>>> 1 Do not track me across differently-branded sites and do not use >>>>>> previously tracked/obtained behavioral data from other sites to >>>>>> personalize a response. >>>>>> >>>>>> 0 Use of cross-site tracking and personalization has been >>>>>> specifically permitted for this site, as described in section 6. >>>>>> User-agent-managed site-specific exceptions. >>>>> >>>>> [Section 4, 4.1] >>>>> As mentioned on the call, I was surprised to see this definition of >>>>> DNT:0 positioned as a site-specific exception to a general DNT:1 >>>>> preference. I was expecting (and others on the call seemed to >>>>> assume) a quite different approach. My understanding is more as >>>>> follows: >>>>> >>>>> >>>>> DNT:1 Tells everyone who receives it that I have a heightened >>>>> preference for privacy and against being tracked. First parties >>>>> mustn't share any information about me. Third parties must treat me >>>>> like someone about whom they know nothing, and remember nothing >>>>> about me later. >>>>> >>>>> DNT:0 Tells everyone who receives it that I have a preference >>>>> towards a personalized service, and consent to tracking. All >>>>> parties may gather data and learn about me and should use that >>>>> information to improve my experience with them. >>>> >>>> I have no problem defining it that way if that is how user agents >>>> intend to implement it. What I wrote is how it is currently >>>> implemented, AFAICT. I agree that the current state isn't as crisp >>>> as what you describe above, for a variety of reasons. >>>> >>>> Can we get some input from the other browser vendors? >>>> >>>> ....Roy >> > > >
Received on Tuesday, 17 January 2012 00:21:40 UTC