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

I agree with the proposed changes in ISSUE-140, as otherwise mandating that there be a UA UI for exceptions will lead IMO to insurmountable UI scalability issues  (the "cognitive burden") as each HTTP-enabled application on the device would have to provide such a UI (DNT support is the responsibility of much more than Web browsers).

Enabling sites to manage exceptions and related UI will enable more rapid innovation in privacy preferences management. Coupled with a device-wide privacy preferences management service (an implementation option) that provides a unified UI for all HTTP-enabled applications on the device, the JavaScript API will make it possible to scalably align site-managed (out-of-band) preferences with the DNT settings in the device. This makes perfect sense to me as users should be able to trust the sites they visit, and could verify that trust as needed with the help of their device's privacy preferences service. Such a service could ensure that any requested exceptions, regardless of which application is connecting to the site requesting the exception, is consistent with the user's preferences or is validated by a single/consistent UI (which will result in the lowest "cognitive burden").

Thanks,
Bryan Sullivan

From: Fred Andrews [mailto:fredandw@live.com]
Sent: Monday, October 08, 2012 8:43 AM
To: Matthias Schunter (Intel Corporation); Jonathan Mayer
Cc: public-tracking@w3.org
Subject: 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<mailto:mts-std@schunter.org>
To: jmayer@stanford.edu<mailto:jmayer@stanford.edu>
CC: public-tracking@w3.org<mailto: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.