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

Rushed responses below to try to give a little more context before the upcoming call, sorry for brevity/unclarity.

On May 1, 2012, at 7:55 PM, Ian Fette (イアンフェッティ) wrote:

> On Tue, May 1, 2012 at 7:01 PM, Nicholas Doty <npdoty@w3.org> wrote:
> On Apr 30, 2012, at 11:07 AM, Ian Fette (イアンフェッティ) wrote:
> 
>> On Sun, Apr 29, 2012 at 11:59 PM, Nicholas Doty <npdoty@w3.org> wrote:
>> 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.)
>> 
>> Couldn't this be done in an out-of-band manner? I doubt you are just going to call RequestException() when the user goes to the homepage. Probably you message something to them explaining why you want the exception. You could explain your limited use of third parties here. (You could also make it available at a well-known URI).
> 
> Yes, sites can use other means to specify the limited set of parties they work with or to explain their list of parties. If the request itself contains the list, users may be able to verify the list at the time that permission is requested and will know that the permissions they grant won't change if other resources are embedded in the future.
> 
> and if permissions change in the future, which is highly likely for advertising (that a new third party comes or goes from somewhere in the redirect chain), you have to prompt again, which is a horrible UX, so I doubt sites will actually use this.

I think we're agreed that sites with rapidly-changing lists of third-parties are likely to use the "*" parameter; this use case is about sites that wish to distinguish themselves for their limited set of third parties. A site that doesn't make changes very often may be happy to prompt the user on the infrequent occasions where it adds a new third-party widget that it wants to be able to track the user in a third-party context -- their users have transparency and control in a way that isn't particularly bothersome.

>> * 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.)
>> 
>> Again, you can message purposes out of band. As for having users pick and choose, I think this is both unlikely and complex, though admit it is theoretically possible. However, you could accomplish the same thing if you really cared by letting the user pick and choose what third parties they wanted you to include on their pages if you really cared (e.g. a "grant me an exception and I promise I won't include social widgets")
> 
> The advantage of Do Not Track is that the user can continue to load resources while asking them not to track you. With a origin/origin permissions request, sites don't have to manage different renderings of their site for different users and users can continue to load resources (social widgets, analytics, etc.) while still maintaining their tracking preference.
> 
> I think a common (if not oft-explicitly-stated) assumption is that if a site isn't sure its required elements (e.g. ads) are covered by an exception, it will choose to present the user with a page explaining why it's requesting an exception, as opposed to the actual content. I would not just assume that the site will load and present its regular content to the user if it wants an exception and isn't sure if it's gotten one yet.

I agree that some sites will show different content or not provide access to content if their third-parties cannot track the visitor -- and I think we have and should discuss this explicitly. I expect it will be especially common for publishers to allow access to certain sections of a site based on a user's opting in to certain advertising-focused tracking (like we commonly see with paywalls today). But some other third-parties on the site might *not* be essential to monetization. If I include a series of social network widgets on my site (from which I gather no revenue when they're able to track) do I want to base access to my content on whether a user is willing to opt in to tracking by all of those social networks? Or is the exception I want to ask for about the advertisers on my site that are required elements?

Publishers could theoretically provide different renderings of their site to remove social network widgets in an attempt to get more people to grant tracking exceptions. Or the publisher could provide the same page (simpler, and so that users get the functionality to be able to share the publisher's article by clicking on the social widget, also good for the publisher!) and simply let the user continue to express their tracking preference to those widgets.

>> * 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.)
>> 
>> This seems over-constrained to a particular regime.
> 
> I'm not sure what you mean. Yes, having origin/origin exceptions could help satisfy legal requirements of certain regimes even if those weren't requirements in all legal regimes. I think having a protocol that helps companies satisfy EU legal requirements while not burdening those organizations in other jurisdictions is a positive.
> 
> as I said, introducing the notion of explicit/explicit doesn't complicate things for just a particular subset of users. It complicates things for everyone as it makes the notion of knowing whether or not you are covered by an exception much more complex, for a very niche set of use cases.

As I've said on other threads, I don't think removing the potential for any site to request origin/origin exceptions provides any additional guarantee that all resources on your site receive the same DNT: value. 

Is the niche set of use cases you're referring to all European sites or all European third-party trackers (or maybe all sites that cater to European visitors)? Or the list of use cases we've come up with during this thread? In any case, I don't see that the possibility of a list parameter complicates things for any site that prefers to request an exception with a "*" parameter.

—Nick