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

On May 1, 2012, at 7:55 PM, Ian Fette (イアンフェッティ) wrote:
> 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:
>> * 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.

I'm again not sure what the horrible UX is. Jane decides to opt-out of tracker.com across the Web (as in the current self-regulatory opt-out cookie case) and later browses to publisher.com. Publisher.com wants an exception for its third parties and calls requestTrackingException([a.com, b.com, c.com]) with its list of partners A, B and C, not including tracker.com. Jane's browser sees that tracker.com isn't in the list, tells Jane "publisher.com wants an exception for its partners, don't worry, you haven't specifically opted out of any of them" and so Jane approves. (Or maybe even easier, Jane's browser grants the exception for her, no user intervention needed, and remembers A, B and C for her to look at later if she cares.) Alternatively, if publisher.com calls requestTrackingException("*"), what would Jane's browser do? Immediately return false since it's incompatible to possibly opt in to tracker.com even though tracker.com isn't on the site now anyway? Warn Jane that she must opt back in to tracker.com in order to continue to a site that doesn't even include tracker.com? (Is publisher.com willing to risk losing Jane as a reader because of a tracker it doesn't even use?)

Or maybe news.com requests exceptions for a.com and tracker.com; Jane's browser gives her a different warning than usual that news.com needs an exception for a tracker she had specifically configured a DNT preference for earlier, a warning she only has to see at all when a tracker she pre-configured as Do Not Track appears. Or Jane's browser automatically responds with false, granting an exception for a.com but not tracker.com and news.com decides whether it wants to block access to articles.

That a parameter with a list of origins exists does not mean that a user agent ever has to show a list of checkboxes next to domain names, even though that is one conceivable implementation. A user agent that knows the list of origins can help users make decisions about granting exceptions, or allow them to be pre-configured, or remember and change exceptions later.

—Nick