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

Received on Monday, 30 April 2012 06:59:05 UTC