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

Why don't you provide some good explanatory text? Shane, Mike?

 -- Rigo

On Monday 03 December 2012 17:02:43 Mike O'Neill wrote:
> 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

Received on Thursday, 6 December 2012 10:30:17 UTC