- From: Nicholas Doty <npdoty@w3.org>
- Date: Tue, 14 Oct 2014 21:16:49 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>, "Amy Colando (LCA)" <acolando@microsoft.com>, David Singer <singer@apple.com>
- Cc: Tracking Protection Working Group <public-tracking@w3.org>
- Message-Id: <0DF71F02-FBBF-429A-B46F-1D7DD9AAC84C@w3.org>
On October 8, 2014, at 11:30 AM, Roy T. Fielding <fielding@gbiv.com> wrote: > On Oct 7, 2014, at 5:32 PM, Nicholas Doty wrote: > >> ## deidentification >> >> Added definition agreed via Call for Objections. Changed all instances to refer to "permanently deidentified" (or similar). Non-normative section currently immediately follows the definition (and includes the geolocation note from before), but we could move this elsewhere if it reads as too verbose. > > Okay, but it is supposed to be hyphenated (de-identified and re-identified). I assumed that punctuation was typically an editorial decision and I prefer it without the hyphen. If someone has a reason why this would be confusing to readers, let me know. I'll be sure to do a pass as we get further along to make sure punctuation is consistent throughout. > % cvs diff -r1.125 -r1.126 tracking-compliance.html > Index: tracking-compliance.html > =================================================================== > RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v > retrieving revision 1.125 > retrieving revision 1.126 > diff -u -r1.125 -r1.126 > --- tracking-compliance.html 1 Oct 2014 06:54:43 -0000 1.125 > +++ tracking-compliance.html 1 Oct 2014 07:02:11 -0000 1.126 > @@ -551,21 +551,8 @@ > signals" may be received. > </p> > <p> > - As a general principle, more specific settings override less > - specific settings. > + As a general principle, more specific settings override less specific settings, as where the specific consent in user-granted exceptions overrides a general preference. If a party perceives a conflict between settings, a party MAY seek clarification from the user or MAY honor the more restrictive setting. > </p> > - <ol start="1"> > - <li>No DNT Signal / No Opt-Out: Treat as DNT unset</li> > - > - <li>DNT:1 Signal / No Opt-Out: Treat as DNT: 1</li> > - > - <li>Opt-Out / No DNT:1 Signal: Treat as DNT: 1</li> > - > - <li>Opt-Out / DNT User-Granted Exception: Treat as DNT: 0 for that > - site; DNT User-Granted Exception is honored</li> > - </ol> > - <p class="issue" data-number="210" title="Interaction with existing privacy controls"></p> > - <p class="issue" data-number="207" title="Conditions for dis-regarding (or not) DNT signals"></p> > </section> > <section> > <h3>Unknowing Collection</h3> > =================================================================== > > The above section no longer applies in my proposal and should not be in > compliance. There are only two possibilities: prior consent or DNT. > Prior consent always overrides DNT, regardless of the intent of that > consent (e.g., the consent might even limit tracking more than DNT:1). > > The text above implies UGE is some additional signal; it is not. > UGE would be reflected in a different DNT header field. Hence, the > last sentence above is simply incorrect -- there is no opportunity for > multiple signals to be received other than consent + DNT, in which case > consent is *not* a conflict -- it is designed to override so that a user > doesn't have to twiddle their general preference. This section is referring to possible interactions with, for example, DAA-related opt-out cookies, when they're present with a DNT:1 or DNT:0. As such, I don't think it's attempting to describe any conflicts between DNT and a UGE, but rather UGE and a DAA-style opt-out cookie. I believe Amy Colando (CCed) had worked on the update to that section. Amy or Roy, is there some clarification we should add to that paragraph? > Also, the following change is apparently a clarification to the definitions > currently in TPE. Should I add it to TPE? Ah, yes, good catch, I think that's right. We should also be sure that we're using "first party" and "third party" in the TPE consistently to how we're using it in Compliance. I think maybe the references to first party in the Exceptions API sections should use the phrasing of "first party to a given user action". Thanks, Nick [change to first party / intentional interaction definition retained below for context] > ....Roy > > % cvs diff -r1.123 -r1.124 tracking-compliance.html > Index: tracking-compliance.html > =================================================================== > RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v > retrieving revision 1.123 > retrieving revision 1.124 > diff -u -r1.123 -r1.124 > --- tracking-compliance.html 6 Aug 2014 04:44:06 -0000 1.123 > +++ tracking-compliance.html 1 Oct 2014 06:49:47 -0000 1.124 > @@ -8,9 +8,7 @@ > var respecConfig = { > specStatus: "ED", > shortName: "tracking-compliance", > - previousPublishDate: "2012-04-30", > previousMaturity: "WD", > - //previousURI: "http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/", > edDraftURI: "http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html", > editors: [ > { name: "Nick Doty", url: "http://npdoty.name", > @@ -174,6 +172,9 @@ > co-branding on the resource might lead a user to expect that > multiple parties are responsible for the content or functionality. > </p> > + <p> > + Network interactions and subrequests related to a given user action may not constitute intentional interaction when, for example, the user is unaware or only transiently informed of redirection or framed content. > + </p> > </section> > > <section id="third-party"> > ===================================================================
Received on Wednesday, 15 October 2014 04:17:06 UTC