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

Publishers who are not on this list don't even know about this debate let alone know what they should demand.
  
Publishers want to receive the maximum $ and have to know as little as possible about how they got it.  That is why they will outsource this to 3rd party service providers.  Innovative third parties *may* figure out a way to get publishers pretty close to their maximum $ goal and protect privacy better than then "traditional advertising".  It is true they may not.  But they absolutely will be foreclosed from doing so if there is no API that they can access.

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.
> 
> -kevin
> 
> 
> -----Original Message-----
> From: Nicholas Doty [mailto:npdoty@w3.org] 
> Sent: Monday, April 30, 2012 12:59 AM
> To: Tracking Protection Working Group
> Subject: ACTION-172: Write up more detailed list of use cases for origin/origin exceptions
> 
> Per ACTION-172, I'm tasked with explaining in more detail the possible use cases for an API that supports (as in the current draft) asking for exceptions that are scoped to explicit origin/origin pairs (that is, calling from a particular origin and using a parameter that is a list of other origins).
> 
> I'm not sure this is an exhaustive list, but these are the use cases I've heard or know of:
> 
> * Companies that want to distinguish their limited list of third-parties Some companies may wish to put users at ease or distinguish their practices from competitors by requesting exceptions for an explicit list of third-party partners rather than an open-ended site-wide exception. (As suggested by Shane in DC.)
> 
> * Permission requests for specific sets of purposes Some sites may have different sub-sets of exceptions that they can request at different times or in different contexts. For example: "grant exceptions to these 8 advertising parties to support our monetization and access the full text of our articles", "opt in here to social widgets on Foo News". Sites may see higher opt-in rates for certain categories, users may get a better understanding of what kinds of exceptions they're granting. (This came up in our original drafting in December.)
> 
> * Separate data controllers in EU jurisdictions A DNT:0 signal sent to a third-party service in the EU might usefully be interpreted as consent for independent use by that thid-party (that the service would itself be a data controller, not just a processor). EU regulations, however, may require that this consent be specific to the party rather than site-wide. (Suggested by Ninja, who may be able to add more detail.)
> 
> * Smaller sites
> Small sites or sites that use fewer third parties (including small businesses, non-commercial sites, academic sites, governmental sites) may know the precise list of third parties they work with and have an interest in asking for the least permissions necessary. Small sites that add widgets may not wish to ask for tracking exceptions for those widgets or understand that implication in adding a widget. Government sites may in fact be prohibited from asking for tracking exceptions for certain widgets on their pages. (Suggested by Nick, from his maintainance of academic sites.)
> 
> * Carve outs
> Users may, on inspection, wish to grant an exception to some but not all third-parties on a particular site. Sites may wish to increase their opt-in rate by facilitating such an option. A site may not have any interest in facilitating a tracking exception for certain widgets the site embeds. (Term from Jonathan.)
> 
> * Web-wide opt-out
> As some users do now with self-regulatory opt-out cookies, a user may have previously indicated a preference to opt out of tracking by a particular third party and may not know whether a site-wide exception would opt in to tracking by that party. Sites may wish to avoid user agents automatically rejecting tracking exception requests for users with opt-outs previously configured. (I believe this may be related to the comment from Evidon. This is similar to "Carve outs" although the preference might be real-time site-specific or, in this case, previously-configured Web-wide.)
> 
> * Data minimization
> The TAG and Device APIs groups have suggested that APIs should be designed to allow sites to request as little information as possible. One way for this tracking exception API to satisfy the principle would be to allow those sites who can to request a limited list of parties to receive exceptions, rather than every third party domain. (This is perhaps a principle rather than a use case; the criterion supports many of the use cases above. I think it would be unfortunate if this privacy-related spec didn't exemplify documented best practices for privacy in Web APIs.)
> 
> Have I missed any? I believe all these use cases are well-handled by the current proposal (and the proposal since December) of allowing but not requiring sites to request exceptions with a list of third parties.
> 
> Thanks,
> Nick
> 
> 
> 

Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com
http://blurryedge.com

Received on Monday, 30 April 2012 23:47:41 UTC