Re: explicit-explicit exception pairs

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