4 ms·
You should be able to use things like WebTransport locally, localhost is considered a secure context.
by yladiz 11mo ago
You should be able to use things like WebTransport locally, localhost is considered a secure context.
- mort96 11mo ago192.168.0.x is not though
- vscode-rest 11mo agoport fwd through localhost?
- mort96 11mo agoYou're missing the point. The useful thing is to run some service on the LAN, be it a web interface for a NAS, a web interface to control some lighting, a web interface into a media PC to do remote desktop type stuff or control media playback, a debug interface into some embedded product I'm working on, or a whole host of other things. The thing that makes web technologies useful for this is that it Just Works, from any other machine on the LAN (my laptop, my phone, a guest's phone, etc). By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
- jimvdv 11mo agoYou can get a free cert from letsencrypt using their dns challenge. No need to expose to the internet. Add a DNS record that points to the address of your LAN and it’ll make things even easier for your guests.
- mort96 11mo agoNot interested in going through the effort of setting up a DNS record, go through the whole DNS challenge process, and go through a periodic manual renewal process, for every stupid little thing (many even just temporary things which don't even have a static DHCP lease). There's literally no advantage for my use case, except that I'd be allowed by the web standard bodies to use their shiny new toys that they artificially lock away otherwise. For the permanent installation case, it's typically easier to use mDNS domains since they're shorter. 'mediapc.local' is easier for guests to type than 'mediapc.local.mort.coffee' or whatever I'd end up with. What would be a good solution is self-signed certificates, but that too is a non-option until all browser vendors downgrade the warning from a "Someone is trying to hack you!" style scare screen to a more informative "this is a self signed certificate, do you trust it?" style warning screen.
- sroussey 11mo agoSelf signed for 192.x would be one thing, self signed for gmail.com would be another.
- mort96 11mo agoI would be perfectly happy with a solution where browsers show a scare screen for self-signed certificates on the public internet but a benign-looking "Do you want to trust this certificate?" screen for 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 or mDNS .local domains.
- fukka42 11mo ago[dead]
- otabdeveloper4 11mo ago> you VILL spend effort to placate the corporate letencrypt gods with pointless encantations and you VILL like it Gee thanks corporate overlords, whatever would we do without your cloying efforts to provide quote-unquote-"security"?
- addisonj 11mo agonot disagreeing with your point here, or in the follow-ups of the pain of https for "local network" apps... but I really wish that we could get to a place where we could get away from this distinction. Obviously, ipv6 is not that easy or realistic, but that really is, imho, the "right" long term answer. Having gone down the path of being able to just spin up "local" services that get a publicly routable (but most often firewalled off) ipv6 IPs and then good DNS integration is really neat... but still requires lots of technical chops. I wish that weren't the case
- mort96 11mo agoI work with embedded Linux stuff and MCU stuff where we make a significant number of units. Even in an IPv6 world, there's no way each of those would get their own public static IPv6 address with an associated DNS record just for the purpose of being able to spin up a debug web interface. It's explicitly desirable for these devices to not be reachable through the public Internet.
- stavros 11mo agoWell then you set your firewall to default-deny. It doesn't make sense to hobble the internet just because NATs are inadvertently a convenient firewall.