Re: ISSUE-111 - Exceptions are broken

I've received a number of off-list questions about this thread.  In the interest of preserving sanity, I'd like to wrap the thread up.  I think we have agreement that exceptions are not "broken" in any substantial sense.  There do seem to be four open areas of discussion, each of which could be taken up in a separate thread.

1) Should the browser expose an API for a first party to enumerate or poll third-party exceptions?

2) Should the browser expose an API for a third party to enumerate or poll other third-party exceptions?
(ISSUE-109 is CLOSED with a no, owing to fingerprinting risks.)

3) To what extent can a first party or third party share its exception status with a third party?
(ISSUE-114 is PENDING REVIEW with cautionary text in TPE.  TCS is silent on exception status information, meaning it would be governed by the same rules as any other information.)

4) If a third party has a site-specific exception for several first parties, should it be required to silo information for each first party?
(Conversations up until this point have largely assumed the answer is no, and I'm fine with that.  But there seemed to be some suggestion of it in the thread.)

On Mar 12, 2012, at 10:41 AM, JC Cannon wrote:

> In general, it would be great if we could minimize barriers to adoption by reducing the technical implementation requirements. That will also minimize support issues. Even if individual solutions are simple, collectively they could be viewed as too difficult to address. We need to make sure browser vendors, publishers and third parties view our final spec as something they can easily embrace.
> 
> Thanks,
> JC
> 
> -----Original Message-----
> From: Sid Stamm [mailto:sid@mozilla.com] 
> Sent: Monday, March 12, 2012 10:07 AM
> To: Nicholas Doty
> Cc: Kevin Smith; VINCENT (VINCENT) TOUBIANA; Tracking Protection Working Group WG
> Subject: Re: ISSUE-111 - Exceptions are broken
> 
> Hey Nick,
> 
> Sorry for the late reply.
> 
> On 3/8/12 3:53 PM, Nicholas Doty wrote:
> 
>>> I am not sure how to do this using current methodologies.  Take a 
>>> simple example.  Site A has an exception for all 3rd parties and 
>>> includes 3rd Party B which then includes 3rd Party C.  3rd Party C is 
>>> requested from 3rd Party B, not Site A.  How does the browser know 
>>> that 3rd Party C's request originated from Site A?  Certainly 3rd 
>>> Part C probably knows from customized request parameters, but how 
>>> does the browser map the request to its list of exceptions to even 
>>> see the '*' associated with site A?  I think this would be new 
>>> functionality.
> 
>> We opened ISSUE-110 I believe specifically for this question (will 
>> user agents always be able to determine corresponding top-level-origin 
>> for all outgoing requests?) as Vincent was concerned that browsers or 
>> browser extensions might not be able to do this. I believe Sid 
>> informed us that browsers always could (whether it's a redirect, 
>> embedded iframe, XHR request, etc.) which is why it was closed -- Sid, 
>> can you confirm?
> 
> Confirmed.
> 
> The key here is that *all* subordinate loads are subject to some top-level policy regardless of which element is their parent.  It is perhaps new functionality to apply a policy based on the top frame only, but as far as I can tell there's no reason Browsers shouldn't be able to do this.  We draw the stuff on the screen, and there's *always* a causal chain of requests starting with the top level site.  We had to work in part of this space when implementing a "frame-ancestors" part of CSP in Firefox, one that checked all frame/iframe ancestors of an element, and in fact we have to at the very least keep track of at least one level of "ancestry" for iframes due to the same origin policy.
> 
> Now, that's not saying there are bugs in specific bits of browser code that make this hard or impossible for extensions, but due to the way requests are initiated, browser vendors should indeed be able to keep track of the whole chain of loads (redirect, subordinate or otherwise).
> The catch here is that it may not be trivial to implement, but it *can* be engineered.
> 
> -Sid
> 
> 
> 
>

Received on Wednesday, 14 March 2012 01:14:12 UTC