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

Re: first parties

From: David Wainberg <dwainberg@appnexus.com>
Date: Fri, 7 Oct 2011 15:18:42 -0400
Message-ID: <4E8F5092.7030700@appnexus.com>
To: Shane Wiley <wileys@yahoo-inc.com>
CC: Clay Webster <clay.webster@cbsinteractive.com>, "Amy Colando (LCA)" <acolando@microsoft.com>, "Aleecia M. McDonald" <aleecia@aleecia.com>, "public-tracking@w3.org" <public-tracking@w3.org>
I tend to prefer the initial version: "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." 
(Though, the MAY clause is superfluous. See below.)

However, I am still concerned that we have not agreed on a definition of 
first party. I even wonder whether ultimately 1st vs 3rd party is the 
right paradigm for applying DNT. We don't know until we dig into the 
definitions and start to think out the distinctions that are relevant to 
the meaning of DNT. As we've discussed, the technical definition of a 
3rd party call does not map perfectly to a real-world view of who is a 
1st party.

As to the proposed MAY's or SHOULD's, while I certainly share the desire 
to encourage appropriate notice from all companies, we should constrain 
the definition of the DNT standard to what exactly parties must do in 
response to receiving a DNT signal. In my view it is beyond the scope of 
this standard to make any suggestions regarding entities' practices 
outside of their data collection or use upon receipt of a DNT. Moreover, 
we have enough complex issues to sort in regard to what parties must 
actually do that it's not worthwhile to burn cycles delving into mushy 
standards for what parties may or should do. And, finally, whereas a 
SHOULD is clearly optional in a technical context, this use is in a 
legal/policy context, and could be interpreted more strongly than intended.


On 10/7/11 12:51 AM, Shane Wiley wrote:
>
> Clay,
>
> “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.”
>
> I should have called it out more expressly but it was my assumption 
> the standard will outline “appropriate notice” for any party 
> (primarily 3^rd party) to disclose their support of DNT so I left it 
> as an open element yet to be defined in the latest draft of this 
> statement.
>
> - Shane
>
> *From:*Clay Webster [mailto:clay.webster@cbsinteractive.com]
> *Sent:* Thursday, October 06, 2011 5:58 PM
> *To:* Shane Wiley; Amy Colando (LCA); Aleecia M. McDonald; 
> public-tracking@w3.org
> *Subject:* Re: first parties
>
> On Thu, Oct 6, 2011 at 5:34 PM, Shane Wiley <wileys@yahoo-inc.com 
> <mailto:wileys@yahoo-inc.com>> wrote:
>
>     With Tom's Addition:
>     "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 improve notice
>     with respect to DNT."
>
>     I agree with the Initial Statement but feel that Tom's request was
>     out of scope to suggest first parties must improve notice across
>     the board (not just with respect to DNT).
>
>     I would suggest the following (hopefully a winning middle-ground):
>     "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 if
>     they chose to do so."
>
>
> I could agree with this.  I think the "if they chose to do so" could 
> be left off given that it's a SHOULD.
>
> What form(s) would "appropriate notice" normally take?
>
> --cw
>
> Clay Webster
> Associate Vice President, Platform Infrastructure
> T908-541-3724 F908-575-7474
> 1200 Route 22 East, Bridgewater NJ 08807
>
Received on Friday, 7 October 2011 20:37:19 UTC

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