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

Jeff,

In general, I would expect web wide exceptions to be used by consumer facing sites like social media sites that perform as both 1st and 3rd parties.  Since most nodes in an ad serving chain are completely hidden from the user, I don't know how they would get a web-wide exception, and I am not sure it would make much sense.  I have not put a lot of thought into this, but off the top of my head

* The 3rd party would have to ask for a web-wide exception since the 1st party has no incentive to do so - they only care if the 3rd party has an exception on their site.
* Many of the nodes in an ad serving chain never return content to the browser (they just process their business logic and redirect to the next element in the chain) - so they could not pop up an exception request in the middle of serving an ad - it would not only be bizarre, but it would break the ad chain (unless they popped it up in a separate window, which would be obnoxious)
* I see two incentives for web-wide exceptions
	1. The service provides value directly to the user and the user wants the service running on other sites.  Examples: social media tools, recommendation engines etc
	2.  A nearly ubiquitous tool that the user gets tired of approving on every site she goes to - I cannot really think of a good example of this since I think the trust level of exceptions rest at the 1st party
* Unless others can think of other scenarios, it might make sense that web-wide exceptions would have to be requested when the 3rd party was acting as a 1st party (on their own site, or in a widget after interaction etc).  I am use cases exist where this does not make sense.  Can anyone think of any?

-kevin

-----Original Message-----
From: Jeffrey Chester [mailto:jeff@democraticmedia.org] 
Sent: Thursday, March 15, 2012 7: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
> 
> 
> 
>

Received on Thursday, 15 March 2012 17:40:41 UTC