Analysis and opinion on the DAA draft ('Tuesday homework')

Analysis of the DAA Draft (edited June document).

Here are the changes I see, and comments on them:

1) Adds the documentation that the spec. is currently focused on 'general browsers'. I think we would need to add a note saying that other user-agents are for future study, and make it clear that this does not imply that they are not allowed to participate.

2) Change to Service Provider, allow use of Client's data under permitted uses.  I don't understand, as no permitted use allows SP use of client data.

3) Much text around de-identification and de-linking.  I think (but am not sure) that this draft uses the term "de-linked" where at least some of us have previously used de-identified.  I think this section mixes best practices and formal requirements.  Formally, to get data out of the scope of this spec., the data cannot be associated with a given user, user-agent, or device (it's not "tracking data" under the old June definition).  It may be best practice to make it as anonymous or pseudononymous as possible if it IS still tracking data, but that recommendation belongs elsewhere.  The spec. message should be clear: get the data formally out of our scope, and we no longer have much to say about it.  (But see separate threads on how good de-id must be, and whether there are any requirements on sites that did it 'acceptably well' at the time but the data is later found to be identifiable).

4) Major change to the definition of tracking.  I think that this new definition is not sufficiently tight, and is in a substantially different direction from the way we've been working. It's somewhat akin to my (not accepted) "do not cross-site track" strawman.  But in that, I realized that the 'quid pro quo' for the user, in allowing 'tunnel-vision' 3rd party tracking, was that we could also restrict the first party to the same tunnel vision, and that, in turn, allowed the spec. to remove the awkward 1st/3rd party distinction.  This new definition does not do that, and removing "after the network transaction is complete" gives it a vague termination (as well as making it unclear to what extent our rules apply during the transaction).

5) Changes to the consent requirements for user-agents "and web sites" (text that is removed).  However, a sentence is later added that 'parties attempting to receive user granted exceptions…'must also comply…'. I cannot tell if this is editorial -- making the site requirements a separate sentence -- or substantive.

6) Changes to 1st party compliance.  These seem editorial, but I may be mistaken.

7) Inserted (duplicate) sentence about the 'Disregard' signal.  I think we should have this text at most once, and if it occurs, repeat the TPE's point that your compliance if you use this signal is unclear/indeterminate.  (The sentence also occurs in 3rd party compliance).

8) Changes to 3rd party compliance.  Some of this seems confused, for example, a party receiving DNT:1 does not, by definition, have an exception;  truly de-identified data doesn't need mentioning, as it is out of scope.

9) Raw data 'out of scope'.  This takes an existing problem in the June draft, saying raw data is out of scope, and makes it worse, removing the restriction that you can't use it or share it.

10) Changes to the 'General principles', no secondary use.  These seem editorial, or perhaps not?  Removal of "as enumerated below" worries me. Replacement text "for specific uses" does not make clear what these specific uses are. Are they the ones below, and only the ones below?

11) Changes to minimization, etc.  Are these editorial?  The restriction on personalization is gone, but it's already implied by 'no secondary use'.

12) Frequency capping permitted use.  I am not sure we need this at all, frankly (I think it technically possible to frequency cap without tracking users), but the deleted sentence worries me; I think it should be retained, if only as a clarification. (Though of course Frequency Capping DOES alter the user's experience, so the sentence does need work). The clause "as long as the data retained do not reveal the user's
browsing history" is weak. We're not solely interested in protecting the user's browsing history, we're interested in protecting their privacy.

13) Deleted Geolocation compliance.  Now I understand this was agreed as an additional restriction for this kind of data, I'd prefer to see it back with that explained.

14) User-granted exceptions.  This seems editorial (and an improvement).

15) Interaction with existing controls.  I am not sure we need this section at all (it's covered by explicit consent for exceptions or out of band, in my opinion).  The table as supplied seems incomplete, so if we're going to cover tri-state DNT (not set, DNT:1, DNT:0) plus a bi-state opt-out, we should have six rows…


Overall, I cannot tell which of these edits the DAA thinks of as a 'package', and they would want taken together, and which can be debated independently.  






Overall, the major changes (notably 3 and 4) mean that for me I can't agree to adopt this wholesale as our basis going ahead; I don't think this is a better basis (likely to get us closer to our target) than the June document as-is, and it's unclear what aspects of this would be open to change proposals if it were adopted.  

The June document is a better basis for refinement going ahead, and we have a slew of change proposals all in the works against that document. We should continue on that road.


But there is much in here that can usefully be 'mined', and I would like to see us:
* pull out the editorial and other less controversial edits, and discuss or even just adopt them
* get more explanation of the more substantive ones
* discuss the more controversial edits, independently




David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 9 July 2013 09:37:46 UTC