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

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

On May 1, 2012, at 1:09 AM, Matthias Schunter wrote:

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

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.

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

Maybe this was unclear, I meant "purposes" in the sense of different categories of trackers (which the hosting site might effectively use for different purposes). Maybe the publisher only needs to request a tracking exception for a sub-set of the third parties on his page, or can do so at different times or in different contexts. I agree that we're not talking about user-granted exceptions for particular uses of data by third parties.

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

I also welcome input from Ninja, Rob and others on this issue.

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

I'm not sure out-of-band exception management is relevant to this case. A small site is likely to be a first party, but we're talking about getting tracking exceptions for third parties on the page. The server-to-server communication needed to communicate an out-of-band exception from a first-party to a third-party may be difficult (avoiding that kind of communication was one of the design criteria we used in authoring this section).

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

A government player might be allowed to request an exception for a particular third party whose practices it had verified. But it might still want to include widgets on the same page (allow the user to continue loading those resources) without requiring the user to grant a tracking exception to those 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.)
> 
> 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.

I think one advantage of Do Not Track is that we can encourage users who would otherwise block resources altogether to continue loading resources (like advertisements) while sending a tracking preference.

It may not always be individual users reading and recognizing a particular domain name that chooses them to carve out an exception; plug-ins could help them, for example.

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

I'm not sure if we're all clear on this, so it would be worth discussing further. If a site asks for a site-wide exception and a user grants that exception but continues to send DNT:1 to some or every third party on that site, are publishers okay with that?

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

Data minimization refers to minimization of information collected (or used, or retained) about a user. Although the "*" parameter is fewer characters sent from the site to the user agent, the exception that it grants would potentially increase the parties collecting, retaining or using data about the user's interaction.

—Nick

Received on Wednesday, 2 May 2012 07:55:06 UTC