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

On Tue, May 1, 2012 at 7:01 PM, Nicholas Doty <npdoty@w3.org> wrote:

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


and if permissions change in the future, which is highly likely for
advertising (that a new third party comes or goes from somewhere in the
redirect chain), you have to prompt again, which is a horrible UX, so I
doubt sites will actually use this.


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

I think a common (if not oft-explicitly-stated) assumption is that if a
site isn't sure its required elements (e.g. ads) are covered by an
exception, it will choose to present the user with a page explaining why
it's requesting an exception, as opposed to the actual content. I would not
just assume that the site will load and present its regular content to the
user if it wants an exception and isn't sure if it's gotten one yet.


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

as I said, introducing the notion of explicit/explicit doesn't complicate
things for just a particular subset of users. It complicates things for
everyone as it makes the notion of knowing whether or not you are covered
by an exception much more complex, for a very niche set of use cases.


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

I understand what you're saying now, but saying that allowing a user to
pick and choose exceptions on a site meets this usecase, while technically
true, is a horrible UX that I doubt many people would do, and again I have
no idea how many sites would actually deal with users picking and choosing
from their list of exceptions. I frankly expect it would be all or nothing
for most cases.



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