I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name.

I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security.

I wish there was a way to opt into a "TOFU" https mode for these use cases (which is how browser dealt with invalid HTTPS certificates for a long time), although I realize that doing that without compromising the security of the internet at large might be tricky.

If somebody has a solution, I'm all ears. As far as I can tell the "solution" employed by many IoT vendors is simply to mandate an internet connection and have you access your own LAN devices through the cloud, which is obviously a privacy nightmare. But it's HTTPS so your browser will display a very reassuring padlock telling you all is fine!

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more.

What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices)

What about offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all!

It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow.

EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host.

[0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

> without recourse

Doesn't the post say they'll fall back to http if the https attempt fails?

> For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails.

The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).

I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck.

WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one.

The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.

Self-signed certificates seem reasonable in this context - unless I’m missing something.

They might to you, but the browser doesn't agree. It will scream with all its force to all your users that this accessing that product is a really really dangerous idea.

You can set up the users' machines so that they trust your certificate.

I have tried to do just that but ran into all kinds of difficulties:

1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine.

2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it.

3. How do I even install certs on an iPhone?

4. Firefox uses it's own Certificate Database -- for each profile. So I'll have to install certs on the system AND on the host (for e.g. Chrome to find it).

5. All these steps need to be repeated every year (90 days?!) depending on the cert expiration period.

Eventually I just gave up on this. It's not practical. There needs to be a better solution.

I found the steps described in https://github.com/FiloSottile/mkcert reasonable to follow. It describes an iOS workflow too.