Re: [whatwg] Making cross-origin <iframe seamless=""> (partly) usable

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