Re: ISSUE-111, ad exchanges, web wide exception

Thanks.   What information would a DNT:O user receive about the third parties and their data when they have given a web-wide exception?  Would a user be first informed about these third parties by the site seeking such an exception?





Jeffrey Chester
Center for Digital Democracy
1621 Connecticut Ave, NW, Suite 550
Washington, DC 20009
www.democraticmedia.org
www.digitalads.org
202-986-2220

On Mar 15, 2012, at 10:15 AM, Shane Wiley wrote:

> Jeff,
> 
> If a party had web-wide exception (DNT:0), then they would be able to leverage OBA targeting in a bidding situation, where as parties that have DNT:1 activated would not be able to (and would likely bid at a lower rate because of it).  This is true in an ad network or exchange ad delivery scenario (traditional ad placement or real-time bid ad placement).
> 
> - Shane
> 
> -----Original Message-----
> From: Jeffrey Chester [mailto:jeff@democraticmedia.org] 
> Sent: Thursday, March 15, 2012 6:52 AM
> To: Shane Wiley
> Cc: Matthias Schunter; public-tracking@w3.org
> Subject: Re: ISSUE-111, ad exchanges, web wide exception
> 
> Shane and colleagues:
> 
> Can you explain your thoughts on how the web-wide exception would work in the ad exchange/dsp model?  Would a user be informed first (before an ad could be served) about the companies bidding to serve the ad, in terms of their data collection practices?  [Talk about millisecond decision-making!]  Would a user know about the third party data companies and data itself used to compile the profile for the bidding? I want to better understand how a users privacy via DNT:1 will be impact by the real-time targeting and sales process.
> 
> Thanks,
> 
> Jeff
> 
> 
> 
> On Mar 14, 2012, at 10:25 AM, Shane Wiley wrote:
> 
>> Matthias and Working Group,
>> 
>> Several of us have been working off list to review the Exceptions structure and associated process and would like to propose a solution we believe covers most of the open issues being discussed in the chain.  
>> 
>> 1.  Starting from a consumer point of view, we've developed two distinct perspectives to operate around:
>> - I trust this site (site-specific exception), or
>> - I trust this 3rd party (web-wide exception)
>> 
>> 2.  Under this perspective, we believe it would be more appropriate to only support "*" for site-specific exceptions.  While it's technically possible to support the 1st party/3rd party domain pairs in certain limited situations, after more discussion across Publishers it appears everyone would support only the "*" approach so we're not sure if it's worth adding additional complexity to the standard for a solution no one will likely implement and would not work in many of the most common scenarios
>> 
>> 3.  Publishers and the ad serving ecosystem will be responsible for passing DNT:0 in server-to-server interaction situations.  The web browser will continue to broadcast the appropriate signal on its own to client-side 3rd parties directly.  (It's recommended that industry leverage the AdChoices Metadata standard currently under development to pass the DNT value for server-to-server communications.  This will provide a standard communication mechanism and drive even higher compliance with AdChoices.)
>> 
>> 4.  We need closure on which situations a DNT:0 would be sent to a Publisher.  If the only reason this will ever be sent is due to a site-specific (or web-wide) exception, then there is no need for DNT:2 or for a server-side polling mechanism.  If there are other possible scenarios where DNT:0 could be sent in the header, we'll need to understand those to review the possible need for a different signal for site-specific and/or web-wide exceptions.
>> 
>> We believe this approach will greatly reduce the complexity for implementing site-specific and web-wide exceptions.
>> 
>> Thoughts?
>> 
>> Thank you,
>> Yahoo! and Adobe
>> 
>> -----Original Message-----
>> From: Matthias Schunter [mailto:mts@zurich.ibm.com] 
>> Sent: Wednesday, March 14, 2012 3:43 AM
>> To: public-tracking@w3.org
>> Subject: Re: ISSUE-111 (was: Agenda for 2012-Mar-14 call [Note: Call starts 1h earlier (5pm CET) in Europe; Times unchanged in the US])
>> 
>> Hi!
>> 
>> from the constructive and lively mailing list discussion on ISSUE-111
>> I understand that we do not have agreement on how to best manage the
>> exceptions.
>> 
>> The purpose of today's call is to
>> a) Understand the objectives of the site-specific exceptions
>> b) Understand all the observations and discussions
>> 
>> and most importantly
>> c) find a team/ teams of volunteers that would like to create a
>> revised proposal
>> 
>> Regards,
>> matthias
>> 
>> PS: Some inputs, I picked from the mailing list:
>> 
>> DISCUSSION 1: Opinions on the Granularity of site-specific exceptions:
>> - Permitting specific third parties is too fine-grained and users will
>> neither
>> know these third parties nor care
>> - As a consequence, only opt-in to "*" will be used
>> - Users want transparency and need to know what third parties are in use
>> - A browser always 'knows' the third parties (after all, it sends http
>> requests)
>> - Users may want to prevent exceptions for selected third parties that
>>  are perceived as bad
>> - Third parties should not be treated as a 'third party of a first
>> party" but
>>  rather as independent entities (asking for exeptions on their own)
>> - ...
>> 
>> DISCUSSION 2: Informing the server of the current exeption state at
>> the client
>> - A site needs to know whether the third parties in use still work
>> - A site does not know what third parties are actually used at a point
>> in time
>> Status: DNT;2 to signal that there are
>> site-specific exeptions for a site
>> - Transparency: At the end of the day, the browser can
>> control the interaction and the browser can request a 3rd party
>> resource, or not. So 3rd parties better declare that they have
>> implemented DNT to generate some confidence. We are creating an entire
>> new ecosystem here. And all have to adapt to this new ecosystem. The
>> user has to make responsible choices. First parties have to take their
>> responsibilities on what to allow on their site.
>> And third parties have to work to regain some confidence. Hiding
>> doesn't help here.
>> 
>> 
>> On 3/13/2012 5:53 PM, Matthias Schunter wrote:
>>> 
>>> Chair:Matthias
>>> 
>>> Goals:
>>> - Start new discussions on open issues for TPE
>>> - Assign actions to revise/write text addressing those issues
>>> 
>>> ---------------------------
>>> Administrative
>>> ---------------------------
>>> 
>>> 1. Selection of scribe
>>> 
>>> 2. Any comments on minutes:
>>> http://www.w3.org/2012/03/07-dnt-minutes
>>> <http://www.w3.org/2012/02/08-dnt-minutes>
>>> 
>>> 3.  Review of overdue action items: 
>>>  https://www.w3.org/2011/tracking-protection/track/actions/overdue
>>> <http://www.w3.org/2011/tracking-protection/track/>
>>> 
>>> ---------------------------
>>> New business
>>> ---------------------------
>>> 
>>> 4. ISSUE-111: Signaling status and existence of site-specific exceptions
>>> http://www.w3.org/2011/tracking-protection/track/issues/111
>>> 
>>> 5. Responses: Header & URI
>>> - Discuss Tom & Roy's ideas how to combine headers and URIs
>>> 
>>> ---------------------------
>>> More business (if time permits)
>>> ---------------------------
>>> 
>>> 6. Creation of new actions for TPE
>>> 
>>> 7. Announce next meeting & adjourn
>>> 
>>> ================ Infrastructure =================
>>> 
>>> Zakim teleconference bridge:
>>> VoIP:    sip:zakim@voip.w3.org
>>> Phone +1.617.761.6200 passcode TRACK (87225)
>>> IRC Chat: irc.w3.org <http://irc.w3.org/>, port 6665, #dnt
>> 
>> 
>> 
>> 
> 
> 
>