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 Monday, 17 June 2013 23:52:41 UTC