W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Component Model is not an Isolation Model

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Thu, 10 Mar 2011 13:58:08 -0800
Message-ID: <AANLkTimGQTxG3iJk8PPhA7HQOBjpc6oPqyVAvxEbCEyu@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps <public-webapps@w3.org>, MarkM Miller <erights@google.com>
On Wed, Mar 9, 2011 at 7:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/9/11 7:30 PM, Dimitri Glazkov wrote:
>>>
>>> From the perspective of the component, the isolation is unfairly
>>
>> punishing -- you can't use the outside DOM or even DOM element on
>> which you're hoisted, you can't add methods to it, and you have to
>> always imagine the membrane in order to build a proper mental model of
>> what the heck you're trying to accomplish.
>
> This is sort of a requirement for being able to use components that you
> don't trust to arbitrarily mess with your DOM though, no?

Yes, you're exactly right. Having an isolation boundary is a
requirement for the components that don't trust the document or the
document that doesn't trust the component.

However, many use cases for components simply don't have this
requirement. Most complex apps today build or reuse their own
component frameworks just for the sake of encapsulation
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Custom_Widget_System).
Isolation for them is not a concern, because the components are its
own source. We want to be useful and not in the way for this use case.

For the cases where isolation is necessary, be that mashups or
browser's implementation of HTML elements
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements),
we should provide the capability.

This, in essence, is what triggered realization that components and
isolation are complementary, but different things.

> Also, the component wants to keep the document from poking at its internals
> except via the APIs the component exposes, I would think.
>
>>> From the perspective of the document, the isolation is too fiddly:
>>
>> it's rare that the level of isolation at the _individual_ component
>> level is what's actually necessary.
>
> I'm not sure what the "fiddly" issue is here...  From the perspective of the
> document isolation should mean two things:
>
> 1)  Cross-site components are safe to use.
> 2)  You can't screw up and depend on implementation details of a
>    component, because if you're calling something the component
>    provides then you're using APIs the component explicitly exposed.
>
> Is there something I'm missing?
>
> Or are those things that fall under "modularity" or "encapsulation" in your
> message?  If so, what are you thinking of in terms of "isolation"?

Ah, great question. I've been only recently enlightened by Mark
Miller's Caja crew on this subject, apologies for perhaps crude
explanations.

Isolation is an abstraction that provides a boundary (a membrane from
the Caja world http://en.wikipedia.org/wiki/Object-capability_model)
around untrusted code. The untrusted code could be any chunk of DOM or
Javascript, including the document itself (this case would be a
component defending itself from the untrusted document,
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Parent_trusts_component_but_not_vice_versa).

The Isolation model (whatever it turns out to be), should provide
ability to create this boundary at will, not tied to a component spec
in itself.

Does this make a bit more sense now?

:DG<
Received on Thursday, 10 March 2011 21:58:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT