[whatwg] crossorigin property on iframe

Fri Apr 13 00:55:50 PDT 2012

Am 12.04.2012 22:35 schrieb Ojan Vafai:
> On Thu, Apr 12, 2012 at 1:32 PM, Adam Barth<w3c at adambarth.com>  wrote:
>
>> On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai<ojan at chromium.org>  wrote:
>>> On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>>>> On 4/12/12 3:49 PM, Adam Barth wrote:
>>>>> The seamless part might be workable, since that leaks information only
>>>>> from the document in question.  It's possible that there's a better
>>>>> mechanism than CORS for a child frame to opt into being seamless with
>>>>> its parent.
>>>>
>>>> Yes, I agree that having a way for a child to opt into being seamless is
>>>> desirable.  That doesn't have the problems direct DOM access does.
>>>
>>> OK, I'm convinced that direct DOM access is a bad idea. seamless was the
>>> use-case I most cared about anyways. In theory, if we use seamless + CORS
>>> for the @src load and any navigations of the frame (including via
>>> Location), then this should be feasible, yes?
>>>
>>> Alternately, 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.
>>
>> The reason we have the crossorigin attribute for<img>  and<script>  is
>> because the request needs to follow the CORS rules, which means we
>> need to know ahead of time how to make the request.  In this case, we
>> don't need to know whether the child wants to opt into cross-origin
>> seamlessness until we get the response.
>>
>> For that reason, something like an attribute on the<html>  element
>> might be a better mechanism than CORS.
>>
>
> Sounds fine to me. allowseamless? embedded-frame-options=allowseamless? The
> latter would give future extensibility if we wanted to ad other embedding
> options.

I assume that one popular use case for seamlessly embedding cross-origin 
frame content is: A service provider allows his/her customers to embed 
the pages provided. In this case, the info needed is a list of domains 
that are allowed to embed the content, rather than an allowseemless 
yes/no flag. As an author, I think a meta element would be handy, 
something like:

<meta name="allow-seemless-embedding"
    content="domain1.com, domain2.co.uk, shop.domain3.net">

I don't know whether the list should rather be space or comma separated. 
Subdomains of the specified domains should inherit the allowance, the 
way that www.domain1.com and test.domain1.com can seamlessly embed the 
page, but not www.domain3.net or even foo.co.uk.