Re: [w3ctag/design-reviews] Portals (#331)

Thanks for the feedback.

I've looked through the notes, and would like to address some of the points discussed:

* Why are we proposing this as a new element instead of an attribute on `<iframe>`:
  * Immutability of the frame tree: The web platform contains many assumptions about the immutability of the frame tree, in particular, the fact that a frame's parent never changes. Chrome experimented in the past with [magic iframes](https://bugs.webkit.org/show_bug.cgi?id=32848), which allowed some iframes to be reparented. This has caused [many issues](https://lists.webkit.org/pipermail/webkit-dev/2012-March/020045.html) that have lead to the [removal](https://bugs.webkit.org/show_bug.cgi?id=81590) of the feature.
  * In order to mitigate some of the risks, we are proposing that portals should not have their WindowProxy's exposed to their embedders. In particular, this implies that they would not be part of the same unit of related browsing contexts, and the only means of communication between a portal and its embedder would be via asynchronous APIs (such as postMessage). This also has other advantages, as it would allow implementers to use separate threads/processes for content embedded in a portal, resulting in better performance.
* At least for the initial version of portals, we are planning to have a page embedded in a portal behave more or less like a tab, so any privacy-preserving pre-rendering would have to be guaranteed by the embedding page. That means that things like state or storage would be allowed inside the portal (as its real origin) and our expectation is that the embedder would inspect the content being served (either via a CDN or SXG) in order to guarantee the user's privacy. In the future, we'd like to explore other options, such as restricted storage and network access in order to lower the requirements on the embedder page to guarantee privacy, but it's important to note that the embedder page will always need to cooperate with the portal to some extent in order to achieve privacy preserving pre-rendering.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/331#issuecomment-461866645