Re: explicit-explicit exception pairs

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