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

On Feb 6, 2014, at 3:52 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 
> 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.

So you're telling me it's an attractive nuisance and should not be done at all, and Dmitri is telling me that everything is designed so this possibility is still open and it's planned to be added. Which is it?

> 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.

This is totally solvable by having a trusted way to get the ShadowRoot constructor, e.g. by making the relevant object properties read-only and not configurable. Alternately, you can give the script in components code or in an imported document a separate global object. There are many solutions.

That being said, Type 2 encapsulation is not meant to be a security feature - see below..

> 
> 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.

What you describe is a different feature - Type 4 in my typology. I think it's a valuable feature too. But not every use case requires Type 4. Type 2 is still useful.

> So, to summarize, your Type 2 proposal fails to provide any actual
> security or privacy, only the illusion of such,

It's true that it does not provide security. But it's not meant to! It's meant to provide encapsulation. C++ private data members do not provide any security. But they still provide effective encapsulation.

In these discussions, Google folks have often attempted to conflate strong encapsulation (Type 2) with a broken version of robust security isolation (what I call Type 4). Please re-read my email which explains the difference between these features and why Type 2 is still valuable, and address my actual arguments instead of what you imagine they are.

> while restricting authors' ability to do novel things with shadow DOM that we can't
> current anticipate.

That seems clearly false. If shadow DOM is subject to Type 2 encapsulation by default, the author can always opt out to Type 1. Even if we don't provide a feature for it, component authors can always do something to expose the shadow DOM themselves. However, there is no way to build Type 2 on top of Type 1. That is why I think defaulting to Type 1 and providing only Type 1 is a mistake. We can't have any experiments for whether Type 2 would be sufficiently useful and beneficial because you can't do it.

This actually makes Type 2 the more fundamental primitive! You can't build it on top of Type 1. Am I allowed to cite http://extensiblewebmanifesto.org at this point?

> 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.

Referring to strong encapsulation as "fake privacy" is not a good way of indicating willingness to work with me. I have tried to avoid applying pejorative terminology to other people's design proposals, please try to do the same, or we'll end up having a debate of "fake privacy" vs "pretend encapsulation" and get nowhere.

Regards,
Maciej

Received on Friday, 7 February 2014 00:22:28 UTC