That's not new, LetsEncrypt just didn't solve it. And if you think this is the only single point of failure in the stack, I have news for you.

▲

greyface- 15 hours ago | parent [-]

It's absolutely new. No HTML5 features were restricted to secure origins only pre-LE. Today, many are. Google was able to push these requirements in large part due to Let's Encrypt's success making secure origins ubiquitous.

▲

ekr____ 15 hours ago | parent [-]

The order of events is a bit more complicated than this.

Google initially proposed restricting powerful features to secure origins back in February of 2015 (https://web.archive.org/web/20150125103531/https://www.chrom...) and Mozilla proposed requiring secure origins for all new features in April of 2015 (https://blog.mozilla.org/security/2015/04/30/deprecating-non...). Let's Encrypt issued its first certificate in September of 2015.

This isn't to say that these two things are unrelated: Mozilla obviously knew about Let's Encrypt and we considered it an important complement for this kind of policy, and at least some people at Chrome knew about LE, though I'm not sure how it played into their thinking. However, it's not as simple as "LE happened and then people started pushing for secure origins for new features".

	▲	bruce511 6 hours ago \| parent [-]
		I'd also argue, very necessary. A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc. Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable. Even though all you'd be doing is reading some random blog etc. To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".