Re: Towards a Grand Compromise

I was thinking about this a little more.

It seems that *sites* within *one party* are able exchange data (that's what we mean by a party, after all - the envelope within which data can flow and be used).  It seems that to do that, they need to have a common responsibility for the data and its use - that the privacy policy under which it was collected applies no matter where it goes, and that if there is a problem, there is a *singular entity* that will own the responsibility.

Given that, it seems that the definition of 'share' is when data flows and can be used out of one 'responsibility envelope'.

(Note that this leaves outsourcing off the table -- it's not sharing, as the collector has no ability to use.)

For me, the notion that responsibility-follows-data is more useful than trying to find something about ownership or branding, which vary by the structures and laws that define corporations etc.

So, for me, the (a) responsibility-envelope fully encompasses the data-exchange envelope and (b) the site-party relationship is discoverable (if not evident, e.g. by host name), perhaps through the well-known-resource, are what we need.

does this help?

On Jun 12, 2012, at 14:30 , Dobbs, Brooks wrote:

> Jonathan,
> 
> Apologies for the late comments here, but I think it is worth mentioning that the proposed definition of “share” is likely to create a number of problems.  Semantically I think most people understand the concept of sharing as being where one party “has possession” (for lack of a better term) of a known set of data points which it then forwards to another party.  The general idea being data subject gives data to controller 1, controller 1 knowingly gives the data to controller 2.  This analogy doesn’t work well online where the following is true... 
> 
> Data is directly collected by controller 2 from data subject.  
> Data collected by controller 2 may be different than that collected by controller 1 (controller 2 may have different cookie than controller 1).  \
> And in reality controller 1 may not know either the identity of the data subject, the identity of controller 2 or the relationship as between subject and controller 2.  
> 
> Taken together, there is no practical way that a 1st party can comply.  
> 
> By way of example.  Say publisher has a tool which allows for an ad auction to occur on its site.  Publisher does not know ahead of time who will win the auction or even the population of data collectors who may potentially win.  Whoever wins the auction, the first party publisher has enabled the advertiser to receive data (shared).  If e.g. Amazon wins the auction an ad containing perhaps a fully identified .amazon.com cookie may cause Amazon to receive data which it may be prohibited by DNT from coming into its control, but because the 1st party had neither knowledge of who the 3rd party is, or what specifically it was prohibited from collecting, there is a problem.  The advertiser can still respect DNT and act accordingly, but arguably the spec violation occurred when the 1st party caused the 3rd party to receive the data and have to make the decision.
> 
> It may be better to define share in the traditional way – I know what I have and who I give it to – and then break out a new definition of “enable to collect”.  It doesn’t answer the prohibition question, but at least it gives us a workable vocabulary.
> 
> -Brooks
> 
> 
> 
> On 6/6/12 7:06 AM, "Jonathan Mayer" <jmayer@stanford.edu> wrote:
> 
>> 
>> This group has made tremendous progress.  As we enter our second year and look forward to our fifth meeting, we can celebrate achieving hard-won consensus on many difficult topics. 
>> 
>> It's time to complete our task.  We have given shape to the several issues at the center of Do Not Track policy, but we have not reached agreement on how to resolve them.  Those issues are, in brief:
>> 
>> 1) May a user agent enable Do Not Track by default?
>> 
>> 2) May a website share its information with corporate affiliates?
>> 
>> 3) May a third-party website continue to set tracking cookies (or use an equivalent technology for collecting a user's browsing history)?
>> 
>> Peter Eckersley (EFF), Tom Lowenthal (Mozilla), and I (Stanford) have iterated on a comprehensive compromise proposal that addresses these issues.  The text draws extensively on prior drafts from multiple constituencies.  It would, in short:
>> 
>> 1) Require explicit consent for enabling Do Not Track.
>> 
>> 2) Allow affiliate information sharing.
>> 
>> 3) Prohibit tracking cookies.
>> 
>> We have received valuable feedback from a number of participant viewpoints, including browser vendors, advertising companies, analytics services, social networks, policymakers, consumer groups, and researchers.  Out of respect for the candid nature of those ongoing conversations, we leave it to stakeholders to volunteer their contributions to and views on this proposal.
>> 
>> As you review the draft, please recognize that it is a compromise proposal.  The document is not a retread of well-worn positions; it reflects extraordinarily painful cuts for privacy-leaning stakeholders, including complete concessions on two of the three central issues.  Some participants have already indicated that they believe the proposal goes too far and are unwilling to support it.
>> 
>> We would ask all stakeholders to approach the document with a collegial spirit.  I can assure you now: there will be components of the proposal that you will not like.  Some industry and advocacy participants will flatly reject it.  But when everyone in the center of the group is just a bit unhappy, I think we've found our consensus.
>> 
>> Sincerely,
>> Jonathan
>> 
>> 
>> 
>> 
> 
> -- 
> 
> Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the Wunderman Network
> (Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com 
> brooks.dobbs@kbmg.com
> 
> <image.png>
> 
> This email – including attachments – may contain confidential information. If you are not the intended recipient,
>  do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message.

David Singer
Multimedia and Software Standards, Apple Inc.