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

My most fundamental concern with the DAA draft is that I do not understand whether it permits behavioral advertising or not when DNT:1 is activated.  From reading the text, I would think no.  But from Mike Zaneis's description during the call on Wednesday, he seemed to indicate that the DAA approach would allow at least retargeting, and potentially more even for DNT:1 users.

My supposition --- though I could well be wrong about this --- is that DAA thinks that its proposed deidentification language is sufficiently flexible to allow for some degree of behavioral targeting.  I do not think that that is a logical reading of the definition, but disagreement over the meaning and consequences of deidentification has existed within the group for some time now.

In order to fully assess the DAA proposal, I'd like someone to explain what degree of personalization/targeting is allowed for DNT:1 users under the revised language?  Can site attributes be retained but not urls?  Are urls OK so long as the data is hashed and persons within the company are prohibited from accessing it?  Am I mistaken about the DAA interpretation, and behavioral targeting is still prohibited?  If so, how does that accord with Mike's presentation last week?  Is the language on deidentification the extent of the "data hygiene" that is being afforded to DNT:1 users on OBA?  Am I just looking at the wrong document?

I hope this is considered within the spirit of perfecting amendments, as I'm just looking for more clarity as to what is being proposed (I will withhold normative judgment until Friday!).  I apologize for not suggesting specific text, but I'm not entirely sure what the policy goal is here, and anyway, I suspect we might disagree about the meaning of the text anyway.

Justin Brookman
Director, Consumer Privacy
Center for Democracy & Technology
tel 202.407.8812
justin@cdt.org
http://www.cdt.org
@JustinBrookman
@CenDemTech

On Jul 9, 2013, at 5:36 AM, David Singer <singer@apple.com> wrote:

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