- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 5 Dec 2012 01:45:25 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On Mon, Dec 3, 2012 at 9:57 AM, Adam Barth <w3c@adambarth.com> wrote: > 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. I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through <meta> elements as well as, or instead of, using headers. / Jonas
Received on Wednesday, 5 December 2012 09:47:22 UTC