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

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 knowwho / 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 blockwith 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.