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

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