Re: [webkit-dev] Magic Iframe removal proposed
I'm ok with removing this feature for the reasons you described. I concur with others who think we should update the spec. I am also skeptical of state sharing features that work via newer, less tested API surface instead of latching onto existing features. That seems like a more risky strategy since it may be harder to remove such a feature without compat breakage, and it's not clear how it makes the security problems even easier. As a side note, this probably should have had more discussion time before being actually committed. If a change is worthy of webkit-dev discussion in the first place, then 5 hours between initial webkit-dev post and committing the patch is cutting it a bit short. Especially when it is outside normal working hours in the time zones where most WebKit contributors live. I don't want to harp on this too much, since I don't personally disagree with the change, but if anyone does, then they may feel that they didn't really get a fair chance to comment. Regards, Maciej On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted 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). 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: 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
Yeah, normally I would have waited longer, but the patch fixed a crash in WebKit2 that was making the bots red. There was a discussion in another bug (sorry, don't have the link handy) where folks graciously held off fixing the crash, and I didn't want them to wait any longer than necessary. Adam On Mar 20, 2012 1:31 AM, Maciej Stachowiak m...@apple.com wrote: I'm ok with removing this feature for the reasons you described. I concur with others who think we should update the spec. I am also skeptical of state sharing features that work via newer, less tested API surface instead of latching onto existing features. That seems like a more risky strategy since it may be harder to remove such a feature without compat breakage, and it's not clear how it makes the security problems even easier. As a side note, this probably should have had more discussion time before being actually committed. If a change is worthy of webkit-dev discussion in the first place, then 5 hours between initial webkit-dev post and committing the patch is cutting it a bit short. Especially when it is outside normal working hours in the time zones where most WebKit contributors live. I don't want to harp on this too much, since I don't personally disagree with the change, but if anyone does, then they may feel that they didn't really get a fair chance to comment. Regards, Maciej On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for 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 herehttps://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 spechttp://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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
I actually do know of at least one WebKit-only application under development at Google that may be using this feature (I recently suggested it to them). Oh well. - a On Tue, Mar 20, 2012 at 8:07 AM, Adam Barth aba...@webkit.org wrote: Yeah, normally I would have waited longer, but the patch fixed a crash in WebKit2 that was making the bots red. There was a discussion in another bug (sorry, don't have the link handy) where folks graciously held off fixing the crash, and I didn't want them to wait any longer than necessary. Adam On Mar 20, 2012 1:31 AM, Maciej Stachowiak m...@apple.com wrote: I'm ok with removing this feature for the reasons you described. I concur with others who think we should update the spec. I am also skeptical of state sharing features that work via newer, less tested API surface instead of latching onto existing features. That seems like a more risky strategy since it may be harder to remove such a feature without compat breakage, and it's not clear how it makes the security problems even easier. As a side note, this probably should have had more discussion time before being actually committed. If a change is worthy of webkit-dev discussion in the first place, then 5 hours between initial webkit-dev post and committing the patch is cutting it a bit short. Especially when it is outside normal working hours in the time zones where most WebKit contributors live. I don't want to harp on this too much, since I don't personally disagree with the change, but if anyone does, then they may feel that they didn't really get a fair chance to comment. Regards, Maciej On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted 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). 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: 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Magic Iframe removal proposed
Hi Dmitry. Two thoughts on this: (1) If we remove this feature, are Chromium/GMail developers going to re-request the other shared document features that this feature subsumed? Or are y'all now convinced that shared document is, in general, not a good idea? The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Thanks, Geoff On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted 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). 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: 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
On Mon, Mar 19, 2012 at 6:09 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitry. Two thoughts on this: (1) If we remove this feature, are Chromium/GMail developers going to re-request the other shared document features that this feature subsumed? Or are y'all now convinced that shared document is, in general, not a good idea? On a contrary, 'shared application state' could be a good idea, however this particular way to implement it unfortunately is very difficult to get right. There are no Google applications that use this feature currently, and there is understanding of the costs involved. There is a possibility that some other idea can both address the potential need and be reliably implementable at the same time. Workers, for example, are a good case of limiting the surface that also limits design/maintenance costs. Perhaps something similar can be proposed for shared state. However, there was a discussion in Chromium and it appears that ongoing design and maintenance of magic iframe is not worth the benefit the feature provides for the applications. The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Good suggestion, will do. Just wanted to give WebKit community a heads-up... Thanks, Geoff On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for 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 herehttps://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 spechttp://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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Magic Iframe removal proposed
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 dim...@chromium.org wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for 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 herehttps://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 spechttp://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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
I have no immediate objection to removing the shared iframe feature since, as you say, it's a source of problems, very few apps use it, and no apps require it. It's great that we did this feature through a pre-existing web technology, so we discovered its problems, and can now remove it, without creating a huge API surface area burden along the way. On a contrary, 'shared application state' could be a good idea, however this particular way to implement it unfortunately is very difficult to get right. There are no Google applications that use this feature currently, and there is understanding of the costs involved. There is a possibility that some other idea can both address the potential need and be reliably implementable at the same time. Workers, for example, are a good case of limiting the surface that also limits design/maintenance costs. Perhaps something similar can be proposed for shared state. However, there was a discussion in Chromium and it appears that ongoing design and maintenance of magic iframe is not worth the benefit the feature provides for the applications. This doesn't sound so good to me. The main problem you identified with shared iframes -- the fact that permissions and live objects are typically associated with a single top-level page, and can get confused in the context of sharing between pages -- sounds like a problem with sharing, and not a problem with iframes as the mechanism for sharing. I don't support Sharing is hard and nobody uses it, therefore let's add sharing through workers. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
