RE: June Draft of the DNT compliance spec

I've cut and pasted some of the thread from below and added my response.



Aleecia: 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.



Thomas: Good point on the missing text; that's worth adding.  Does anybody object against restoring the missing material here?



Me:  I object to adding any language on this topic.  And, I propose deleting the language: "First parties MAY elect to follow third party practices."  This language is out of place in a technical spec and could actually create more confusion.  It's obvious that first parties may elect to follow more stringent data collection practices.  Also, it's not clear that following the 3rd party rules would necessarily be enough to comply with the EU.  If the EU feels that this would be enough to comply with their regulations, then it would be appropriate for the EU to note that and clarify what other requirements are needed.  For that matter, any jurisdiction may choose to do that.



Chris Pedigo
VP, Government Affairs
Online Publishers Association
(202) 744-2967






-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org]
Sent: Wednesday, June 19, 2013 11:20 AM
To: Aleecia M.McDonald
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: June Draft of the DNT compliance spec



Aleecia wrote:



> 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.



The "general browsable Web" language is from the Sunnyvale Consensus Action Summary.  It scopes Do Not Track away from special-purpose uses of HTTP -- for example, the protocol that your computer speaks with your network-enabled printer is built on top of HTTP, but it's really not the use case that we're discussing here.  Also, I don't see how this language would preclude a (sufficiently feature-complete) add-on from implementing Do Not Track.  Care to elaborate?



> 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 user agent definition is picked up from HTTP itself, and should remain as is.  What the spec says is scoped to a specific class of user agent.  If there is a way to say this more explicitly, that should be an easily addressable editorial issue.



>     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.



Both of these sound like material for change proposals.



>           3. Unclear why "or share" is in there. One suggestion: "has no independent right to use the data." then a pointer to permitted uses.



The "or share" part here helps to cover the situation where a party doesn't actually process the data beyond passing them on to yet another party.  One can, of course, argue that that's already covered by "use" -- but having both seems to make the text clearer.



>     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?



Probably.  Change proposals welcome.



>     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.)



At first sight, that looks like a sketch for a fine editorial clean-up. Want to draft that?



>     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.



I'd expect change proposals.



>     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?



Same definitional point as above:  Collection limitations apply when you either store the data for your own purposes, or when you take them, pass them on, and destroy them immediately.



Re-reading this, I notice the inconsistency between including "sharing" in the definition of "collection", but excluding it in the definition of "use".  It's probably worthwhile having those cleaned up and made consistent.



If there's a taker for a specific proposal here, that would be welcome help.



>     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.



Yes, surely.



> 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.)



Text proposals will be welcome.



>     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?



Thanks for flagging this as an area for further editorial clean-up. The text here is meant to be a combination of what was discussed in Sunnyvale, and what we previously had in TPE.  If somebody wants to take on a wholesale cleanup (without changing the meaning), that would be a welcome contribution. Otherwise, this is indeed probably worth reviewing.



>     Final paragraph, "under control of the user" -- what does this

> actually mean? We are not even sure if we disagreed. :-)



noted



> 4. 1st Party Compliance

>     2nd paragraph, "pass information" and "be passed on" -> share; period

> missing at the end



+1, thanks.



>     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.



I'd expect that to come up as a change proposal.



>     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.



Good point on the missing text; that's worth adding.  Does anybody object against restoring the missing material here?



> 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?



Good point.  To make this logically consistent, the "and any explicitly-granted exceptions" text should be dropped from the enumerated list.



Any objections?



> 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.



The text currently makes no statement on whether or when it is ok to disregard a signal -- it simply points out that if you do it, you must indicate that.  I'd expect appropriate change proposals (including, possibly, a no-change proposal).



>     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.



Sounds like a fine correction to me.   Any objections?



>     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.)



Possible clarification: "if alternative solutions that do not require such identifiers are reasonably available."



>     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,



That sounds like a fine way to put a little more meat on the current language about proportionate retention.



Any objections?



> and a note that cookie lifetimes can be helpful here.



Sounds like a potential change proposal, though the usefulness of cookie lifetimes will depend heavily on the frequency with which the user interacts with a particular third party.



(A one day cookie can live indefinitely if the user interacts with the third party every day.)



>     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.



Can you say more about the specific questions and objections here?



>     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."



Sounds like a fine set of potential change proposals, provided the geolocation language remains in the spec.



> 7. Interaction with Existing User Privacy Controls

>

>     same page -> same webpage



+1



>     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.



Want to propose editorial clean-up of this part?



> 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.



noted