[webkit-dev] "Magic Iframe" removal proposed

[Ryosuke Niwa]

I support the removal.  I've seen quite a few security bugs caused by this
feature.

Please make sure the spec changes as Geoff pointed out.

- Ryosuke

On Mon, Mar 19, 2012 at 5:51 PM, Dmitry Titov <dimich at chromium.org> wrote:

> Hi,
>
> There is a patch posted <https://bugs.webkit.org/show_bug.cgi?id=81590>for removal of the 'magic iframe' feature. This is the ability to move
> 'live' iframe from one page to another w/o unloading it.
> If you have interest or ideas about this feature, please reply.
>
> HISTORY
> This feature was added 2 years ago (bug here<https://bugs.webkit.org/show_bug.cgi?id=32848>).
> It was intended as a shared app context for complex apps that span several
> pages. In case when random set of pages is closed, the surviving iframe
> could be passed between remaining pages and serve as 'app state'.
> This behavior is somewhat described in HTML5 spec<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>:
> "Removing an iframe from a Document does not cause its browsing context to
> be discarded. Indeed, an iframe's browsing context can survive its original
> parent Document if its iframe is moved to another Document."
> All non-WebKit browsers don't have this and always unload the iframe when
> it is disconnected form the document.
>
> PROBLEMS
> We did have quite a few issues with this mechanism. The root of the
> problem seems to be that traditionally, multiple 'permissions' and 'live
> objects' are associated with a top-level page, or a top frame of some kind,
> instead of being associated with each Frame. Even HTML specifications often
> formulate the scope of things like permissions in terms of a page - for
> example, geo permissions are computed based on the origin of the page. When
> an iframe is transferred from one page to another, it may enter a different
> set of permissions while already performing operations authorized
> before. Association with the top-level page is also used to determine which
> one should show modal UI for HTTP Auth, per-origin permissions, or
> certificate issues for example.
> As a result, we had quite a few bugs popping up (and fixed).
>
> WHY REMOVE
> This is somewhat obscure feature of the platform. Only a few apps that we
> knew used the feature. Most developers, both app and webkit kind, don't
> even know about it. When new mechanisms/APIs are implemented, a lot of
> objects get associated with Page (WebView) level and they are almost
> 'automatically' broken in case of live iframe transfer because once old
> page closes, it destroys the objects with lifetimes scoped by it. This
> makes it somewhat dangerous and difficult to support. The benefits that it
> gives to the big multi-page applications do not seem to warrant the actual
> complexity of maintaining this feature.
> Other browsers never implemented the feature, siting difficult design due
> to various thorny security issues as well.
>
> This is potentially a compatibility issue for sites that use
> document.adoptNode(iframe) to ensure live transfer of an iframe from one
> page to another.
> In the future, if there will be sufficient need, it is possible to design
> a 'shared module' feature that would explicitly deal with various
> security/lifetime boundaries.
>
> Please let us know what you think.
>
> Thanks,
> Dmitry
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120319/811a0c6c/attachment.html>