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

> > Just for the sake of exposing new major APIs to secure context only to persuade web devs to give up with less secure contexts.
> 
> Thus, I think the point is that this motivation is important enough or not.

Indeed.   I would observe that the restriction of ServiceWorkers to HTTPS, though it was done for more direct security reasons, has been an [effective motivator for migration](https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom).  The same applies here: If this is an important feature for people, all the more reason for it to be restricted.

The "local testing" argument is pretty bogus.  The [Secure Contexts](https://w3c.github.io/webappsec-secure-contexts/) spec has a specific exemption for localhost.  If you use a modern server, you can have [HTTPS for zero cost](https://www.youtube.com/watch?v=nk4EWHvvZtI) in either dollars or time.  And even making your own self-signed setup is [just not that hard](https://devcenter.heroku.com/articles/ssl-certificate-self).

As far as "artificially restricting adoption" -- I realize it's unpleasant to spend effort on stuff and see it not catch fire right away.  But if all we were after was adoption, we could just, say, remove all the sandboxing the web provides and give JS direct machine access.  (It would make a lot of devs happy!)  We need to balance adoption against what's right for the web.

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