W3C home > Mailing lists > Public > public-tracking@w3.org > October 2011

Re: first parties

From: Matthias Schunter <mts@zurich.ibm.com>
Date: Sun, 09 Oct 2011 13:19:44 +0200
Message-ID: <4E918350.7020704@zurich.ibm.com>
To: public-tracking@w3.org
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 Sunday, 9 October 2011 11:20:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:41 UTC