Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 1, 2012 at 2:43 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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.

I'm fine with specifying explicitly too.  The case we're trying to
avoid is authors getting (unneeded) privacy by default, just because
they did the easiest thing and didn't think too hard about it.

The analogy with JS is somewhat telling - it's harder and less
convenient to make private (closure) variables in JS. Even when we add
Symbols to the language, it'll still be easier to just use normal
(public) properties.


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

I'm not 100% sure (Dimitri can answer better), but I think it's
because we can do a somewhat more lightweight isolation than what a
full iframe provides.

IIRC, several of our use-cases *really* want all of the instances of a
given component to use the same scripting context, because there's
going to be a lot of them, and they all need the same simple data;
they'd gain no benefit from being fully separate and paying the cost
of a thousand unique scripting contexts.

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

I think that Workers or something very much like them is a productive
direction to look in for the isolated components, actually.

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

I think we'd like that, but haven't thought it through very hard yet.

~TJ

Received on Thursday, 1 November 2012 15:40:14 UTC