RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions)

* The browser needs a UI to handle exceptions for non-JS resources anyway, so allowing each site to define its own UI just increases the cognitive burden on the user.

* Having both a site UI followed by a UA UI confirmation also increases the burden on the user.

* A UI designed to assist the user could be very different to a UI designed for the benefit of the website so it is not possible to leave this to the website.  For example a UI designed to help the user may just default to 'no' for any exception request, whereas a UI designed to help the website could have just one option (accept to proceed) or could just blindly apply exceptions and justify it a privacy policy.

Could someone explain why any site would need to have 'essential' tracking exceptions (from the users perspective)?

There are a large range of tracking elements used on pages, but not one occurs to me that is essential for users.  Being profiled and having custom content delivered is hardly essential.

If tracking is really essential for some resources then they can simply respond with an appropriate tracking status value and the UA can decide if it will accept this.  This should be easy for a webpage to do by including an appropriate option or link to the third party resource.  This avoids the need to even ask the UA to communicate the exception in the resource request - the UA can still request DNT:1.  If necessary then perhaps a separate tracking status value could be defined that indicates that DNT:1 has been refused due to a first party request and the UA can then query the user if necessary to accept the exception and indicate to the user that the first party considers it essential.

Servers receive the DNT header and this should be enough for them.  They should have no need to be able to query the exception for themselves or to query exceptions for third party resources.  The UA exceptions are a private matter for the user that the user will communicate to the third party without leaking the choice to the first party.

I expect users will tire of this exception process very quickly.  Users who enable DNT probably do not want to answer many exception requests and will just default all to 'no' anyway.  Users that do want some exceptions will mostly likely use a few web-wide exceptions for sites they trust and exclude all others.

I suggest leaving the exceptions out of the spec. and leave it as a UA implementation matter because it does not appear to be an interoperability matter and UAs should be free to explore alternative UI designs in this area and the w3c can not dictate UI design.

cheers
Fred

Date: Mon, 8 Oct 2012 09:32:35 +0200
From: mts-std@schunter.org
To: jmayer@stanford.edu
CC: public-tracking@w3.org
Subject: Re: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions)


  
    
  
  
    Hi Jonathan,

      

      

      in the meantime, there is a revised proposal by the browsers on
      the table. Basic ideas:

      - Unchanged: 3 types of exceptions: site-wide, web-wide, and
      explict lists

      - New: Sites are responsible for UI and for determining exceptions

      - New: Browsers are free to validate/adjust exceptions based on
      user preferences

      - New: No atomicity requirement anymore

      - New: We added a query API where a site can validate whether its
      "essential" exceptions are still present

           in order to double-check that it is still working as
      intended. 

      

      Some advantages (from my personal perspective) are:

      - Sites can provide a consistent experience

      - Browsers can now freely manage preferences as determined by
      their users

      - Sites can store a broad range of exceptions ("these are my 30
      third parties" while later querying a subset "I need these 10 to
      work").

      

      We have an action pending to elaborate this new proposal (AFAIR on
      Ian Fette). Feel free to comment once we obtain text documenting
      it in more detail.

      

      

      Regards,

      matthias

      

      

      On 08/10/2012 03:20, Jonathan Mayer wrote:

    
    
      

      
      On Wednesday, October 3, 2012 at 12:42
        AM, Matthias Schunter (Intel Corporation) wrote:
      
        
          
            
              
              Hi Jonathan,

                

                

                thanks for the feedback!

                

                As part of the other response, you said that you
                disagree with the all-or-nothing approach of the API.

                I agree that this needs discussion.

              
            
          
        
      Yes.  Is there a separate
          issue for whether exception requests are all-or-nothing?  If
          not, there should be.