RE: first parties

That sounds reasonable to me.  I think our disagreement is that I think the definition of a "First Party" is far less interesting that the definition of "First Party Data".  At first I was thinking we could get away with just a definition of First Party Data, but I've realized that perhaps I'm over simplifying the issue, and it will make more sense to have a definition of both First Party (or maybe a definition of Site Owner) AND First Party Data.  If that is the case it will almost certainly make sense to have both definitions, one building on the other.  

Perhaps a couple of examples will help illustrate my point:  

Option A:
This standard imposes no requirements on First-Party Data.  

Definitions:
First-Party Data:  Data that meets all the following criteria:
	1) Be collected by the Owner of the site (domain/brand/??? etc).  
	2) Be used solely by the Owner of the site for the benefit of the site
	3) Not shared with any other entity other than the employees of the Owner of the site with the exception of First Party Agents (see definition)
	4) ...


Option B:
This standard imposes no requirements on First Party Data as long as that data is collected by this party, is not shared with other entities (with the exception of Agents-- see definition) and benefits only the first party owner, ... etc.

Definitions: 
First-Party: The Owner of the site (domain/brand/???)


-----Original Message-----
From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Matthias Schunter
Sent: Sunday, October 09, 2011 5:20 AM
To: public-tracking@w3.org
Subject: Re: first parties

Hi!


I think that Brett made an important point:
 I believe that there is agreement that we need to restrict the amount of sharing done by 1st parties.

Whether this is part of the definition (~you are no longer a 1st party if you share) or part of the constraints on third parties (~1st parties must not share) is a matter of style.

I prefer the latter since 1st/3rd parties is a distinction from the user perspective (the site you are visiting) and (unauthorized) sharing should not render a 1st party to be somethine else.

As I tasked Shane (from Yahoo) to do, I'd like to see what these restrictions on 1st parties should be...


Regards,
matthias




