W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

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

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Thu, 15 Mar 2012 08:01:55 -0700
To: Jeffrey Chester <jeff@democraticmedia.org>
CC: Matthias Schunter <mts@zurich.ibm.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D1041810C@SP2-EX07VS02.ds.corp.yahoo.com>
Jeff,

I'm not sure I understand the question.  I believe you're asking what tools does a user have to discover which 3rd parties they have granted a web-wide exception to?  While the UI specifics are up to the browser vendors, it's my assumption that both the request for a web-wide exception will be a visible event to the user and then hopefully the use will have a place within the browser to see which parties they have granted these exceptions to and have the ability to remove those exceptions if they desire at any time.

- Shane


From: Jeffrey Chester [mailto:jeff@democraticmedia.org]
Sent: Thursday, March 15, 2012 7:53 AM
To: Shane Wiley
Cc: Matthias Schunter; public-tracking@w3.org
Subject: 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<http://www.democraticmedia.org>
www.digitalads.org<http://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<mailto: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<mailto: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> <http://irc.w3.org/>, port 6665, #dnt
Received on Thursday, 15 March 2012 15:03:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:26 UTC