[whatwg] crossorigin property on iframe

Thu Apr 12 13:35:36 PDT 2012

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.

Ojan