Re: explicit-explicit exception pairs

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> 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> 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"], trackingExceptionHandler);
> >>>>
> >>>> +else if (navigator.supportsWebWideExceptions)
> >>>>  navigator.requestWebWideTrackingException(["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>
> 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>
> 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
> > gelman@blurryedge.com
> > http://blurryedge.com
> >
> >
>
>
>
>