Re: Encapsulation and defaulting to open vs closed (was Re: Shadow DOM Encapsulation)

[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