Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)

2) window.parent.location has always been disallowed from reading cross-originYes, but document.referrer of an IFRAME == parent.location and this has always been allowed.
Scenario is. . .frame cannot set x-frame options, or frame-ancestors b/c it doesn't necessarily know all allowedhosts.  

Instead it looks at HTTP referrer/document.referrer, and what level the nesting occurs, and logs this information, 
and whenever that parent matches something "untrustworthy" (by monitoring logs pseudo-offline), take some action.
In other words, you have some widget that's allowed to be embedded by "most" origins, so long as it's embeddedat the right level and so long as said widget can establish "who" the origin is. . .
Sean


      From: Brad Hill <hillbrad@gmail.com>
 To: Sean Snider <ssnider@yahoo-inc.com> 
Cc: Frederik Braun <fbraun@mozilla.com>; "public-webappsec@w3.org" <public-webappsec@w3.org> 
 Sent: Sunday, November 2, 2014 6:43 PM
 Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
   
Sean,

 I'm going to repeat Mike's request to clarify against the points he raised at:

http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0110.html

 In particular, the points that:

1) referrer does not reliably contain the embedding parent window's location,
2) window.parent.location has always been disallowed from reading cross-origin
3) frame-ancestors is the correct way to only allow embedding from
particular origins.

What exactly are you doing and how is it going to break?  If you are,
e.g. using referrer on the incoming request to set frame-ancestors or
X-Frame-Options on the outgoing response, and someone sets
referrer-policy to none in an attempt to do something malicious,
wouldn't the embed attempt safely fail closed?

-Brad



On Wed, Oct 29, 2014 at 9:55 AM, Sean Snider <ssnider@yahoo-inc.com> wrote:
> OK let me put this another way. . .
>
> Why shouldn't every single frame be able to know the origin of who did the
> embedding?
> Seems to me that's reasonable, since we've ALWAYS allowed it in the past. .
> .
>
> Further, if someone did set referrer to none, again the HTML document in
> question has no way to know
> who / or way the embed-er is.. . and if the embed-ee wants to know that, or
> is required to know that. . .
> what are they supposed to do?
>
> Unless an embed-ee can require that knowledge somehow, (which he cannot
> unless we add something else to frame ancestors),
> I really feel like this is game-breaking. . .
>
> It's not to say that I don't believe in being able to protect the referrer,
> it's simply that we shouldn't create a 1-way block
> with absolutely no recourse. . .
>
> Right now the way the spec is setup, even if an embed-ee says to allow
> frame-ancestors of "foo.org", "bar.org", etc,
> but one of those sites set "referrer" to "none", the embed-ee has absolutely
> 0 way to know who did the embedding,
> even though they are trying to establish trust. . .
>
> Sean
>
> ________________________________
> From: Frederik Braun <fbraun@mozilla.com>
> To: public-webappsec@w3.org
> Sent: Monday, October 27, 2014 4:01 AM
> Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for
> Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
>
> On 25.10.2014 02:37, Sean Snider wrote:
>
>
>
>> Anyway. . . In my very humble opinion. . .
>>
>> I really cannot see a "valid" use-case for "none", and I think it
>> potentially breaks things or creates nasty situations..
>
>>
>
> I disagree. There are numerous cases for secrets in the link (aka
> capability URLs) that may want to get a greater deal of leak protection.
>
>
>
>
>