Next steps for local HTTPS

[hybridherbst]

As the explainer mentions, making local https better is out of scope. I’d still like to learn more – is there a proposal somewhere to read and comment on?

In particular, many development tools have to create local HTTPS servers, for example for using WebXR or other APIs that require a secure context. At the moment, this needs self-signed certs which brings up „insecure connection“ scare screens.

[tresf]

At the moment, this needs self-signed certs which brings up „insecure connection“ scare screens.

Tangentially related:

• Provide a mechanism for whitelisting #38

Quoting:

This "use-case" of an app informing the browser is a real stop-gap for non-enterprise user. [...]

[...] I would even argue (and have in other threads) that the very nature of NOT allowing a sane whitelist encourages users to get in the habit of blindly clicking the same option over and over [...]

Also tangentially related, the project did make a promise to "relax" HTTPS connections, quoting #16 (comment):

[...] because sites that need the LNA permission must be HTTPS, but local network requests are often to devices where it is currently difficult to get working HTTPS and if accessed over HTTP they would ordinarily be blocked as mixed content, the LNA permission additionally relaxes the mixed content blocking logic to allow certain local network requests through.

... but these tests are currently failing for Chrome 143; Test results: #16 (comment):

I just tested this on Android (Chrome 143) with WebSocket LNA enabled and I'm failing to find this "relaxation" of content blocking. [...] Note that localhost connections via ws:// succeed, but LAN connections fail.

Although it may be off-topic for this repository, HTTPS connections are often extremely important for apps affected by this new LNA requirement because due to mixed-content restrictions, HTTPS (or WSS) was the only viable way to communicate. There are some projects that do all the heavy-lifting-client-side work as well, such as mkcert because this need is all-too-common however this only addresses same-machine connections (localhost) and there's no sane option for same-network connections (LAN).

Assuming WICG eventually closes this thread as off-topic, I would greatly appreciate a future cross-reference or @mention in wherever future home these discussions are occuring.

[hybridherbst]

did make a promise to "relax" HTTPS connections

My understanding is that this would allow mixed content, yes – but it doesn't help because APIs like WebXR strictly require secure contexts (and will fail in mixed contents). Allowing https > http connections does not really help with that, I believe.

such as mkcert

Yes, we're using self-signed certificates (through vite basicSsl) for this purpose. It allows testing locally running apps with secure context requirements on the LAN (develop on PC, test on phone or Quest), but shows the aforementioned scare screen.

[tresf]

APIs like WebXR strictly require secure contexts (and will fail in mixed contents)

Hmm... sorry for the off-topic rant here, but while we're asking for new features, it could be argued that these HTTPS-only APIs like WebXR are causing self-inflicted wounds. A bit of a rant, but SubtleCrypto should also be allowed from an insecure context as it's useful in insecure contexts too. /rant.

[hubertchao]

As the explainer mentions, making local https better is out of scope. I’d still like to learn more – is there a proposal somewhere to read and comment on?

In particular, many development tools have to create local HTTPS servers, for example for using WebXR or other APIs that require a secure context. At the moment, this needs self-signed certs which brings up „insecure connection“ scare screens.

Making local https better is something that the Chrome team would like to tackle soon, but there's nothing concrete that we can share at the moment.