- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 18 Jun 2013 12:01:10 -0700
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: "'Aleecia M. McDonald'" <aleecia@aleecia.com>, <public-tracking@w3.org>
ISSUE-4 is closed. ....Roy On Jun 18, 2013, at 11:56 AM, Mike O'Neill wrote: > Aleecia, > > My input was sabotaged by gremlins towards the end of the call but here is > what I want to add. > > On 3. User Agent Compliance I meant that "general" to be inserted after Do > Not Track i.e. > <text>A user agent MUST offer users a minimum of two alternative choices for > a Do Not Track general preference ... </text> > > This is to differentiate the DNT:0 case which could be optional for a > general preference but is required for a site-specific UGE indication > created by the API. > > I also flagged the 3rd para - "A user-agent MUST have a default tracking > preference of unset", more for the EU jurisdictional issue than IE10. I > would like it more like: > > <text>A user agent SHOULD have a default tracking preference of unset unless > a default preference of set is needed to comply with applicable laws, > regulations and judicial processes.</text> > > If we had an API for site-specific DNT:1 this may not be necessary, but we > don't. > > I would also like to suggest text about the duration of identifiers, i.e. to > cover maximum expiry times for cookies encoding UIDs for permitted uses. For > example in 5.1.2 Data Minimisation, Retention and Transparency a new para. > 4: > <text> > If unique identifiers are used their duration should be limited to the > maximum necessary for such permitted use. > </text> > > We should have a definition of duration and unique identifier to support > this: > > <p> > A <strong>unique identifier</strong> is an arbitrary value stored in the > User-Agent whose purpose is to identify the User-Agent in subsequent > transactions to a particular web domain. It may be encoded for example as > the name or value attribute of an HTTP cookie, as an item in localStorage or > recorded in some way in the cache. > </p> > <p> > The <strong>duration</strong> of a unique identifier is the maximum period > of time it will be retained in the User-Agent. This could be implemented for > example using the Expires or Max-Age attributes of an HTTP cookie so it will > be automatically deleted by the User-Agent after the specified time period > has been exceeded. > </p> > > Mike > > > > > > -----Original Message----- > From: Aleecia M. McDonald [mailto:aleecia@aleecia.com] > Sent: 18 June 2013 00:52 > To: public-tracking@w3.org (public-tracking@w3.org) > Subject: Re: June Draft of the DNT compliance spec > > Thanks to the dozen plus people who called in today -- the call forced me to > set aside time to go through the draft, which was my primary (selfish) goal. > I hope it was helpful for others as well. To that end, here are some notes I > took. If I missed anything, please chime in. We were looking for areas where > the drafting was not clear, or issues remain but are not called out as > clearly. We were not looking to solve (or discuss) anything in detail on the > call, and for the most part, managed not to. > > 1. Scope > 2nd paragraph, "general browsable Web" has differing opinions and is > likely not at consensus; we might want an issue there. This also appears to > preclude add-ons from setting DNT. > > 2. Definitions > The user agent definition conflicts with the 2nd paragraph for > scope. We did not all agree with one should trump, but we did agree it is > inconsistent as is. > > The party definition continues to have potential disagreement. > People could live with this broad definition if other parts of the spec were > more narrow; it is not clear they will be. It may make sense to note there > is a view party should be closer to brand and this is an issue after other > things are nailed down. > > Service provider, I (Aleecia) continue to think "same party" is > insanity, so please consider this sustained objection. > > 3. Unclear why "or share" is in there. One suggestion: "has > no independent right to use the data." then a pointer to permitted uses. > > For the paragraph that starts "The party that owns or operates or > has control over a branded or labeled embedded widget..." it takes a really > long time to get to the idea that if a user interacts with it, they are > promoted from 3rd to first party. Someone unfamiliar with the spec would > likely need to re-read that paragraph three or more times to figure it out. > Can it be redrafted to read better? > > Third party: suggested enhancements to this text, a x-ref to section > 8 about unknowning data collection; a note that a 3rd party can become a 1st > party and vice versa specific to a network interaction (if the prior widget > et al note is addressed well, this might not be needed.) > > Deidentified: very much a point of active debate with new text > forthcoming. Strong suggestion that this area needs non-normative text to > get to LC. > > Tracking: "Good core, not quite there." I have half a dozen > conflicting suggestions -- this is an issue for the larger group. > > Collects & retains, why is "shares" part of the collects definition? > JC suggested something we all found sane: > > A party collects data if it stores data for less than a > transient period. > A party retains data if the party stores data for longer > than a transient period. > > In all cases, we note that "transient period" is not defined, and > needs to be. > > Uses: why is forward part of this definition? > > David W. requests that once the definitions are nailed down, someone > reads through both drafts to make sure terms are used consistently and > correctly. +1 from me. > > 3. User Agent Compliance > Initial paragraph: perhaps Peter and Matthias could examine this in > context of the existing decision process outcome. Mike suggests that this is > about a "general" user agent. How does this work with browser plugins? > > 3rd paragraph, default -> unset: we all agreed with the text as > written, but disagree if IE 10 is compliant. Strong suggestion to have > non-normative text to address general issues (not hard coded to any specific > implementation as those change over time.) > > > 4th paragraph, the rest of this text is hard to read. Suggestion: > pull this apart into two parallel sections, one for user agents and their > UI, and one for websites and what they must show for out-of-band consent > prompts. Keeping them parallel is great, but as it is, the text is trying to > do too much at once. It's rough reading. Other suggestions: does "describe > the parties" refer to affiliates of a website? (What would it mean for a > UA?) It might be good to have a x-ref to EU issues here. Problem: the text > about how DNT unset varies seems missing from this draft. Please add it back > -- that is long-standing agreed upon text. > > The numbered list was also hard to parse. Again, splitting into two > sections could help a great deal. We think that 1. the "tracking preference" > really means "DNT:1 preference" and "it" means "the DNT choice," plus > "viewing" means "browsing." > In 2, why not say permitted uses instead of "certain purposes"? > In 3, viewing -> browsing? > > Final paragraph, "under control of the user" -- what does this > actually mean? We are not even sure if we disagreed. :-) > > 4. 1st Party Compliance > 2nd paragraph, "pass information" and "be passed on" -> share; > period missing at the end > > In addition to data append remaining open, Alan drafted text that > when a 1st party acts as a 3rd party, it may not use data it collected in a > 1st party context. In other words, parallel to point 2 in the 3rd party > section below. There is not a note of this issue. > > Final paragraph, would help to add non-normative text highlighting > that to comply with EU, you may well NEED to follow 3rd party practices. > Also, prior drafts had text that if you are not sure which party you are, > you must act as a third party. That appears to have gone missing. > > 5. 3rd Party Compliance > 1. Confusing. If there's a user granted exception (UGE) there's no > DNT:1 signal anyway, so how does the second half of this paragraph make > sense? Might x-ref to section 6 on UGEs, might want to mention out-of-band, > but mostly: what was this supposed to mean? > > "Third parties that disregard a DNT signal..." we agree on the text, > but notice we do not agree on when it is ok to disregard a signal. That is > an open, un-noted issue. > > Final paragraph: depends on the meaning of de-id'ed. This could be > problematic or fine, depending. > > 5.1.2, retention periods -- please add one line that retention times > may not be indefinite. We had agreement there. > > 5.1.2, final paragraph: unclear what "alternative solutions are > reasonably available" means. Ideally the normative language would be better > drafted to be clear, but non-normative text to illustrate could also work. > As is, we have no idea (that is, people reading this text reached different > conclusions.) > > 5.1.2, generally -- discussion of if there should be retention > periods for unique identifiers v. the data itself. Perhaps some note that > unique ids should only be retained as long as need to fulfill the purpose, > and a note that cookie lifetimes can be helpful here. > > 5.2, permitted uses: after much discussion, it boiled down to a view > that this new text does not improve upon prior drafts, and that the text in > April was further along that this version. The basic view was revert to what > we had before and try again. > > 5.3, request to add that this is specifically about geo-IP. > Statement that postal code is too granular in some areas (Ian Fette had > raised similar concerns.) Perhaps we can address this as "must aggregate > postal codes if there are fewer than X people in a postal code." > > 7. Interaction with Existing User Privacy Controls > > same page -> same webpage > > The bulleted list does not make it clear that these are combinations > of incoming signals. This is my fault; I should've worked with Shane on > this. Perhaps it would be much clearer with a table and column labels. > > General comment: x-refs to the TPE guide are better if they can give at > least a 2nd level heading, not just the document name. > > *** > > As always, please speak up if I failed to capture content on the call > correctly. Thanks to those who joined! > > Aleecia > >
Received on Tuesday, 18 June 2013 19:01:19 UTC