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

Received on Friday, 7 October 2011 18:54:03 UTC