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

RE: ACTION-172: Write up more detailed list of use cases for origin/origin exceptions

From: Kevin Smith <kevsmith@adobe.com>
Date: Wed, 2 May 2012 12:35:03 -0700
To: Nicholas Doty <npdoty@w3.org>
CC: Tracking Protection Working Group <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF307D0A02760@nambx07.corp.adobe.com>
Sorry Nick, you are right.  The API as defined would not inhibit websites since both options are available.  Having both options available does however complicate our docs and significantly increase the efforts for browsers to be compatible.  So, the point I was making is that, if we are going to consider the use cases you listed as a possible reason to include the origin/origin option, we should remember that companies that fall into each of those use cases also would have to be willing to forgo traditional advertising methods, and thereby make sure we are considering them in proper scope.  

Kevin Smith  |  Engineering Manager  |  Adobe  |  385.221.1288 |  kevsmith@adobe.com

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Tuesday, May 01, 2012 7:29 PM
To: Kevin Smith
Cc: Tracking Protection Working Group
Subject: Re: ACTION-172: Write up more detailed list of use cases for origin/origin exceptions

On Apr 30, 2012, at 4:25 PM, Kevin Smith wrote:

> It's important to remember that implementing origin/origin exception precludes the use of most common advertising mechanisms in use on the web today.  Therefore, each of the use cases below would need to be prefaced with something like "A site that does not participate in traditional advertising and ...", which would not necessarily reduce the number of use cases, but would likely significantly limit the potential pool of implementers.  I agree with Matthias - I am not sure we should invest more time, effort and complexity to standardize something simply because we can think of a possible use case.  There should be some level of demand for that use case established as well.

What do you mean by "precludes"? In the current draft, sites could EITHER specify a list of origin pairs OR a "*" if, for example, they use an advertising mechanism where they don't know ahead of time which third party domains need an exception. (I think you understand this, but sometimes I'm not sure it's clear to everyone.) I agree that the sites that would use the list parameter would be the sites that aren't already using a "*" call to request an exception for every advertiser and requiring that opt-in in order to visit the site. (There could be sites that make a "*" call but have a fall-back option to request a smaller set if the user rejects the "*" request, as in the "sets of purposes" case.)

I'm not certain what the additional effort is to standardize this given that we've already written the spec that includes origin pairs as well as the "*" option.

Received on Wednesday, 2 May 2012 19:35:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:42 UTC