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

On Fri, Feb 7, 2014 at 1:58 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Feb 7, 2014, at 1:09 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>> On 2/6/14 8:44 PM, Boris Zbarsky wrote:
>>> It's been clear.  I just thought, and still think, that given our past
>>> experience with XBL it's a mistake to scope the problem as you have.
>>
>> I should clarify.  That's my personal viewpoint, not necessarily Mozilla's position.
>>
>> I also think that rescoping the problem to the one I'm particularly interested in, which would be type 4 in Maciej's typology, means not getting anything for a while, because the primitives involved (multiple globals, cross-global security membranes or separate worlds or something else along those lines) are simply not there right now in the platform.  Several browsers have some versions of it, but even those  disagree wildly on how that sort of thing should work.  And I mean the security engineers involved, not just the implementations.
>>
>> So while it would be nice if we all had focused on type 4 encapsulation a few years ago and actually driven through the bits needed for it, I don't think we should be holding up web components for it at this point.  Especially because I'm not sure how much others care about type 4 (e.g. Maciej is not very interested in it).
>
> I am interested in it (or really the combination of 4+5). I just think Type 2 is independently valuable as well, and much less complex.

In discussion with Mozilla, we've come to the exact opposite
conclusion.  We do still think Type 2 is valuable, but it's actually
much more complex.

Type 1 boundary is pretty simple.  On the CSS side it's easy to
define; on the DOM side there are a lot of nooks and crannies you've
got to tease out, but the *answer* to each of them is almost always
immediately obvious - if you're outside the shadow, filter out any
mention of the shadow so it look like the host is an atomic element.

Similarly, a Type 4 boundary is simple - you just prevent *anything*
from seeing *anything* across the boundary.  No need to do auditing or
munging of data that crosses the boundary, because *nothing crosses
the boundary*, except through the postMessage channel.  Again, the
details are a little tricky in some cases, but the answer is obvious
in every case.

Type 2 doesn't benefit from this simplicity.  It's more or less Type 1
in terms of security; attempting to think of it in terms of Type 4
will end in tears.  It's just a Type 1 that hides itself a little bit
more.  You then have to make a decision, at each possible interaction
point, whether it's an interaction that should be hidden/blocked, or
not.  We can't block everything, because that's full-blown Type 4, so
it's a judgement call over exactly where we start and stop blocking
information flow.  This is far from simple, and will require
significantly more work and thought to do.

> I believe a strong security boundary is the right way to do cross-domain hosting, such as social network like buttons, third-party comment systems, hosted video or ads. I also do not speak for Apple but I believe many at Apple agree with me that this would be valuable.
>
> I think Type 2 level protection is sufficient for the non-cross-domain case, and in my opinion better than Type 1 for at least some kinds of projects. It's true that the JS frameworks of today allow lots of cool stuff to be built with even less protection, not even Type 1. But part of the goal for Web Components is to provide stronger encapsulation to make components defined by libraries more robust and reusable.

We definitely agree that being able to seal a component off a little
more and expose a more deliberate API is certainly valuable for some
cases.  However, all cases that would like to use Type 2 are
*possible* to do in Type 1, just with a little bit less certainty (not
much less, remember - Type 2 actually offers *zero* additional
guarantees over Type 1, given a determined author), while a lot of
things that would like to use Type 1 cant' be done in Type 2, at least
in a reasonable way.

This is precisely why we want to start with Type 1, and pursue Type 2
*additionally*, but not blocking the first draft of the spec.  We
won't be reducing the security of *anything*, just making *some*
components slightly easier to penetrate than their authors would like.
 They're still completely penetrable regardless of what we do, short
of Type 4, so this isn't losing anything.

> In addition to favoring Type 2 encapsulation, I am also concerned that shadow DOM doesn't seem to be providing the right building blocks to create a system with Type 4/5 encapsulation, even in combination with as-yet-undefined additional security features. I am skeptical that security isolation can be bolted on to a system that is designed to be completely open.

It's likely that Type 4 encapsulation will end up looking somewhat
different in terms of author-facing API, yes.  Maybe it'll be a
"RenderWorker" or something else of that shape.  Since nobody's spent
the time in the last several years to dive deep into the subject, we
really have no idea.  I think it's quite reasonable to conclude,
though, that the current Shadow DOM work will not *block* any future
work on Type 4 encapsulation (and if you're right that the current
design isn't well-designed for Type 4 anyway, then it definitely won't
interfere), and so it shouldn't be a blocker for shipping Type 1
Shadow DOM either.


So, in conclusion:

Type 1, by itself, is useful.  It offers useful guarantees about
encapsulation that enable authors to compose components safely and
freely, without risk of outside code accidentally messing up the
component's internal code, or vice versa.  Its openness allows a lot
of useful cases, but also exposes component authors to some mild
compat risk when delivering upgrades to their component.  I believe
experience in jQuery modules, which has *even worse* encapsulation
guarantees, shows that this compat risk is fairly minimal in practice.

We agree that Type 2 would be cool.  It requires more work than you
seem to be implying.  Progress on Type 2 should not block us from
shipping Type 1.  Nothing is blocked from being created due to not
having Type 2 security/isolation guarantees, because Type 2 offers
absolutely no additional security/isolation guarantees over Type 1.
The exact same compat risk is there, just somewhat less likely due to
the increased difficulty of fiddling with the internals.

Similarly, Type 4 would be cool.  It definitely requires a lot more
work before we know what it would look like.  Progress on Type 4
should not block us from shipping Type 1.  Some things are block from
being created due to not having Type 4 security/isolation guarantees,
but blocking Type 1 won't make us finish Type 4 any faster.

~TJ

Received on Friday, 7 February 2014 22:33:14 UTC