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

It's hard to imagine making such substantial changes to where the spec is this late in the game.

best, Joe

--
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
https://www.cdt.org/

On Oct 8, 2012, at 17:42, Fred Andrews <fredandw@live.com> wrote:

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