RE: ISSUE-111 - Exceptions are broken

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 Monday, 12 March 2012 17:42:51 UTC