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

Hi Nick,


thanks for posting the list. This is very helpful input to understanding
whether we need the explicit/explicit piece of our API.

 Based on this list we should now analyse the use cases to determine
whether they indeed require this functionality for their implementation.
Our (and my) goal should be  to understand the usecases better as one
input to our call on wednesday.

Once we know what usecases would no longer be possible without the API,
we can determine whether those cases provide sufficient traction to
justify the additional complexity.

Below I started my personal attempt at analysing and prioritising the
use cases. Since these analysis are somewhat subjective (there are many
ways to design a feature and it is subjective what solutions are
considered 'nice'), feel free to suggest alternatives or comments.


Regards,
 matthias

-------------------------------8<--------------- Use cases analysis
------------------------


On 30/04/2012 08:59, Nicholas Doty 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.)

Importance: This is an important use case.

Design Notes: If I were a site, I would be reluctant to use the API for
this function since I cannot rely on a positive UI experience.

Instead, I would explain to the users somewhere on my site how privacy
protective I am and then ask for a corresponding exception. E.g.,
without the explicit/explicit call, this would mean that at the end of
this 'I am nice'-page, the user would be asked to OK the use of third
parties on this site.
> * 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.)

Importance:
Currently out of scope

Design notes:
I think that purpose-limitation is a use case that is orthogonal to our
explicit/explicit vs site-wide API discussion. Formally, our current
approach to exceptions does not restrict the purposes. If a site wants
to bind itself, it cannot bind itself via the API and will need promises
on a web-site no matter whether we provide the explicit/explicit call or
not.

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

Importance: Medium

Design Notes:
I agree that being able to provide consent via DNT is useful. I cannot
judge what extent explicit/explicit is needed or whether a site-wide
exception would also be considered consent. An important question in
this use case is what responsibilities (under EU law) are implied from
the corresponding "Trust myself and my third parties" statement.

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

Importance: High (small sites should work with DNT)

Design Notes:
These are two important use cases:
a) If a site is small and does not want to ask for a site-wide exception
(like the big guys do) while using tracking based third party services,
then this site could no longer use third party services (e.g.,
comment-spam detectors for their blog) while serving DNT;1 and claiming
compliance.

A workaround would be (assuming that a user uses professional services
and tools such as wordpress) that the site would do out-of-band
exception management. Another option would be that the used services
(e.g. akitmet) would ask for web-wide exceptions to work.

a) The second case where governments are not permitted to ask for
certain exceptions, then I believe that this would hold no matter
whether they ask this as part of an explicit/explicit set or as a
site-wide exception? Or did I misunderstood anything.


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

Importance: Low - I believe that such carve-outs are unrealistic since
80/20 average users will not know these third parties and therefore
cannot make this judgement.

Design Notes:
Privacy experts may use other tools (e.g., blockers or plugins) to meet
this objective. I believe that this API will not increase the opt-in
rate for the following reason: I expect that users will get used to
site-wide exceptions (many sites will request those). If a site then
asks for a explicit/explicit list with a list of names usualy unknown to
the user, this will look unusual and more threatening than the 'usual
click' despite being better for their privacy.

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

Importance: High (we want to allow users from protecting themselves
against certain third parties that they perceive as malicious).

Design Notes: Without additional user agent support, the
explicit/explicit API is not able to provide this functionality.
Similarily (as discussed earlier) getting a site-wide exception granted
does not _guarantee_ that all third parties alwasy receive DNT;0.

As a consequence, I believe that this feature would rather be
implemented by the user agent / plugin that forces DNT;1 to those
'blacklisted'  sites no matter what other exceptions were granted. This
is the reverse idea to the web-wide exceptions.
> * 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.)

I believe it is a principle. I would read 'as little as possible' 
different than you since I perceive a call with "*" to be shorter than a
list of {explicit, explicit}

Received on Tuesday, 1 May 2012 08:10:19 UTC