On 10/7/2011 11:54 PM, Brett Error wrote:
> I believe that this specification should not impose restrictions on first parties (subject to pending definition) other than the restrictions involved in that definition (for example, you can't share consumer data with other parties and still be defined as a first party).
>  
> I would urge us to stay away from "shoulds" in defining a standard.  One of the primary purposes of a standard is define a minimum standard that participating entities must meet.  Including "shoulds" adds very little value.  It does not redefine that standard in any way, makes specification more cumbersome and less readable.
> 
> 
> -----Original Message-----
> From: public-tracking-request@w3.org 
> [mailto:public-tracking-request@w3.org] On Behalf Of Shane Wiley
> Sent: Friday, October 07, 2011 1:02 PM
> To: Justin Brookman; public-tracking@w3.org
> Subject: RE: first parties
> 
> I still prefer the shorter version and would suggest we go with that approach over this longer version with stacked shoulds, should nots, mays, and must onlys which will take more time to pull apart and address individually.
> 
> "This standard imposes no requirements on first-party websites.  A first-party website MAY take steps to protect user privacy in responding to a Do Not Track request and SHOULD provide appropriate notice in what manner they support Do Not Track."
> 
> - Shane
> 
> -----Original Message-----
> From: public-tracking-request@w3.org 
> [mailto:public-tracking-request@w3.org] On Behalf Of Justin Brookman
> Sent: Friday, October 07, 2011 11:50 AM
> To: public-tracking@w3.org
> Subject: Re: first parties
> 
> Shane, please re-read my message.  The combination proposal from Aleecia (as I understand it) does not include any MUST language at all for first parties --- Aleecia proposed taking Thomas's language and changing the MUST ONLY language to SHOULD.  Personally, I would be OK with either Jonathan's MAY approach, or the revised version of Thomas's to offer only SHOULD and MAY guidance.
> 
> Justin Brookman
> Director, Consumer Privacy Project
> Center for Democracy&  Technology
> 1634 I Street NW, Suite 1100
> Washington, DC 20006
> tel 202.407.8812
> fax 202.637.0969
> justin@cdt.org
> http://www.cdt.org
> @CenDemTech
> @JustinBrookman
> 
> 
> On 10/7/2011 2:14 PM, Shane Wiley wrote:
>> I believe this approach is far outside of scope as the group generally agreed first parties should not be subject to the Do Not Track signal.  The proposed approach below goes significantly beyond this perspective to set out "MUST" elements and feels like an attempt to address much broader privacy issues beyond "Tracking Protection".
>>
>> - Shane
>>
>> -----Original Message-----
>> From: public-tracking-request@w3.org 
>> [mailto:public-tracking-request@w3.org] On Behalf Of Justin Brookman
>> Sent: Thursday, October 06, 2011 1:18 PM
>> To: public-tracking@w3.org
>> Subject: Re: first parties
>>
>> I believe the suggestion is to meld Jonathan's and Tom's first party 
>> approach by taking Tom's language (see below) and revise the last 
>> "MUST ONLY" to "SHOULD."  I would be OK with this approach.
>>
>> To Aleecia's other questions, I do not think we want a continuum of 
>> first vs third parties --- once we make the call about who is first 
>> and who is third, I would have this spec apply to the first, and the 
>> most prescriptive third party spec apply to the third.  Don't see a 
>> cause for special treatment of middle edge cases ATM.  I would not 
>> require that a first party send a response header.
>>
>> When a first party receives a request where
>>
>> - they know that they are a first party, and
>> - the DNT signal is on,
>>
>> that party **should**:
>>
>> - store as little information about that request as possible,
>> - store as little information about the user who made the request as 
>> possible,
>> - take all reasonable steps to protect the privacy and anonymity of 
>> the user who made the request; and
>>
>> that party **may**:
>>
>> - provide an affirmative notice to that user regarding the steps that 
>> the site takes as a result of the user's expressed preference,
>> - provide the user with additional options to choose how the site 
>> should further protect that user's privacy; and
>>
>> that party **should not**:
>>
>> - send information about that request or the user who made the 
>> request to any other entity, unless
>>       - the entity to which the information is sent is performing a 
>> service as the agent of that party, and
>>           - that entity is bound by contractual or technical means
>>               - to keep information associated with requests and 
>> users related to this party completely separate from information 
>> associated with any other information they keep, and
>>               - not to further share such information except under 
>> similar restrictions, or
>>       - it is the user's deliberate intent to share information
>>           - (for instance, when a user sends an email through a 
>> webmail provider, that provider should send that email to the 
>> destination server); and
>>
>> that party **must only**:
>>
>> - store information about that request where
>>       - each piece of information is stored for a particular purpose, and
>>       - the party posts a readily-accessible policy which describes
>>           - what information is collected, and
>>           - the purpose for which each piece of information is stored.
>>
>>
>> Justin Brookman
>> Director, Consumer Privacy Project
>> Center for Democracy&   Technology
>> 1634 I Street NW, Suite 1100
>> Washington, DC 20006
>> tel 202.407.8812
>> fax 202.637.0969
>> justin@cdt.org
>> http://www.cdt.org
>> @CenDemTech
>> @JustinBrookman
>>
>>
>> On 10/6/2011 4:04 PM, Amy Colando (LCA) wrote:
>>> Sorry, not sure if I am mixing up threads.  Is this the same or different than the following, on which I thought we were (approaching) consensus on a separate thread:
>>>
>>>>> First-Party Requirements:
>>>>> This standard imposes no requirements on first-party websites.  A first-party website MAY take steps to protect user privacy in responding to a Do Not Track request.
>>> -----Original Message-----
>>> From: public-tracking-request@w3.org 
>>> [mailto:public-tracking-request@w3.org] On Behalf Of Aleecia M.
>>> McDonald
>>> Sent: Thursday, October 06, 2011 12:45 PM
>>> To: public-tracking@w3.org
>>> Subject: first parties
>>>
>>> After our discussion yesterday on ISSUE-17 (Data use by 1st party,) here is what I think I heard of the two proposals on the table:
>>> 	- Jonathan is fine with the idea of a list of things first parties SHOULD (not must) do in response to receiving a DNT header, along the lines of what Tom proposed.
>>> 	- The remaining difference is that Tom wants to see improved notice as something companies MUST do to comply with DNT.
>>>
>>> Outside of scope for just this moment: (1) when things become more 
>>> complex than an obvious first party (e.g. third party in a first 
>>> party context, common branding, widgets, iFrame issues...) do we 
>>> treat them or define them as first parties, or not? (ISSUE-49, 
>>> ISSUE-60, ISSUE-62, ISSUE-65, ISSUE-73, ISSUE-77) (2) is there an 
>>> obligation for first parties to send a response header? (ISSUE-51)
>>>
>>> Note that a straw man draft is not the final word on the issues ahead of us, but ideally does represent a rough consensus view of where we are today. If we fail to reach any consensus, than the editors will take their best shot at creating something for the group to react to. We can, and should, note points where we lack consensus within the straw man document itself.
>>>
>>> PROPOSAL: include Tom's text in a straw man draft, but changing improved notice as something first parties SHOULD do.
>>>
>>> What say you all?
>>>
>>> 	Aleecia
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

--
Dr. Matthias Schunter, MBA
IBM Zurich Research Laboratory,  Ph. +41 (44) 724-8329
Homepage: www.schunter.org, Email: schunter(at)acm.org
PGP Fingerprint    989AA3ED 21A19EF2 B0058374 BE0EE10D

Received on Monday, 10 October 2011 00:14:01 UTC