RE: ISSUE-111 (was: Agenda for 2012-Mar-14 call [Note: Call starts 1h earlier (5pm CET) in Europe; Times unchanged in the US])

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 Wednesday, 14 March 2012 14:26:12 UTC