Re: [Shadow] URL-based shadows?

Yes, loading components via imports today is "use at your own risk" since you pull that content directly into your trust boundary. At least with <script src> the platform takes measures to ensure that the imported content (the code) can't be easily observed if it doesn't choose to be.

It seems clear so far that we all want to enable scenarios for both same-origin and cross-origin components. I think we understand that cross-origin components will need to be more restricted. It also seems like there is agreement to want to align the developer experience for the same-origin and cross-origin models as closely as possible (rather than having two very different models).

I'd like to get a sense for what folks' thoughts are on the current non-URL-based creation model (createShadowRoot)? Are we OK with a non-URL-based creation model (as used today) being fairly different from a URL-based creation model? If so, then we can work on figuring this out later and/or separately from the current approach. If not, and we want to have non-URL and URL-based models behave similarly, then it seems like we are signing up to potentially change the current shadow DOM creation model--a breaking change for existing implementations.

Perhaps there's another approach I haven't considered. My preference is not to start over, but to work within the existing creation model framework with incremental changes, not major re-designs. Adding in an isolated scripting environment for shadow dom (of some form) is a fairly large change in my view.

________________________________________
From: Anne van Kesteren <annevk@annevk.nl>
Sent: Thursday, March 19, 2015 1:24 AM
To: Travis Leithead
Cc: Ryosuke Niwa; Dimitri Glazkov (dglazkov@google.com); WebApps WG; Arron Eicholz
Subject: Re: [Shadow] URL-based shadows?

On Thu, Mar 19, 2015 at 12:08 AM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
> 5. I like this. Though it's really only necessary for the cross-origin use case.

I think it's worth mentioning that the existing setup further
encourages the rather dangerous practice of including and trusting
cross-origin scripts. E.g. if you include an HTML import from
angularjs.org you are effectively surrendering all the user's
localStorage, non-protected cookies, indexed DB, etc. to that origin.
Finding ways to move away from such practices while retaining most of
the functionality has significant value.


--
https://annevankesteren.nl/

Received on Friday, 20 March 2015 21:23:44 UTC