Re: June Draft of the DNT compliance spec

[Aleecia started this thread here: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0162.html <http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0162.html> which created some comments at the time, but we didn’t follow up on all those points yet.]

I believe many of the concerns in this thread have since been directly resolved or otherwise obviated. (Maybe we should have gone through this list starting with the earliest rather than starting with the most separable, but ah hindsight.) A couple of comments below.

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

The first party definition now makes the interaction point at the very beginning, which should make it easier to read. I’ve updated the paragraph on multiple first parties to describe it in language where a party is a first party to a given user action.

> "pass information" and "be passed on" -> share; period missing at the end


We aren’t used “passed”, and now use defined terms. (As suggested in this thread, and in general, I welcome other reviews of all defined terms across the tracking-dnt and tracking-compliance documents to catch any inconsistencies that I’ve missed.)

User Agent Compliance is no longer a section in the Compliance document, as many people had instead wanted this in the tracking-dnt doc.

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

As noted, we don’t have text about how to comply when you don’t know whether you’re a first or a third party to a given user action. However, I did update the text in the first-party compliance section, to describe how a party determines its status and unknowing collection to address data where you figure out later that you weren’t the status you thought. Are we missing anything here?

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

I believe we’ve removed compliance requirements regarding sufficient location detail, with just an informative note on how geolocation detail can enable identification.

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

Many of the TPE references now refer to particular sections or particular definitions, but I would welcome any general references that exist where a more specific section would improve clarity.

>  5.1.2, retention periods -- please add one line that retention times may not be indefinite. We had agreement there.

Is this already implied by the Data Minimization section? How should we clarify?

Perhaps we could change:
> A party MUST provide public transparency of the time periods for which data collected for permitted uses are retained.
to:
> A party MUST publicly describe definite time periods for which data collected for permitted uses are retained.

Comments on that would be most welcome.

Thanks,
Nick