Re: Cross Origin Web Components: Fixing iframes
On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa wrote: > > On Nov 26, 2013, at 10:15 PM, Dominic Cooney wrote: > > On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote: > >> >> On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: >> >> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: >> >>> Hi, >>> >>> I have been having informal discussions of our earlier proposal for >>> cross-orign use cases and declarative syntax for web components, and I >>> realized there was a lot of confusion about our motivations and decision >>> decisions. So I wanted to explain why/how we came up that proposal in this >>> email. >>> >>> >>> *Problem*: A lot of websites embed SNS widgets, increasing the security >>> surface of embedders. The old version of techcrunch.com, for example, >>> had 5+ social share buttons on each article. If any one of those SNS >>> websites got compromised, then the embedder will also get compromised. >>> >> >> This is a valid problem. Does anyone have related use cases that might be >> in-scope for this discussion? >> >> >> Comment forms (e.g. DISQUS) is another important use case. >> >> *What if we used iframe?* >>> What if we replaced each such instance with an iframe? That would give >>> us a security boundary. >>> >>> On the other hand, using an iframe for each social button is very >>> expensive because each iframe loads a document, creates its own security >>> origin, JS global object, and so forth. Initializing new script context >>> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a >>> page is quite expensive. If we had 10 articles, and each article had 5 >>> social buttons, we'll have 50 iframes, each of which needs to load >>> megabytes of JavaScript. >>> >>> iframe is also heavily restricted in terms of its ability to layout >>> itself. Comment widgets (e.g. DISQUS) for example need to stretch >>> themselves to the height of its content. >>> >>> We also need a better mechanism to pass arguments and communicate with >>> cross-origin frames than postMessage. >>> >>> >>> *What if we made iframe lighter & used seamless iframe?* >>> The cost of iframe could be reduced substantially if we cached and >>> internally shared each page's JavaScript. However, we still have to >>> instantiate its own script context, document, and window objects. >>> >>> We can also use seamless iframe to address the comment widget use case. >>> >>> >>> *What if we let each iframe create multiple "views"?* >>> The problem with using an iframe for a cross-origin widget is that each >>> iframe creates its own document, window, etc… even if there are multiple >>> widgets from the same origin. e.g. if we had a tweet button on 10 >>> different articles, we have to create its own document ,window, etc… for >>> each tweet button. >>> >>> We can reduce this cost if we could share the single frame, and have it >>> render multiple "views". Naturally, each such view will be represented as >>> a separate DOM tree. In this model, a single iframe owns multiple DOM >>> trees, each of which will be displayed at different locations in the host >>> document. Each such a DOM tree is inaccessible from the host document, and >>> the host document is inaccessible from the iframe. >>> >>> This model dramatically reduces the cost of having multiple widgets from >>> the same origin. e.g. if we have 10 instances of widgets from 5 different >>> social networks, then we'll have only 5 iframes (each of which will have 10 >>> "views") as opposed to 50 of them. >>> >>> >>> *What if we provided a declarative syntax to create such a view?* >>> Providing a better API proved to be challenging. We could have let page >>> authors register a custom element for each cross-origin widget but that >>> would mean that page authors have to write a lot of script just to embed >>> some third-party widgets. We need some declarative syntax to let authors >>> wrap an iframe. >>> >>> Furthermore, if we wanted to use the multiple-views-per-iframe, then >>> we'll need a mechanism to declare where each instance of such a view is >>> placed in the host document with arguments/configuration options for each >>> view. >>> >>> A custom element seemed like a natural fit for this task but the >>> prototype/element object cannot be instantiated in the host document since >>> the cross-origin widgets' script can't run in the host document and >>> prototype objects, etc… cannot be shared between the host document and the >>> shared iframes. So we'll need some mechanism for the shared iframe to >>> define custom element names, and have the host document explicitly import >>> them as needed. >>> >>> >>> At this point, the set of features we needed looked very similar to the >>> existing custom element and shadow DOM. Each "view" of the shared iframe >>> was basically a shadow DOM with a security boundary sitting between the >>> host element and the shadow root. The declarative syntax for the "view" >>> was basically a declarative syntax of
Re: Cross Origin Web Components: Fixing iframes
On Nov 26, 2013, at 10:15 PM, Dominic Cooney wrote: > On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote: > > On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: > >> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: >> Hi, >> >> I have been having informal discussions of our earlier proposal for >> cross-orign use cases and declarative syntax for web components, and I >> realized there was a lot of confusion about our motivations and decision >> decisions. So I wanted to explain why/how we came up that proposal in this >> email. >> >> >> Problem: A lot of websites embed SNS widgets, increasing the security >> surface of embedders. The old version of techcrunch.com, for example, had >> 5+ social share buttons on each article. If any one of those SNS websites >> got compromised, then the embedder will also get compromised. >> >> This is a valid problem. Does anyone have related use cases that might be >> in-scope for this discussion? > > Comment forms (e.g. DISQUS) is another important use case. > >> What if we used iframe? >> What if we replaced each such instance with an iframe? That would give us a >> security boundary. >> >> On the other hand, using an iframe for each social button is very expensive >> because each iframe loads a document, creates its own security origin, JS >> global object, and so forth. Initializing new script context (a.k.a. "VM", >> "world", "isolate", etc…) for every single SNS widget on a page is quite >> expensive. If we had 10 articles, and each article had 5 social buttons, >> we'll have 50 iframes, each of which needs to load megabytes of JavaScript. >> >> iframe is also heavily restricted in terms of its ability to layout itself. >> Comment widgets (e.g. DISQUS) for example need to stretch themselves to the >> height of its content. >> >> We also need a better mechanism to pass arguments and communicate with >> cross-origin frames than postMessage. >> >> >> What if we made iframe lighter & used seamless iframe? >> The cost of iframe could be reduced substantially if we cached and >> internally shared each page's JavaScript. However, we still have to >> instantiate its own script context, document, and window objects. >> >> We can also use seamless iframe to address the comment widget use case. >> >> >> What if we let each iframe create multiple "views"? >> The problem with using an iframe for a cross-origin widget is that each >> iframe creates its own document, window, etc… even if there are multiple >> widgets from the same origin. e.g. if we had a tweet button on 10 different >> articles, we have to create its own document ,window, etc… for each tweet >> button. >> >> We can reduce this cost if we could share the single frame, and have it >> render multiple "views". Naturally, each such view will be represented as a >> separate DOM tree. In this model, a single iframe owns multiple DOM trees, >> each of which will be displayed at different locations in the host document. >> Each such a DOM tree is inaccessible from the host document, and the host >> document is inaccessible from the iframe. >> >> This model dramatically reduces the cost of having multiple widgets from the >> same origin. e.g. if we have 10 instances of widgets from 5 different >> social networks, then we'll have only 5 iframes (each of which will have 10 >> "views") as opposed to 50 of them. >> >> >> What if we provided a declarative syntax to create such a view? >> Providing a better API proved to be challenging. We could have let page >> authors register a custom element for each cross-origin widget but that >> would mean that page authors have to write a lot of script just to embed >> some third-party widgets. We need some declarative syntax to let authors >> wrap an iframe. >> >> Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll >> need a mechanism to declare where each instance of such a view is placed in >> the host document with arguments/configuration options for each view. >> >> A custom element seemed like a natural fit for this task but the >> prototype/element object cannot be instantiated in the host document since >> the cross-origin widgets' script can't run in the host document and >> prototype objects, etc… cannot be shared between the host document and the >> shared iframes. So we'll need some mechanism for the shared iframe to >> define custom element names, and have the host document explicitly import >> them as needed. >> >> >> At this point, the set of features we needed looked very similar to the >> existing custom element and shadow DOM. Each "view" of the shared iframe >> was basically a shadow DOM with a security boundary sitting between the host >> element and the shadow root. The declarative syntax for the "view" was >> basically a declarative syntax of a custom element that happens to >> instantiate a shadow DOM with a caveat that the shadow host is inacces
Re: Cross Origin Web Components: Fixing iframes
On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote: > > On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: > > On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: > >> Hi, >> >> I have been having informal discussions of our earlier proposal for >> cross-orign use cases and declarative syntax for web components, and I >> realized there was a lot of confusion about our motivations and decision >> decisions. So I wanted to explain why/how we came up that proposal in this >> email. >> >> >> *Problem*: A lot of websites embed SNS widgets, increasing the security >> surface of embedders. The old version of techcrunch.com, for example, >> had 5+ social share buttons on each article. If any one of those SNS >> websites got compromised, then the embedder will also get compromised. >> > > This is a valid problem. Does anyone have related use cases that might be > in-scope for this discussion? > > > Comment forms (e.g. DISQUS) is another important use case. > > *What if we used iframe?* >> What if we replaced each such instance with an iframe? That would give >> us a security boundary. >> >> On the other hand, using an iframe for each social button is very >> expensive because each iframe loads a document, creates its own security >> origin, JS global object, and so forth. Initializing new script context >> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a >> page is quite expensive. If we had 10 articles, and each article had 5 >> social buttons, we'll have 50 iframes, each of which needs to load >> megabytes of JavaScript. >> >> iframe is also heavily restricted in terms of its ability to layout >> itself. Comment widgets (e.g. DISQUS) for example need to stretch >> themselves to the height of its content. >> >> We also need a better mechanism to pass arguments and communicate with >> cross-origin frames than postMessage. >> >> >> *What if we made iframe lighter & used seamless iframe?* >> The cost of iframe could be reduced substantially if we cached and >> internally shared each page's JavaScript. However, we still have to >> instantiate its own script context, document, and window objects. >> >> We can also use seamless iframe to address the comment widget use case. >> >> >> *What if we let each iframe create multiple "views"?* >> The problem with using an iframe for a cross-origin widget is that each >> iframe creates its own document, window, etc… even if there are multiple >> widgets from the same origin. e.g. if we had a tweet button on 10 >> different articles, we have to create its own document ,window, etc… for >> each tweet button. >> >> We can reduce this cost if we could share the single frame, and have it >> render multiple "views". Naturally, each such view will be represented as >> a separate DOM tree. In this model, a single iframe owns multiple DOM >> trees, each of which will be displayed at different locations in the host >> document. Each such a DOM tree is inaccessible from the host document, and >> the host document is inaccessible from the iframe. >> >> This model dramatically reduces the cost of having multiple widgets from >> the same origin. e.g. if we have 10 instances of widgets from 5 different >> social networks, then we'll have only 5 iframes (each of which will have 10 >> "views") as opposed to 50 of them. >> >> >> *What if we provided a declarative syntax to create such a view?* >> Providing a better API proved to be challenging. We could have let page >> authors register a custom element for each cross-origin widget but that >> would mean that page authors have to write a lot of script just to embed >> some third-party widgets. We need some declarative syntax to let authors >> wrap an iframe. >> >> Furthermore, if we wanted to use the multiple-views-per-iframe, then >> we'll need a mechanism to declare where each instance of such a view is >> placed in the host document with arguments/configuration options for each >> view. >> >> A custom element seemed like a natural fit for this task but the >> prototype/element object cannot be instantiated in the host document since >> the cross-origin widgets' script can't run in the host document and >> prototype objects, etc… cannot be shared between the host document and the >> shared iframes. So we'll need some mechanism for the shared iframe to >> define custom element names, and have the host document explicitly import >> them as needed. >> >> >> At this point, the set of features we needed looked very similar to the >> existing custom element and shadow DOM. Each "view" of the shared iframe >> was basically a shadow DOM with a security boundary sitting between the >> host element and the shadow root. The declarative syntax for the "view" >> was basically a declarative syntax of a custom element that happens to >> instantiate a shadow DOM with a caveat that the shadow host is inaccessible >> form the component, and the shadow DOM is inaccessible from the host >> document. It also seemed nat
Re: Cross Origin Web Components: Fixing iframes
On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: > On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: > Hi, > > I have been having informal discussions of our earlier proposal for > cross-orign use cases and declarative syntax for web components, and I > realized there was a lot of confusion about our motivations and decision > decisions. So I wanted to explain why/how we came up that proposal in this > email. > > > Problem: A lot of websites embed SNS widgets, increasing the security surface > of embedders. The old version of techcrunch.com, for example, had 5+ social > share buttons on each article. If any one of those SNS websites got > compromised, then the embedder will also get compromised. > > This is a valid problem. Does anyone have related use cases that might be > in-scope for this discussion? Comment forms (e.g. DISQUS) is another important use case. > What if we used iframe? > What if we replaced each such instance with an iframe? That would give us a > security boundary. > > On the other hand, using an iframe for each social button is very expensive > because each iframe loads a document, creates its own security origin, JS > global object, and so forth. Initializing new script context (a.k.a. "VM", > "world", "isolate", etc…) for every single SNS widget on a page is quite > expensive. If we had 10 articles, and each article had 5 social buttons, > we'll have 50 iframes, each of which needs to load megabytes of JavaScript. > > iframe is also heavily restricted in terms of its ability to layout itself. > Comment widgets (e.g. DISQUS) for example need to stretch themselves to the > height of its content. > > We also need a better mechanism to pass arguments and communicate with > cross-origin frames than postMessage. > > > What if we made iframe lighter & used seamless iframe? > The cost of iframe could be reduced substantially if we cached and internally > shared each page's JavaScript. However, we still have to instantiate its own > script context, document, and window objects. > > We can also use seamless iframe to address the comment widget use case. > > > What if we let each iframe create multiple "views"? > The problem with using an iframe for a cross-origin widget is that each > iframe creates its own document, window, etc… even if there are multiple > widgets from the same origin. e.g. if we had a tweet button on 10 different > articles, we have to create its own document ,window, etc… for each tweet > button. > > We can reduce this cost if we could share the single frame, and have it > render multiple "views". Naturally, each such view will be represented as a > separate DOM tree. In this model, a single iframe owns multiple DOM trees, > each of which will be displayed at different locations in the host document. > Each such a DOM tree is inaccessible from the host document, and the host > document is inaccessible from the iframe. > > This model dramatically reduces the cost of having multiple widgets from the > same origin. e.g. if we have 10 instances of widgets from 5 different social > networks, then we'll have only 5 iframes (each of which will have 10 "views") > as opposed to 50 of them. > > > What if we provided a declarative syntax to create such a view? > Providing a better API proved to be challenging. We could have let page > authors register a custom element for each cross-origin widget but that would > mean that page authors have to write a lot of script just to embed some > third-party widgets. We need some declarative syntax to let authors wrap an > iframe. > > Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll > need a mechanism to declare where each instance of such a view is placed in > the host document with arguments/configuration options for each view. > > A custom element seemed like a natural fit for this task but the > prototype/element object cannot be instantiated in the host document since > the cross-origin widgets' script can't run in the host document and prototype > objects, etc… cannot be shared between the host document and the shared > iframes. So we'll need some mechanism for the shared iframe to define custom > element names, and have the host document explicitly import them as needed. > > > At this point, the set of features we needed looked very similar to the > existing custom element and shadow DOM. Each "view" of the shared iframe was > basically a shadow DOM with a security boundary sitting between the host > element and the shadow root. The declarative syntax for the "view" was > basically a declarative syntax of a custom element that happens to > instantiate a shadow DOM with a caveat that the shadow host is inaccessible > form the component, and the shadow DOM is inaccessible from the host > document. It also seemed natural for such an "shared iframe" to be loaded > using HTML imports. > > > You can think of our proposal
Re: Cross Origin Web Components: Fixing iframes
On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: > Hi, > > I have been having informal discussions of our earlier proposal for > cross-orign use cases and declarative syntax for web components, and I > realized there was a lot of confusion about our motivations and decision > decisions. So I wanted to explain why/how we came up that proposal in this > email. > > > *Problem*: A lot of websites embed SNS widgets, increasing the security > surface of embedders. The old version of techcrunch.com, for example, > had 5+ social share buttons on each article. If any one of those SNS > websites got compromised, then the embedder will also get compromised. > This is a valid problem. Does anyone have related use cases that might be in-scope for this discussion? > *What if we used iframe?* > What if we replaced each such instance with an iframe? That would give us > a security boundary. > > On the other hand, using an iframe for each social button is very > expensive because each iframe loads a document, creates its own security > origin, JS global object, and so forth. Initializing new script context > (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a > page is quite expensive. If we had 10 articles, and each article had 5 > social buttons, we'll have 50 iframes, each of which needs to load > megabytes of JavaScript. > > iframe is also heavily restricted in terms of its ability to layout > itself. Comment widgets (e.g. DISQUS) for example need to stretch > themselves to the height of its content. > > We also need a better mechanism to pass arguments and communicate with > cross-origin frames than postMessage. > > > *What if we made iframe lighter & used seamless iframe?* > The cost of iframe could be reduced substantially if we cached and > internally shared each page's JavaScript. However, we still have to > instantiate its own script context, document, and window objects. > > We can also use seamless iframe to address the comment widget use case. > > > *What if we let each iframe create multiple "views"?* > The problem with using an iframe for a cross-origin widget is that each > iframe creates its own document, window, etc… even if there are multiple > widgets from the same origin. e.g. if we had a tweet button on 10 > different articles, we have to create its own document ,window, etc… for > each tweet button. > > We can reduce this cost if we could share the single frame, and have it > render multiple "views". Naturally, each such view will be represented as > a separate DOM tree. In this model, a single iframe owns multiple DOM > trees, each of which will be displayed at different locations in the host > document. Each such a DOM tree is inaccessible from the host document, and > the host document is inaccessible from the iframe. > > This model dramatically reduces the cost of having multiple widgets from > the same origin. e.g. if we have 10 instances of widgets from 5 different > social networks, then we'll have only 5 iframes (each of which will have 10 > "views") as opposed to 50 of them. > > > *What if we provided a declarative syntax to create such a view?* > Providing a better API proved to be challenging. We could have let page > authors register a custom element for each cross-origin widget but that > would mean that page authors have to write a lot of script just to embed > some third-party widgets. We need some declarative syntax to let authors > wrap an iframe. > > Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll > need a mechanism to declare where each instance of such a view is placed in > the host document with arguments/configuration options for each view. > > A custom element seemed like a natural fit for this task but the > prototype/element object cannot be instantiated in the host document since > the cross-origin widgets' script can't run in the host document and > prototype objects, etc… cannot be shared between the host document and the > shared iframes. So we'll need some mechanism for the shared iframe to > define custom element names, and have the host document explicitly import > them as needed. > > > At this point, the set of features we needed looked very similar to the > existing custom element and shadow DOM. Each "view" of the shared iframe > was basically a shadow DOM with a security boundary sitting between the > host element and the shadow root. The declarative syntax for the "view" > was basically a declarative syntax of a custom element that happens to > instantiate a shadow DOM with a caveat that the shadow host is inaccessible > form the component, and the shadow DOM is inaccessible from the host > document. It also seemed natural for such an "shared iframe" to be loaded > using HTML imports. > > > You can think of our proposal as breaking iframe down into two pieces: > >1. Creating a new document/window >2. Creating a new view > > I think decomposing the problem this way is a good step. Re
Cross Origin Web Components: Fixing iframes
Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision decisions. So I wanted to explain why/how we came up that proposal in this email. Problem: A lot of websites embed SNS widgets, increasing the security surface of embedders. The old version of techcrunch.com, for example, had 5+ social share buttons on each article. If any one of those SNS websites got compromised, then the embedder will also get compromised. What if we used iframe? What if we replaced each such instance with an iframe? That would give us a security boundary. On the other hand, using an iframe for each social button is very expensive because each iframe loads a document, creates its own security origin, JS global object, and so forth. Initializing new script context (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a page is quite expensive. If we had 10 articles, and each article had 5 social buttons, we'll have 50 iframes, each of which needs to load megabytes of JavaScript. iframe is also heavily restricted in terms of its ability to layout itself. Comment widgets (e.g. DISQUS) for example need to stretch themselves to the height of its content. We also need a better mechanism to pass arguments and communicate with cross-origin frames than postMessage. What if we made iframe lighter & used seamless iframe? The cost of iframe could be reduced substantially if we cached and internally shared each page's JavaScript. However, we still have to instantiate its own script context, document, and window objects. We can also use seamless iframe to address the comment widget use case. What if we let each iframe create multiple "views"? The problem with using an iframe for a cross-origin widget is that each iframe creates its own document, window, etc… even if there are multiple widgets from the same origin. e.g. if we had a tweet button on 10 different articles, we have to create its own document ,window, etc… for each tweet button. We can reduce this cost if we could share the single frame, and have it render multiple "views". Naturally, each such view will be represented as a separate DOM tree. In this model, a single iframe owns multiple DOM trees, each of which will be displayed at different locations in the host document. Each such a DOM tree is inaccessible from the host document, and the host document is inaccessible from the iframe. This model dramatically reduces the cost of having multiple widgets from the same origin. e.g. if we have 10 instances of widgets from 5 different social networks, then we'll have only 5 iframes (each of which will have 10 "views") as opposed to 50 of them. What if we provided a declarative syntax to create such a view? Providing a better API proved to be challenging. We could have let page authors register a custom element for each cross-origin widget but that would mean that page authors have to write a lot of script just to embed some third-party widgets. We need some declarative syntax to let authors wrap an iframe. Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll need a mechanism to declare where each instance of such a view is placed in the host document with arguments/configuration options for each view. A custom element seemed like a natural fit for this task but the prototype/element object cannot be instantiated in the host document since the cross-origin widgets' script can't run in the host document and prototype objects, etc… cannot be shared between the host document and the shared iframes. So we'll need some mechanism for the shared iframe to define custom element names, and have the host document explicitly import them as needed. At this point, the set of features we needed looked very similar to the existing custom element and shadow DOM. Each "view" of the shared iframe was basically a shadow DOM with a security boundary sitting between the host element and the shadow root. The declarative syntax for the "view" was basically a declarative syntax of a custom element that happens to instantiate a shadow DOM with a caveat that the shadow host is inaccessible form the component, and the shadow DOM is inaccessible from the host document. It also seemed natural for such an "shared iframe" to be loaded using HTML imports. You can think of our proposal as breaking iframe down into two pieces: Creating a new document/window Creating a new view and providing a mechanism to do 2 without doing 1 (or that doing 2 multiple times after doing 1 once), and making it usable with a declarative syntax. - R. Niwa
