- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Mon, 16 Jan 2012 14:43:53 -0800
- To: Kevin Smith <kevsmith@adobe.com>, Tom Lowenthal <tom@mozilla.com>, "public-tracking@w3.org" <public-tracking@w3.org>
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 Monday, 16 January 2012 22:45:05 UTC