- 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