- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 3 Dec 2012 09:57:02 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Fri, Nov 30, 2012 at 6:57 PM, Ian Hickson <ian@hixie.ch> wrote: > On Sat, 26 May 2012, Adam Barth wrote: >> >> [CSP] > > 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 also defined): 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 [1], 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 hard-and-fast rule. >> [X-Frame-Options] > > 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. > > Yeah. > > 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., http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html#frame-options 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. Adam [1] http://wiki.whatwg.org/wiki/AllowSeamless
Received on Monday, 3 December 2012 18:04:36 UTC