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

On Monday, October 8, 2012 12:33 AM, Matthias Schunter wrote:
> 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.

My exception API proposal retained the explicit list option from the current
spec because a) I wanted to minimise differences to allow people to more easily
compare; and b) because some people I spoke to asked for this remain included.

However, it remains an optional feature (user agents may ignore the arrayOfSites
argument) and, as I said based on the discussion at the F2F, I don't believe
it is workable.

I think it adds unnecessary complexity to user agents were they to implement
it, adds unfeasible complexity to sites trying to maintain the exception list
in the face of dynamic relationships with third parties, and damages users'
ability to form a mental model of what DNT does for them.

My preference would be to remove this from the spec for now and keep the API
simple until we have more implementation experience. In general, I'd rather
satisfy the 80% case now and come back and refine in future. I think this
is something that could be added as a new feature later. At the very least,
I'd recommend this feature be marked "at risk" for CR [1].

Cheers,

Adrian.

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

Received on Monday, 8 October 2012 13:36:50 UTC