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

[Jonas Sicking]

On Mon, Dec 3, 2012 at 9:57 AM, Adam Barth <w3c at adambarth.com> wrote:
> 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]
>>
>> 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