17

Goal: an encapculated widget

Suppose I'm the developer of a widget showing a list of friends, such as:

Your friends Michael, Anna and Shirley love this webpage!

First approach: script that creates span

Naively, I create a script which places this information in a span on the website. However, the owners of ExampleSite can now access the names of your friends by simple DOM operations!
That's a big privacy / security issue.

Second approach: an iframe

I don't want ExampleSite to have access to their friends' names. So instead, I let website owners add the widget with an iframe:

<iframe src="http://fakebook.com/friends?page=http%3A%2F%2Fexample.org%2F"></iframe>

This works, because the owners of ExampleSite cannot scrape the contents of the iframe. However, this whole iframe thing is rather ugly, because it does not integrate into the styling of the website, while a span does.

Desired approach: Shadow DOM

When reading about Shadow Dom yesterday, I wondered whether that could be a solution to both issues. It would allow me to have a script that creates a span the original website cannot access:

var host = document.querySelector('#friends');
var root = host.webkitCreateShadowRoot();
root.textContent = 'Your friends Michael, Anna and Shirley love this webpage!';

However, **does a Shadow DOM hide its contents from the surrounding page?**
The assumption here is that nobody except my script can access `root`, but is that correct?

The Shadow DOM spec after all says that it offers functional encapsulation, but I actually want trust encapsulation. And while the Component Model Use Cases actually list this use case, I'm not sure whether Shadow DOM realizes the necessary confinement property.

Ruben Verborgh
  • 3,545
  • 2
  • 31
  • 43
  • 4
    “However, this whole `iframe` thing is rather ugly, because it does not integrate into the styling of the website, while a `span` does.” [` – Mathias Bynens Jan 15 '13 at 13:31
  • You shouldn't rely on an API "that [is] not yet fully standardized and still in flux". I would just use a frame that lets them pass in some basic styles (background-color, color, etc.) – Waleed Khan Jan 15 '13 at 13:31
  • @MathiasBynens `seamless` seems interesting. What's browser support? – Ruben Verborgh Jan 15 '13 at 14:33
  • 3
    @WaleedKhan I didn't say it's something I need implemented tomorrow. I just wonder whether Shadow DOM offers this kind of security. – Ruben Verborgh Jan 15 '13 at 14:33
  • @RubenVerborgh [WebKit has (at least some level of) `seamless` support](http://peter.sh/2013/01/animatable-pseudo-elements-seamless-iframe-fixes-and-happy-2013/). As far as I know no other browser engines do, but then again I haven’t tested this. – Mathias Bynens Jan 15 '13 at 20:32
  • @MathiasBynens Will the `seamless` attribute have an effect if the iframe's content is from another domain?! – Hrant Khachatrian Jan 15 '13 at 20:53
  • Unfortunately, the seamless attribute support is [non-existent](http://caniuse.com/#feat=iframe-seamless) after Chrome [dropped it](https://code.google.com/p/chromium/issues/detail?id=229421). – Xan Jan 16 '15 at 11:23

1 Answers1

8

It does not, but it's in the works: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144

The encapsulation of trust will involve creating a new scripting context for each shadow tree, which is overkill for most scenarios. However, as the bug says, we'll add a flag (details TBD) that would allow this.

Jeremy
  • 1
  • 85
  • 340
  • 366
dglazkov
  • 96
  • 1
  • 1
    Thank you for your answer. There's no information on the net that explicitly points to that fact, that this feature is planned. For other readers: I've found a discussion about the isolation types on the public webapps mailing list http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg217 – Patrick Hillert Oct 22 '14 at 12:42
  • This answer by a WebKit contributor may be of interest: https://github.com/w3c/webcomponents/issues/100#issuecomment-161867941 – Thomas Jensen Feb 12 '19 at 20:55