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

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.

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

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

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

Sorry if I've duplicated or miscategorized. I was using the smaller sites example (based on my personal experience with academic sites) as an example of sites that do have an enumerated list of third parties and often don't use an ad exchange. 

I agree that owners of small businesses, for example, may not have a better understanding of their list of third parties. As I tried to include in this case, installation of widgets that site owners don't fully understand (which I think we agree is more common in small sites) means that a site owner might be making a request for more permissions than they realize if they only have a site-wide option.

A related example: if a site hosts user-generated content that includes resources from other servers (a comment with an image in it, say), a site-wide tracking exception would mean the user agent had to opt the user in to tracking by servers the site itself had no knowledge of. Are sites comfortable with that?

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

I don't expect all users to make carve-out style choices, but if they did then it doesn't seem like private browsing mode would satisfy the case. This is a case where users might be willing to opt-in to some tracking -- maintaining long-term cookies that build a profile about them and everything -- for some trackers but not others.

Also, I think that sites that are making a tracking exception request probably don't want their users to feel the need to visit while in incognito mode -- that would likely decrease their monetization or other tracking need that was the entire reason for making the request.

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

Hmm... can you help me know where I'm losing you here? As in the current case of self-regulatory opt-out cookies, a user might choose to opt-out of a particular tracker wherever they see them on the Web. If that has been pre-configured and a site asks for a site-wide exception (a site that might include that tracker), won't the user agent have to reject that request?

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

I'd be happy to continue that general discussion of privacy techniques on the public-privacy list. I wouldn't call the "all-or-nothing" model of apps much of a shining beacon itself, given the research on users' lack of understanding in those cases.

I think user agents are encouraged (and capable) of building usable interfaces even when the underlying permission request model has some granularity. For example, I imagine that a lot of users could configure their browsers to automatically grant requests (no user interface at all!) if the list of origins that permissions are being requested for is present and, for example, they've granted requests for those trackers' origins in the past. I expect many user agent developers will conclude that a site-wide request for an unknown list of tracking parties will more often require user intervention.

I also think data minimization is a separate principle from just-in-time or separate notices, which seems to be your concern with multiple infobars. I don't think we're debating here when tracking exception requests should be handled, or how separately they need to be handled, just the breadth of permission requested. I don't see that specifying the breadth of permission that a site needs conflicts with end-user usability.

Thanks,
Nick