Re: June Draft of the DNT compliance spec

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