[whatwg] Making cross-origin <iframe seamless=""> (partly) usable
w3c at adambarth.com
Mon Dec 3 09:57:02 PST 2012
On Fri, Nov 30, 2012 at 6:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 26 May 2012, Adam Barth wrote:
> CSP doesn't seem to include any features that would let you limit who is
> allowed to iframe you, so I don't think CSP as designed today provides a
> solution for the per-origin part. Could it be extended?
The current plan is for X-Frame-Options to become a CSP directive.
CSP is quite extensible. The only hard restrictions are that new
directives conform to this grammar (yes, error handling for parsing is
directive = *WSP [ directive-name [ WSP directive-value ] ]
directive-name = 1*( ALPHA / DIGIT / "-" )
directive-value = *( WSP / <VCHAR except ";" and ","> )
Philosophically, the current plan is to use CSP for things that might
be called "content restrictions," i.e., for restricting what a
document might otherwise be able to do. As I wrote on the wiki ,
it's not a great match for this use case because here we're loosening
restrictions rather than tightening them. Of course, this philosophy
might evolve over time, so I wouldn't necessarily treat it as a
> This doesn't let you chose on a per-origin basis whether you can be framed
> either (since you don't get an Origin header in the request, and the X-F-O
> header only gives a thumbs-up or thumbs-down in general).
> I'm dubious about extending X-F-O since it lacks a spec and so how exactly
> to change it in a backwards-compatible way is unclear and getting it
> wrong would be very dodgy.
> On Thu, 12 Apr 2012, Ojan Vafai wrote:
>> we could add a special http header and/or meta tag for this, like
>> x-frame-options, but for the child frame to define it's relationship to
>> the parent frame.
> It seems to me like the best solution is to have a new HTTP header, with
> the four following values being allowed:
> Seamless-Options: allow-shrink-wrap
> Seamless-Options: allow-styling
> Seamless-Options: allow-shrink-wrap allow-styling
> Seamless-Options: allow-styling allow-shrink-wrap
> (Split on spaces, ignore unknown tokens.)
Assuming that these are order independent, it's slightly more
idiomatic for HTTP to use , as a delimiter.
> Then for the per-origin control, we would extend CSP to have a flag for
> limiting who is allowed to embed you (subsuming X-Frame-Options, essentially).
That's already planned for CSP (e.g.,
is one current proposal).
> For the case of things that can be embedded by anyone but only seamlessly
> by paying clients, I would recommend putting the origin in the URL, and
> then limiting the embedding to that URL using CSP.
> Is this a viable direction?
Yeah, I can see how you ended up with an HTTP header. I wonder if it
would make sense to align this stylistically with CORS. For example:
Access-Control: allow-shrink-wrap, allow-styling
I guess it depends how costly you think it is to mint new HTTP headers
rather than having fewer, harder working headers.
More information about the whatwg