RE: ISSUE-187 - What is the right approach to exception handling & ISSUE-185

Mike,

I continue to disagree for this approach for web-wide exceptions for the same basic 'attempting to thwart bad actors (who will NOT implement DNT in any form of good faith) and creating barriers for good actors'.  In this case, good actors have several mechanism that will keep their operations appropriately in-line with compliance requirements:


*         A written record of their exception claim - directly auditable by industry, advocates, and regulators.

*         A 3rd party attempting to request an exception in the context of a 1st party interaction will be immediately booted/blocked by that 1st party (3rd parties have monetary motivation/risk to ensure they get this right)

This approach forces 1st parties to redirect users to 3rd party sites so a web-wide exceptions can be requested - causing additional overhead on the entire process and further disadvantages 3rd parties - to the point where I doubt m/any will implement DNT without the ability to manage their web-wide exceptions in understood and agreed upon 1st party interactions.

- Shane

From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
Sent: Sunday, December 02, 2012 4:28 AM
To: David Singer
Cc: public-tracking@w3.org
Subject: RE: ISSUE-187 - What is the right approach to exception handling & ISSUE-185

David,

I think the new API is fine for site-specific exceptions, because we are putting the responsibility to get user agreement on sites where it is legally anyway.

The sentence in 6.4.1 (The execution of this API and the use of the resulting permission (if granted) use the 'implicit' parameter, when the API is called, the document origin. This forms the first part of the duplet in the logical model, and hence in operation will be compared with the top-level origin) makes it clear that only script in the context of the top-level origin can register a UGE for the site. If script in third-party embedded iframe makes a SS UGE call, the implicit document origin points to the third-party domain so the exception applies there and not at the parent window's origin.

Unfortunately this is not true for the web-wide API so it is possible that script inside a child iframe could register an exception, which may not reflect a user's intention.

If we decide to keep web-wide exceptions under the new UI-less regime it would be safer to limit them to script in the context of top-level origin, which effectively is the situation for site-specific exceptions. I suggest we put a sentence like the following into 6.5.1 (and similar in 6.5.2),

The web-wide exception is only granted if the document origin host of the calling script is the same as the top-level origin host.


Mike