Re: explicit-explicit exception pairs [a proposed resolution to ISSUE-140]

I think the text I sent on the API covered explicit-explicit cases, and no-one seems to have commented.  I don't think they are terribly useful, but I don't see any reason to ban them either.

On May 14, 2012, at 17:05 , Matthias Schunter wrote:

> Hi Folks,
> 
> 
> I believe that we should aim for a solution that balances complexity and end-user control.
> We may 'trial' such a limited solution during our call for implementation (our sort of beta phase) and revisit the decision later.
> 
> Would you be OK with this 'package':
> - We allow explicit/explicit for directly used third parties (e.g., an ad network)
> - We declare exceptions to be transitive (exempting an ad-network exempts the corresponding ad providers)
> - We introduce a DNT;2 signal that signals that explicit/explicit exceptions are in place and that they may 
>   interact with their third parties or poll to determine whether a sufficient subset has been granted
>   (while DNT;0 signals a site-wide exeption)
> - We allow user agents to provide their own UI that may hide complexity (e.g., using the same UI for site-wide
>   and explicit/explicit exceptions)
> 
> Jointly, these measures should:
> - This should reduce UI complexity
> - This should reduce the need for polling [I believe that polling can be locally by a delivered Javascript code that 
>     contains the minimally required third parties and only calls the site to complain if this set is not exempted]
> - This should simplify consent collection in the EU 
> 
> What do you think?
> 
> If you see alternative solutions for explicit/explicit that provide a better balance, feel free to share them.
> Also tell us if you cannot live with such a simplified solution. 
> 
> 
> Regards,
> matthias
> 
> PS: Some arguments that were exchanged during the discussion DISCUSSION on explicit/explicit
> - Explicit/explicit should be transitive to simplify the scheme while providing benefits in the EU
>   , i.e., asking for exception for your directly used third parties will auto-grant exceptions to their descendants.
> - Explicit/explicit may simplify consent collection in EU context (naming additional controllers and/or processors)
> - Explicit/explicit may make the user-agent UI complicated
> - Explicit/explicit allows users to implement fine-grained preferences
> - Explicit/explicit allows users to realize when new 3rd parties have been introduced
> - Explicit/explicit allows users to deny exceptions to an individual 3rd party (not being required to deny all).
> - Explicit/explicit makes it harder for sites to determine whether their key third parties are OK or not
> - The UI for explicit/explicit can be simplified by only asking users broader questions
>    (e.g., do you accept thirdparties on this site) while recording fine-grained exceptions.
> - Explicit/explicit fosters user agent innovation
> 
> 
> 
> 
> 
>   
> 
> On 01/05/2012 00:38, Ian Fette (イアンフェッティ) wrote:
>> 
>> The question isn't on the complexity imposed on an analytics service. The question is the complexity imposed on a website with potentially multiple ad companies and other third parties trying to figure out what third parties are granted exceptions. You get into a state where you require polling, which for me is a non-starter.
>> 
>> -Ian
>> 
>> On Mon, Apr 30, 2012 at 2:59 PM, Jonathan Mayer <jmayer@stanford.edu> 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 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 

David Singer
Multimedia and Software Standards, Apple Inc.