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

Shane,

 

OK, I agree with that. Let's hear what others have to say.

 

Mike

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 03 December 2012 16:53
To: Mike O'Neill
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

Agreed - but not crippling 1st parties in the same pass.  The goal is to
drive high, voluntary implementation rates - we'll need to focus on balance
to get there.

 

- Shane

 

From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Monday, December 03, 2012 9:47 AM
To: Shane Wiley
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

Shane.

 

But they might be out of reach in another jurisdiction. The first-party is
not purposefully embedding them, maybe just unwisely using some external
non-vetted script. Granted, this is a security rather than a privacy issue,
but we should be aware of the danger we are exposing first-parties to.

 

Mike

 

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 03 December 2012 16:10
To: Mike O'Neill
Cc: public-tracking@w3.org
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

Mike,

 

Your description is exactly why a regulator would NOT hold the first party
liable for the situation.  The 3rd party in your use case is purposely being
malicious and now they've stupidly created their own noose to hang
themselves by leaving an evidence trail.

 

- Shane

 

From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Monday, December 03, 2012 8:57 AM
To: Shane Wiley
Cc: public-tracking@w3.org
Subject: RE: ISSUE-187 - What is the right approach to exception handling &
ISSUE-185

 

Hi Shane,

 

We might not be able to thwart them but we should not make their job too
easy. I was thinking about the situation where an external script library
dynamically creates an iframe pointing to an external domain, which then
silently calls the API (and uses UUIDs). The first-party site could be
unaware of it but regulators could hold them responsible, especially as it
applies across the whole web.

 

 

Mike

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 03 December 2012 00:12
To: Mike O'Neill; David Singer
Cc: public-tracking@w3.org
Subject: 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