- From: Ojan Vafai <ojan@chromium.org>
- Date: Thu, 12 Apr 2012 13:35:36 -0700
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
Received on Thursday, 12 April 2012 13:35:36 UTC