Re: explicit-explicit exception pairs

On Monday, April 30, 2012 at 7:18 PM, Ian Fette (イアンフェッティ) wrote:

> On Mon, Apr 30, 2012 at 7:12 PM, Jonathan Mayer <jmayer@stanford.edu (mailto:jmayer@stanford.edu)> wrote:
> > For clarity, I'm going to break out these two assumptions.  
> >  
> > 1) If we support only site-wide exceptions, a first party won't have to jump through hoops to learn an individual third party's status.
> >  
> > Sure - but we know we're not going to support only site-wide exceptions.  We're also going to support web-wide (and out-of-band) exceptions.  Those give rise to the same difficulties in learning an individual third party's status as explicit-explicit exceptions.  
>  
> A first party has very little reason to care about web-wide third party exceptions.
I strongly disagree.  The presence of a particular web-wide exception may affect content, layout, or whether additional exceptions are requested.  There's some discussion of use cases in the "A First-Party List API for Site-Specific Exceptions" thread.
> As for out of band exceptions, a site by definition has knowledge of what out of band exceptions it has, so again I don't think that's a factor.
>  
>  
>  

An out-of-band exception need not be requested by a first party, and it need not be site-specific.  The very same issues crop up.
> > 2) If a first party wants to learn an individual third party's status and there isn't a site-wide exception, the first party has to poll.
> >  
> > There are several viable options for a first party to learn of an individual third party's status.  (See the thread "A First-Party List API for Site-Specific Exceptions" for discussion.)  
> > -A list API scoped to the domain of the top-level window.
> > -A polling API with varying degrees of anti-fingerprinting measures (e.g. no limits for the top-level window's domain, rate + domain limits for third-party domains).
> > -An ad hoc polling approach that uses existing web technologies.
> > None of these seem excessively burdensome in implementation or performance.  
> >  
>  
>  
> All of these are polling approaches which adds at least 1xRTT before you can decide whether you want to serve content or a request for exceptions, which is not acceptable.
The group hasn't yet discussed how first parties can gracefully handle DNT status changing on-the-fly.  We should.  (Suggestion: new ISSUE.)  That said, there's certainly no need to delay the user experience by an extra roundtrip.
> >  
> > On Monday, April 30, 2012 at 6:24 PM, Ian Fette (イアンフェッティ) wrote:
> >  
> > > Yes. My assumption was that if DNT only had site-wide exceptions, it would be trivial for you to know if everything on your site was covered by a site-wide exception. If instead users can pick and choose, then you know either "i have no exception and should ask if i want one" / "i have a site-wide exception" / "i have no clue, some part of me has an exception but whether that's sufficient for me or not I don't know so now I have to poll, and for privacy maybe I don't even get to poll for specific things so who knows". The latter necessitates polling as you can't reasonably list all the third parties that have exceptions in the request headers.
> > >  
> > > -Ian
> > >  
> > > On Mon, Apr 30, 2012 at 6:09 PM, Jonathan Mayer <jmayer@stanford.edu (mailto:jmayer@stanford.edu)> wrote:
> > > > Ian,  
> > > >  
> > > > Could you unpack your reasoning in "[the] existence [of explicit-explicit exceptions] meaning it requires polling for some set of users to figure out the state of the world, as opposed to a request header"?  I think there may be erroneous assumptions lurking in there.  
> > > >  
> > > > Thanks,
> > > > Jonathan
> > > >  
> > > > On Monday, April 30, 2012 at 5:54 PM, Ian Fette (イアンフェッティ) wrote:
> > > >  
> > > > > This seems like the worst of all possible worlds. Sites still have to handle all the complexity of explicit/explicit exceptions (their existence meaning it requires polling for some set of users to figure out the state of the world, as opposed to a request header). They have to handle multiple different "regimes" -- at this point, why don't we just let each browser define their own DNT mechanism?
> > > > >  
> > > > > On Mon, Apr 30, 2012 at 5:04 PM, Tom Lowenthal <tom@mozilla.com (mailto:tom@mozilla.com)> wrote:
> > > > > > I don't see a problem here. It's up to web browser to discover and store
> > > > > > their users' preferences. The API just describes the way to communicate
> > > > > > that info to JS.
> > > > > >  
> > > > > > ---
> > > > > >  
> > > > > > Say Chrome decides to implement only exceptions which have a star in
> > > > > > them, because they think that that most works best for most users. If
> > > > > > they get a request, they sanitize it into first/* or */third, and
> > > > > > compare it with their data structure or talk to users.
> > > > > >  
> > > > > > PrivacyBrowser only implements first/third, no stars, because that's
> > > > > > what they think works best for *their* users. If they get requests with
> > > > > > stars, they say no, because their uses have no truck with that sort of
> > > > > > thing.
> > > > > >  
> > > > > > SimpleBrowser only does wildcards, and ignores first/third. In
> > > > > > SimpleBrowser, if a site has an exception, it gets DNT:0 whether it's
> > > > > > first or third party, all its third parties get DNT:0 too, and it
> > > > > > replies to JS requests appropriately.
> > > > > >  
> > > > > > UxNightmareBrowser doesn't store preferences, it just asks users for
> > > > > > each tuple one at a time, in the form of modal dialog boxes. They're
> > > > > > totally compliant with the DNT API, but for some reason don't get a lot
> > > > > > of market share...
> > > > > >  
> > > > > > ---
> > > > > >  
> > > > > > My point is that all of these are technically compliant, but provide
> > > > > > different interface drawbacks. Some of them reduce the granularity of
> > > > > > the representation that they store of user preferences. Some of them
> > > > > > impose additional mental costs on users.
> > > > > >  
> > > > > > These are issues of user experience, and browsers need to compete on
> > > > > > them. This working group simply can't design, mandate, or perhaps even
> > > > > > imagine the best balance of all the different interface constraints. We
> > > > > > should create a specification which gives UX designers the building
> > > > > > blocks that they need to make great future browsers that implement DNT.
> > > > > > That doesn't mean that we know exactly what they'll look like.
> > > > > >  
> > > > > >  
> > > > > > On 04/30/2012 04:19 PM, Lauren Gelman wrote:
> > > > > > >
> > > > > > > I think there is a significant and real concern that the exceptions -- by offering an all or nothing approach -- are going to eat the rule.  I also agree the case has been made that they are necessary.  Adding some granularity may encourage sites to compete on privacy.  So instead of asking for a blanket site-wide exception, a publisher may ask for an exception for a limited group of privacy-friendly advertising options.  Or small publishers may use a DNT solution plug-in that provides a balanced approach.  Not all websites have the complexity of the ones that are typically used as examples for this group.
> > > > > > >
> > > > > > > Of course there is no demand now because publishers have no idea what the new landscape will look like.  Obviously, the # of people who go DNT:1 is unknown.  But if you don't build this option into the API, there is no chance it will happen.  So I think that if there is agreement that it is manageable and there is no requirement that anyone do anything, than why not include it??
> > > > > > >
> > > > > > > On Apr 30, 2012, at 3:45 PM, Matthias Schunter wrote:
> > > > > > >
> > > > > > >> Hi Jonathan,
> > > > > > >>
> > > > > > >>
> > > > > > >> I agree that the complexity seems manageable.
> > > > > > >>
> > > > > > >> As a group, I believe that it is nevertheless important to understand 'why do we need this feature'  and then 'What is the best (=minimum complexity / least cost / most usable / ...) way to achieve this goal.
> > > > > > >>
> > > > > > >> I believe that we need to revisit the first question 'why is the feature needed' and what use cases cannot be implemented without it (e.g., by after-the-request logging):  I currently do not see a strong push from web-sites to request such exceptions. Since this feature is designed to be used by web-sites, this should tempt us to drop it unless it provides clear benefits to other stakeholders even if only used by few sites.
> > > > > > >>
> > > > > > >> Are there other requirements/use cases that I've overlooked or am I mistaken in another way?
> > > > > > >>
> > > > > > >> Feedback is welcome!
> > > > > > >>
> > > > > > >>
> > > > > > >> Matthias
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On 30/04/2012 23:59, Jonathan Mayer wrote:
> > > > > > >>>
> > > > > > >>> The complexity seems quite marginal to me.  Here's what an analytics service that prefers explicit-explicit exceptions might do with a boolean flag approach.  (A + denotes an additional required line.)
> > > > > > >>>
> > > > > > >>>> var trackingExceptionHandler = function(status) {
> > > > > > >>>>  // Handle acceptance and rejection gracefully…
> > > > > > >>>> }
> > > > > > >>>>
> > > > > > >>>> +if(navigator.supportsExplicitExceptions)
> > > > > > >>>> + navigator.requestSiteSpecificTrackingException(["exampleanalytics.com (http://exampleanalytics.com)"], trackingExceptionHandler);
> > > > > > >>>>
> > > > > > >>>> +else if (navigator.supportsWebWideExceptions)
> > > > > > >>>>  navigator.requestWebWideTrackingException(["exampleanalytics.com (http://exampleanalytics.com)"], trackingExceptionHandler);
> > > > > > >>>>
> > > > > > >>>> else {
> > > > > > >>>>  // Use super-sweet out-of-band exception mechanism
> > > > > > >>>> }
> > > > > > >>>
> > > > > > >>> Pretty painless.
> > > > > > >>> On Monday, April 30, 2012 at 2:22 PM, Ian Fette (イアンフェッティ) wrote:
> > > > > > >>>
> > > > > > >>>> As a website operator, your proposal adds even more complexity to the mix. This is not a good idea.
> > > > > > >>>>
> > > > > > >>>> On Mon, Apr 30, 2012 at 1:55 PM, Jonathan Mayer <jmayer@stanford.edu (mailto:jmayer@stanford.edu)> wrote:
> > > > > > >>>>> As best I can tell, here's the current state of the debate: Some working group participants believe there are important use cases for explicit-explicit exceptions, others do not.  Some browser vendors are willing to implement support for explicit-explicit exception pairs, at least one is not.
> > > > > > >>>>>
> > > > > > >>>>> Given that background, how's this as a compromise: We make support for the various exception types optional for browsers, and we include some ability for a website to learn which exception types are supported by a browser.  A website isn't left guessing how a browser will interpret its exception requests, and a browser vendor is free to pass on the exception types that it doesn't believe it can provide a good user interface for.
> > > > > > >>>>>
> > > > > > >>>>> One approach would be to include simple flags that indicate support (e.g. booleans like navigator.supportsWebWideExceptions).  Another approach would be to modify the TrackingResponseCallback to handle a not-supported state.  If a website learns the browser doesn't support its preferred exception type, it can fall back to a different exception type or an out-of-band exception.
> > > > > > >>>>>
> > > > > > >>>>> On Monday, April 30, 2012 at 9:37 AM, Ian Fette (イアンフェッティ) wrote:
> > > > > > >>>>>> I'm a bit perplexed as to the fact that you think a UI such as the one you describe would actually be compliant. I thought the whole point of this exercise was to allow the user to express a preference and translate that as directly as possible to something that can be passed on to websites they visit.
> > > > > > >>>>>>
> > > > > > >>>>>> If you start picking and choosing from the API as if it were a buffet, where does that leave you? You seem to imply it's fine for a UA to ignore the explicit nature of a "first/third" exception and turn it into a "first/*". Would it be                                     equally fine then to just ignore the distinction between "first/*" and "*/third" and just offer "site" exception regardless of first/third issues? Or just to ignore exceptions all together and say "Eeh, it's a UI issue, if the site grants an exception to anything we'll just turn off DNT globally."
> > > > > > >>>>>>
> > > > > > >>>>>> I think what is being proposed is unworkable and people are trying to use the notion that it's "just a UI issue" to keep it in the spec. This is not a good idea.
> > > > > > >>>>>>
> > > > > > >>>>>> As for the new corner cases, I think many of us are expecting that there will be new regulatory considerations (either under existing or future regulatory regimes) that will involve DNT. Whenever there are new considerations, there are new corner cases. For instance, cookie blocking doesn't actually send any explicit signal to the server, nor does the server have any clue as to what the heck is actually going on. Now we're giving servers a clue, hence there's much more complex considerations.
> > > > > > >>>>>>
> > > > > > >>>>>> -Ian
> > > > > > >>>>>>
> > > > > > >>>>>> On Mon, Apr 30, 2012 at 12:24 AM, Nicholas Doty <npdoty@w3.org (mailto:npdoty@w3.org)> wrote:
> > > > > > >>>>>>> On Apr 25, 2012, at 8:21 AM, Ian Fette (イアンフェッティ) wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> Also, I don't think we should just punt something by saying "It's a UI issue." The spec has implications on UI that should not be ignored. explicit/explicit means we have to come up with UI to support this, where so far we have failed, it means sites now have to worry about corner cases they didn't before, etc.
> > > > > > >>>>>>>
> > > > > > >>>>>>> I agree with Rigo that this is a UI issue in the sense that user agent developers are completely free to decide whether or not to create what kind of UI they want. (We were able to discuss this confusion in DC, but only briefly, so I'll try to recap.) If Google Chrome decides that its users never want or need to see a list of domains, even when a site requests exceptions for a specific list, Chrome need not present any such UI; the browser can just display whatever UI the Chrome team creates for a site-wide exception and the team doesn't have to come up with any other UI. The browser also may choose not to store the list version of the permissions but just store a site-wide permission, or not to store the permission at all, the spec explicitly leaves all of these choices up to the user agent implementation. (Section 6.5 lists several other UI decisions that are also completely up to the user agent developer.) I expect user agent UIs to vary -- some browsers will use a
> > > > > >  simple b
> > > > > > uilt-in UI to avoid burdening their users; a developer of plugins for particularly privacy-conscious users might build a more complex configuration panel. Vive la différence.
> > > > > > >>>>>>>
> > > > > > >>>>>>> What are the corner cases that sites have to worry about that they didn't before? In the current self-regulatory opt-out cookie system the publishing site never gets an indication of whether one of its advertisers received an opt-out signal (unless it communicates on the server side) and the site may have a mix of advertisers that received opt-out cookies or not. Sites that only wish to ask for site-wide exceptions can always call requestSiteSpecificTrackingException with the "*" parameter; that some unrelated sites specify a list of origins in the parameter need not affect them. Of course, even sites that always use "*" may still receive visitors where some of their parties receive DNT:0 and others receive DNT:1, but that situation will exist whether the JavaScript API takes a list parameter or not.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Hope this helps,
> > > > > > >>>>>>> Nick
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >
> > > > > > > Lauren Gelman
> > > > > > > BlurryEdge Strategies
> > > > > > > 415-627-8512 (tel:415-627-8512)
> > > > > > > gelman@blurryedge.com (mailto:gelman@blurryedge.com)
> > > > > > > http://blurryedge.com
> > > > > > >
> > > > > > >
> > > > > >  
> > > > >  
> > > >  
> > >  
> >  
>