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

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).


> * 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")


>
> * 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.


> * 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.)
>
>
Seems to be the same as your first point (companies distinguishing their
limited list of third parties). Though, FWIW i don't really buy that this
is correlated with the size of your site/company. Small sites include ad
networks too, which then branches out to a larger number of third parties.


> * 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.)
>

Again, this seems like it makes things very complex for all parties. Much
easier to just do private browsing in a separate browsing context, no?
(incognito / private browsing mode / ...)


>
> * 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.)
>

I'm not sure I understand this one


>
> * 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.)
>

There's a conflict between data minimization and usability, unfortunately.
In this case, I think usability (and thus adoption) would trump.

FWIW the current model taken by HTML (following TAG and DAP's model) of
requesting individual permissions one at a time has been a nightmare, and
has led to poor user experiences (infobar after infobar) and many sites
shifting to app models (either on mobile, or proprietary models like chrome
extensions/apps) where they can request all the permissions they want. It
has been far from a shining beacon of success.


>
> 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
>
>
>