W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

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

From: Sean Snider <ssnider@yahoo-inc.com>
Date: Wed, 29 Oct 2014 16:55:50 +0000 (UTC)
To: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <722515626.141286.1414601750630.JavaMail.yahoo@jws100115.mail.ne1.yahoo.com>
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.




   
Received on Wednesday, 29 October 2014 17:01:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC