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

Received on Thursday, 15 March 2012 13:52:24 UTC