> and iirc, permit cross-origin resource access

Firefox does not do that.

Safari has some behaviors along those lines last I checked.

I can't recall for Chrome whether it does or not.

I fundamentally agree, but I think the solution is to continue making HTTPS easier to use rather than giving up on security.

For anything on the public Internet, things are already incredibly better than they used to be: HTTPS is free, and there's a wide range of easy ways to set it up on your site, ranging from Caddy (a webserver with built-in Let's Encrypt support) to CloudFlare (who will proxy your site for free including SSL termination). There are still problems – e.g. for all that certbot (official Let's Encrypt client) tries to be easy to use, it's more fiddly than ideal. But the goal of "HTTPS just works" seems clearly within reach, and things can only continue to improve from here.

On the other hand, the situation with local network servers is a complete mess. This includes not just development environments, where "just don't bother with security" is a viable option, but also things like home routers and IoT devices which do want to be secure. Currently, routers tend to just use HTTP, which is insecure if you have anyone untrusted on your Wi-Fi network. IoT devices, of course, tend to route everything through centralized cloud services; there are a lot of reasons for that, and it's easy to blame invidious motives, but I suspect a significant part of the reason is just that it's really hard to make an easy-to-use-device without a centralized service. At a bare minimum, you need to be able to:

1. Securely pair with the device;

2. Connect the device to the network; and

3. Access the device's services over the network, using the existing pairing record to establish identity and prevent a MitM.

(Ideally you would also be able to expose the device's services to the wider Internet, but that's another story.)

You can do this already with a custom protocol, but not with a browser. The closest browsers have to a "pairing record" is asking you to trust a self-signed cert for some random domain, but that's nowhere near the semantics you actually want. After all, it doesn't really matter whether the device controls such-and-such domain; what matters is whether it's the same device you paired with. Meanwhile, trusting random self-signed certs is fundamentally insecure, and (intentionally) difficult to do.

What we need IMO is an entirely new protocol to address this use case, and I think such a protocol might also work for local dev servers.

In the meantime... well, there are always plenty of workarounds.

This feels pessimistic to me: most people didn’t learn the web that way, instead using shared servers — and there were plenty of similar complaints that it was too hard to learn Unix/Windows admin stuff, too. Today, you can use glitch, github pages, jsbin & a million friends, zeit, etc. or the same cheap Dreamhost account people used $20 years ago and start practicing with HTTPS and many other amenities at minimal cost. JavaScript CDNs make it pretty easy to use a ton of stuff without even needing to learn how to install it, too, and increasingly you can do that as native modules.

I’d worry a lot more about how many people are being told they need a J2EE-scale tool chain to run hello world even though the native environment has never been richer.

> Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev;

Then... you can do it on localhost. I can't really image the new web dev that is using separate computer on their local network as a dev server but can't figure out how to get a Let's Encrypt cert to use.

The burden is a little higher but not insurmountable and it obligates new folks into things they need to know. I think it's an acceptable forcing function. Especially given the security concerns.