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

RE: Redirect chains and DNT:0 / Exception:* (ACTION-146 re ISSUE-111)

From: Kevin Smith <kevsmith@adobe.com>
Date: Fri, 23 Mar 2012 10:40:06 -0700
To: "ifette@google.com" <ifette@google.com>, Shane Wiley <wileys@yahoo-inc.com>
CC: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CD524B2@nambx07.corp.adobe.com>
Thanks Ian.  I have been saying much the same.  Shane, the concern I have is actually for the document itself.  As you said, I think very few publishers if any will (or could if they wanted to) implement an exception list rather than a single * implementation because of the expense incurred.  And I certainly would not envy the browser manufacturers having to try to find something even approaching a usable UI for a setting that will be rarely used.  I am sure there are a few scenarios where this would be useful, but I question whether it is worth the working group’s time to make the document robust enough to handle selective exceptions when we expect such small usage.  1st party wide exceptions significantly simplify the doc.  Without them we have to answer questions like:

·         How does the browser communicate to the 1st party that some but not all of their 3rd parties have exceptions?

·         How does the 1st party learn which 3rd parties have an exception?

·         Can they do so early enough for them to take advantage of the information?

·         How do we communicate the necessary information to the user for them to make a decision.  I know the UI and actual presentation is up to the browser, but there are certain elements that need to be there in all cases which we would have to provide for.  The current API method would be insufficient.  At the least, the user would need to know the company name (which the browser will somehow have to associate to all respective URLs – the current doc seems to have combined these two very different pieces of information), and a link to where they can learn enough about the 3rd party to decide one way or the other.  This makes it very hard for the browser to create the exception request automatically (since they will need to translate the URL into a company name – and where would they get the link?) and it’s a difficult list for the 1st party to maintain since most of it is outside of their control.  Would we need a standard for the link to more info too?

·         What do we do in cases where all the 3rd parties cannot be ascertained by the 1st party?

·         etc

That list goes on and on.  It seems like an awful lot of work and unnecessary complication for a setting we do not expect to actually get used.  This is why I have asked for actual concrete scenarios, because I think we need to understand what benefit we would actually be providing by putting in the time and effort to answer the above questions.


From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com]
Sent: Wednesday, March 21, 2012 9:50 AM
To: Shane Wiley
Cc: public-tracking@w3.org Group WG
Subject: Re: Redirect chains and DNT:0 / Exception:* (ACTION-146 re ISSUE-111)


I think adds a lot of complexity, as now we the browsers have to figure out UI that's not god-awful for these preferences, and I think it's also rather confusing as it leads to these issues of redirect chains and confusion (if I grant yield manager an exception, does that flow down to whomever the ad is syndicated to?) -- I think it would be much simpler to implement and understand if it were just *.

On Wed, Mar 21, 2012 at 8:46 AM, Shane Wiley <wileys@yahoo-inc.com<mailto:wileys@yahoo-inc.com>> wrote:

While I agree with the simplified approach (trust me -or- trust my site), I believe there are really 3 options when we look at the entire spectrum of user granted exceptions that some in the working group would like to employ:
1st Party                         3rd Party                 Outcome
coXYZ.com                  adABC.net            adABC.net has site-specific exception on coXYZ.xcom
coXYZ.com                  *                              All 3rd parties that operate with coXYZ.com will have an exception
*                                      adABC.net            adABC.net has a web-wide exception on any party’s site
While I don’t believe many publishers will ever implement option one (1st party + 3rd party expressed domain pair), I don’t believe it harms the standard to have this as an option.  Do you feel this adds too high a burden of complexity when compared to the possible options it may provide to those publishers that wish to only gain exceptions for known 3rd parties?

Thank you,
- Shane

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com<mailto:ifette@google.com>]
Sent: Wednesday, March 21, 2012 5:29 AM
To: public-tracking@w3.org<mailto:public-tracking@w3.org> Group WG
Subject: Redirect chains and DNT:0 / Exception:* (ACTION-146 re ISSUE-111)

Upon reflection, this is probably just further discussion for ISSUE-111. I also can't seem to find the canonical text that ISSUE-111 is proposing. That said, my understanding of the proposal is essentially allowing for negotiation of (on this site, X can track me) where X is a single third party, list of third parties, or all third parties.

My main concern is that, as a website author, you may include ads from a given ad network (be that doubleclick, yieldmanager, adecn, or whatever) but have no idea what other third parties those ad networks syndicate to. You want higher quality ads on your site (which presumably translates to more revenue for the site), so you request an exception for the third party ad network you use directly. But, you have no idea, in the presence of syndication, what the final ad provider will be, so you have no way of requesting an exception.

It seems like the only meaningful thing is to request *, at which point I wonder why we're making this so complicated, rather than just two options -- "I request an exception for myself" vs "I request an exception for myself and third parties on my page."


Received on Friday, 23 March 2012 17:40:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:46 UTC