- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 6 Feb 2014 15:52:15 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: www-style list <www-style@w3.org>
[Why fork the thread immediately?] On Thu, Feb 6, 2014 at 3:06 PM, Maciej Stachowiak <mjs@apple.com> wrote: > On Feb 6, 2014, at 2:10 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> The decision to do the JS side of Shadow DOM this way was made over a >> year ago. Here's the relevant thread for the decision: >> <http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312> >> (it's rather long) and a bug tracking it >> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562>. >> >> Note that there were good arguments made for adopting either a >> private-by-default or private-by-choice model, but we eventually went >> with a public-by-default model instead. > > I think it should be made clear that "we" means the Chrome team and the Shadow DOM spec editors, and not the Web Apps WG as a whole. I don't think we ever actually reached consensus on this, and in particular, Shadow DOM currently does not even offer the option to have stronger encapsulation.[1] > > The ^ and ^^ operators double down on this. They would render a flag to not expose the shadow dom directly toothless, since you could always use querySelector or styling to get at the Shadow DOM internals. > > I understand that Google folks largely agree amongst themselves that they only want "weak" encapsulation - Type 1 in the typology I posted here several years ago: <http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html>. > > I don't think anyone has ever countered my arguments for why Type 2 encapsulation is valuable. Yet years after my feedback, the Web Components family of specs continues to not support it, and to be designed so it's not even possible to support it. > > I think that is a bad design direction. I am ok with there being such a thing as a "public mode" where components get only Type 1 encapsulation. However, I strongly feel that Type 2 should also be offered. I also feel that Type 2 should be the default, because defaulting to open has frequently turned out to be a mistake that has been hard to correct in the Web Platform. Some examples of "open" decisions that are by default problematic: Your "Type 2" is an attractive nuisance, unfortunately, because it *looks* like it offers some protection, when it really doesn't. It is *not* sufficient to explain the security boundaries of current HTML elements that use a shadow DOM. In particular, every solution proposed so far is vulnerable to people just hooking the ShadowRoot constructor and observing creation directly, so they can store the root somewhere without interfering with the normal operation of the function. We believe strongly that we need to enable this kind of higher-security boundary, but doing so is far more difficult than you're making it out to be, and requires coordination across several other features beyond Shadow DOM. To be somewhat clearer: this kind of security is *not* a Shadow DOM feature. It's an orthogonal feature, involving JS and the web's security model. Specifying it is an important task, but it's a *completely separate* task from what we're doing here. When it's done, we'd like to have sugar to allow authors to opt into it for their components as painlessly as possible. So, to summarize, your Type 2 proposal fails to provide any actual security or privacy, only the illusion of such, while restricting authors' ability to do novel things with shadow DOM that we can't current anticipate. To make this clearer, let's take one of your examples of mistaken-openness: allowing webpages to embed cross-domain resources freely. Your Type 2 proposal is akin to adding a method to document that, when called, causes the document to do cross-domain checks for all linked content. If an author can call that method first, it might be useful. But if a hostile cross-domain script can get in ahead of the author's script (via an extension, or an XSS, or just an oversight by the author), it can remove that method, or replace it with a fake that does nothing when called. The correct solution is to express this preference at an early enough level that a hostile script can't jump ahead, which is what CSP does. None of this argument is new, by the way. This entire email is just a restatement of arguments against fake privacy from a year+ ago. We would *love* to work on this topic with you, so we can explain the magic behind <iframe> and <input type=file> and all the rest, but this topic is not the correct place to solve it. ~TJ
Received on Thursday, 6 February 2014 23:53:02 UTC