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

David:

Thank you for the service you provided the group in doing a careful read
of the DAA proposal and circulating your comments.

Procedurally, friendly/perfecting edits are welcome at this point.  It
would be helpful for people in the DAA group to indicate where they concur
with editorial changes, such as some of the ones David circulated here and
the list that Thomas Roessler circulated last week.

Questions and discussions about substance are a main topic of the call for
this Wednesday.

Thank you,

Peter



Prof. Peter P. Swire
C. William O'Neill Professor of Law
	Ohio State University
240.994.4142
www.peterswire.net

Beginning August 2013:
Nancy J. and Lawrence P. Huang Professor
Law and Ethics Program
Scheller College of Business
Georgia Institute of Technology






-----Original Message-----
From: David Singer <singer@apple.com>
Date: Tuesday, July 9, 2013 5:36 AM
To: "public-tracking@w3.org WG" <public-tracking@w3.org>
Subject: Analysis and opinion on the DAA draft ('Tuesday homework')
Resent-From: <public-tracking@w3.org>
Resent-Date: Tuesday, July 9, 2013 5:37 AM

>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 12:18:32 UTC