- From: David Singer <singer@apple.com>
- Date: Mon, 21 May 2012 10:10:34 +0200
- To: Jonathan Mayer <jmayer@stanford.edu>
- Cc: Rigo Wenning <rigo@w3.org>, Shane Wiley <wileys@yahoo-inc.com>, "rob@blaeu.com" <rob@blaeu.com>, Mike Zaneis <mike@iab.net>, Kimon Zorbas <vp@iabeurope.eu>, "ifette@google.com" <ifette@google.com>, "public-tracking@w3.org" <public-tracking@w3.org>, Nicholas Doty <npdoty@w3.org>, Matthias Schunter <mts-std@schunter.org>
On May 9, 2012, at 1:04 , Jonathan Mayer wrote: > This thread began with a discussion of whether the specifications should include support for explicit-explicit exceptions. In the interest of sanity, civility, and inbox control, I'd like to pop the conversational stack and return there. > > The first issue we had to consider was whether there are use cases that necessitate explicit-explicit exceptions. We've now heard from quite a few stakeholders that explicit-explicit exceptions are important in the EU owing to the ePrivacy Directive. We've also previously discussed several other scenarios where explicit-explicit exceptions would be helpful. (Nick sent an email with a convenient list.) I think it's fair to say sufficient use cases have been raised to warrant thinking through how to implement the feature. If the technical complexity is excessive, we can circle back to whether the feature is worthwhile. > > Ian has raised some technical concerns about how explicit-explicit exceptions would work in practice. I think that would be a productive place to refocus the conversation. My feeling is that they have a place, and can be manageable. Why do they have a place? There are a variety of 'third parties' that might end up on a 1st party site: * 3rd parties of the 1st party's choosing, essential to the operation, and maybe monetization of the site, with whom the 1st party has a managed relationship; (primary ad servers, analytics, and so on); * 3rd parties of the 1st party's choosing that do little or nothing for the 1st party, but add value in the perception of the users (social buttons, etc.); * 3rd parties that are included to provide content that completes or adds value to the site (widgets etc.); * 3rd parties that are pulled in by other third parties (e.g. ad servers, analytics, etc. pulled in by widgets). When the 1st party explains to the user why it wants the site-wide exception grant, it may well wish to state something about its belief in what those 3rd parties will or won't do; there almost certainly needs to be some sort of 'overall' statement about the behavior of 3rd parties that will get an exception. For these reasons, I think it quite possible that sites will want to ask for exceptions only for the first bullet, above - the 3rd parties that really matter to their operation. Social networking buttons would be better covered by the user granting (or not) a web-side exception to them. Quite how to handle mash-ups that need to monetize, I am not sure… Ian has said he's concerned about managing the UI, and I see that, but I think it is manageable. Example "Swampville Chronicle is asking you to confirm that you grant a site-wide exception to DNT to its selected third-parties" - and "selected" could be a link or have a hover that reveals their names, for the truly curious. I quite agree with him that the site names will probably mean little to the user. I think that the management of the UI and the management of the 'grants database' can use and expose information differently. The alternative to (site, site) pairs is to ask for a general site-wide exception for all 3rd parties that are now, or will be in future, embedded (site, *). That may be asking a very open-ended question of the user. David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 21 May 2012 08:11:18 UTC