Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>>> Hi folks!
>>> 
>>> While you are all having good TPAC fun, I thought I would bring this
>>> bug to your attention:
>>> 
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562
>>> 
>>> There's been several comments from developers about the fact that
>>> Shadow DOM encapsulation is _too_ well-sealed for various long tail,
>>> but important use cases
>> 
>> What are these use cases? I did not seem them in the bug.
>> 
>> <http://w3cmemes.tumblr.com/post/34633601085/grumpy-old-maciej-has-a-question-about-your-spec>
> 
> For example, being able to re-render the page manually via DOM
> inspection and custom <canvas> painting code.  Google Feedback does
> this, for example.  If shadows are only exposed when the component
> author thinks about it, and then only by convention, this means that
> most components will be un-renderable by tools like this.

As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into <canvas> without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things?

> For the public/private part at least, this is just a switching of the
> defaults.  There was no good *reason* to be private by default, we
> just took the shortest path to *allowing* privacy and the default fell
> out of that.  As a general rule, we should favor being public over
> being private unless there's a good privacy or security reason to be
> private.  So, I don't think we need strong use-cases here, since we're
> not having to make a compat argument, and the new model adds minimal
> complexity.

I don't enough of the context to follow this. Right now there's no good general mechanism for a component exposing its guts, other than by convention, right? It seems like adding a general mechanism to do so is a good idea, but it could work with either default or with no default at all and requiring authors to specify explicitly. I think specifying either way explicitly would be best. JS lets you have public properties in an object, or private properties (effectively) in a closure, so both options are available and neither is default. It's your choice whether to use encapsulation. I am not sure we need to specifically nudge web developers away from encapsulation.

> 
>>> 1) There's a 3-position switch on each shadow DOM subtree: public,
>>> private, isolated.
>> 
>> Is there any special behavior associated with these three settings besides what is in the other numbered points?
> 
> I don't think so, no.  Public/private is just a matter of exposing or
> nulling some references.  "Isolated" is obviously not well-defined in
> this email, but the implications are relatively straightforward - it's
> like a cross-domain iframe.  (Which is, in fact, exactly how existing
> "components" hack in some isolation/security.)
> 
> 
>>> 2) There's a mechanism in place to flip this switch (specifics TBD)
>> 
>> Who gets to flip the switch? Can a "private" subtree still be accessed via the element it is attached to by simply marking it "public"? That would make "private" useless if so. It seems like whoever creates the shadow DOM should be able to make it "private" in an irreversible way. Without knowing the mechanism it's hard to judge if that is the case.
>> 
>> In cases where a browser implementation provides a built-in shadow DOM, it seems particularly necessary to make it irreversibly private.
> 
> The idea so far is that the switch is just set at shadow creation
> time, and can't be changed.

That seems workable.

> 
> 
>>> 6) The "isolated" setting essentially means that there's a new
>>> document and scripting context for this shadow subtree (specifics
>>> TBD). Watch https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509 for progress.
>> 
>> That seems like a whole separate feature - perhaps we should figure out "private" vs "public" first. It would be good to know the use cases for this feature over using "private" or something like seamless iframes.
> 
> Yeah, sure.  It's useful to bring up at the same time, though, because
> there are some decent use-cases that sound at first blush like they
> should be "private", but really want even stronger security/isolation
> constraints.
> 
> An existing example, iirc, is the Google +1 button widget.  Every
> single +1 includes an <iframe> so it can do some secure scripting
> without the page being able to reach in and fiddle with things.

What are the advantages to using an isolated component for the +1 button instead if an iframe, or a private component containing an iframe?

One thing that makes me nervous about the"isolated" idea, is thata scripting context is normally bound one-to-one to either a browsing context or a worker; and having multiple scripting contexts per browsing context seems like it could be tricky to implement and may have security risks. But I don't have any more concrete objection at this time.

> 
> Flipping it around, isolation also serves as a great way for the
> *page* to protect itself from the *component*.  There are tons of
> components that have absolutely no need to interact with the outside
> page, so sealing them off loses you nothing and gains you peace of
> mind when worrying about whether you should include some random
> plugins you found on your favorite component library site.

Would the page be able to choose to make a component isolated without the cooperation of the component? Or alternately load components in such a way that only isolated ones would succeed?

Regards,
Maciej

Received on Thursday, 1 November 2012 13:44:48 UTC