On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. <[email protected]> wrote:
> On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak <[email protected]> wrote: >> On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov <[email protected]> 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
