Re: [webcomponents] Consider exposing Shadom DOM and Custom Elements only in secure contexts (#449)

Are there any benefits beyond encouraging devs to go secure on their sites?

> this would severely impact the simpler use cases, such as just using a component on an existing site.
Also, local serving for testing is a pain if you have to self-sign certs and install them on other devices.  With minor APIs like `getUserLocation`, graceful degradation on insecure contexts is easy (and there's an actual benefit beyond encouraging devs), but when a large amount of the page could be web components, it's not so easy to sidestep unless you already have a polyfill (which people likely won't have when support is ubiquitous).

FWIW in the [original idea](https://sites.google.com/a/chromium.org/dev/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) for restricting new features to secure contexts, the Chrome Security team referred to "particularly powerful features", defined as:

> things like: features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments, features that provide the origin with control over the UA's trustworthy/native UI, access to sensors on the user's device, or generally any feature that we would provide a user-settable permission or privilege to.

And goes on to say:
> “Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category.

I'd say that web components fit into the latter category and there's no need to limit availability to secure contexts only.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/449#issuecomment-199360775