crossorigin property on iframe

[Ojan Vafai-2]

We should add a crossorigin property on iframe that causes the request to
use CORS. If it's an allowed cross-domain request, then the page should
have access to the DOM of the frame.

Also, seamless should work (assuming the CORS request succeeded of
course). One tricky thing here is that seamless needs to stop working if
the frame is navigated to a different origin to which it does not have CORS
access.

Ojan

[Adam Barth-5]

Would this be transitive?  Suppose A allows B with CORS and B allows
C.  What happens when C includes a frame to B and B includes a frame
to A?  Can C access A?  Based on your description, it sounds like
"yes", but there's widespread evidence that transitive trust is
problematic.

Adam


On Thu, Apr 12, 2012 at 12:30 PM, Ojan Vafai <ojan@...> wrote:

> We should add a crossorigin property on iframe that causes the request to
> use CORS. If it's an allowed cross-domain request, then the page should
> have access to the DOM of the frame.
>
> Also, seamless should work (assuming the CORS request succeeded of
> course). One tricky thing here is that seamless needs to stop working if
> the frame is navigated to a different origin to which it does not have CORS
> access.
>
> Ojan

[Anne van Kesteren-2]

On Thu, 12 Apr 2012 21:30:00 +0200, Ojan Vafai <ojan@...> wrote:
> We should add a crossorigin property on iframe that causes the request to
> use CORS. If it's an allowed cross-domain request, then the page should
> have access to the DOM of the frame.
>
> Also, seamless should work (assuming the CORS request succeeded of
> course). One tricky thing here is that seamless needs to stop working if
> the frame is navigated to a different origin to which it does not have  
> CORS access.

This cannot work. CORS only works for sharing a single resource. If you  
expose a DOM on a different origin that *entire* origin would be exposed,  
which would be way more than CORS allows for. You'll have to use a  
postMessage()-based workaround I'm afraid.


--
Anne van Kesteren
http://annevankesteren.nl/

[Adam Barth-5]

On Thu, Apr 12, 2012 at 12:46 PM, Anne van Kesteren <annevk@...> wrote:

> On Thu, 12 Apr 2012 21:30:00 +0200, Ojan Vafai <ojan@...> wrote:
>> We should add a crossorigin property on iframe that causes the request to
>> use CORS. If it's an allowed cross-domain request, then the page should
>> have access to the DOM of the frame.
>>
>> Also, seamless should work (assuming the CORS request succeeded of
>> course). One tricky thing here is that seamless needs to stop working if
>> the frame is navigated to a different origin to which it does not have
>> CORS access.
>
> This cannot work. CORS only works for sharing a single resource. If you
> expose a DOM on a different origin that *entire* origin would be exposed,
> which would be way more than CORS allows for. You'll have to use a
> postMessage()-based workaround I'm afraid.

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.

Adam

[Boris Zbarsky]

On 4/12/12 3:30 PM, Ojan Vafai wrote:
> We should add a crossorigin property on iframe that causes the request to
> use CORS.

Which request?  Just the @src load?  Or navigation of the frame via its
Location object too?

> If it's an allowed cross-domain request, then the page should
> have access to the DOM of the frame.

Which page?  Just the page that embedded the frame?  Or any page?  This
should presumably be an asymmetric access check, in that the subframe
should not be able to access the parent frame DOM?

If this is done, it sounds like the code in the parent frame would have
to be _very_ careful to avoid being attacked by the subframe.  We
(Mozilla) have a fair amount of experience in this sort of setup: we
have a parent frame (the browser UI) that can touch cross-origin
subframes (web pages) with asymmetric security checks.  We've discovered
over the years that unless the access is very carefully mediated in
various ways it becomes trivial for the subframe to run script with the
permissions of the embedding frame.

While it's possible, obviously, to spec out the exact mediation needed,
I just want us to realize that this is NOT a small project that will
require a line or two of spec text to get right.

-Boris

[Boris Zbarsky]

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.

-Boris

[Ojan Vafai-2]

On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky <bzbarsky@...> 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.

Ojan

[Adam Barth-5]

On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai <ojan@...> wrote:

> On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky <bzbarsky@...> 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.

Adam

[Ojan Vafai-2]

On Thu, Apr 12, 2012 at 1:32 PM, Adam Barth <w3c@...> wrote:

> On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai <ojan@...> wrote:
> > On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky <bzbarsky@...> 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.

Ojan

[Anne van Kesteren-2]

On Thu, 12 Apr 2012 22:17:50 +0200, Ojan Vafai <ojan@...> wrote:
> 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 problem with CORS might be that if you want to expose content for  
embedding with seamless that depends on credentials, XMLHttpRequest can  
request that information then too. As a developer trying to make seamless  
work cross-origin you might not anticipate that.

On the other hand, the enormous growing number of one-off flags developers  
can attach to resources for various features is starting to get worrisome.


--
Anne van Kesteren
http://annevankesteren.nl/

[Markus Ernst]

Am 12.04.2012 22:35 schrieb Ojan Vafai:

> On Thu, Apr 12, 2012 at 1:32 PM, Adam Barth<w3c@...>  wrote:
>
>> On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai<ojan@...>  wrote:
>>> On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky<bzbarsky@...>  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.