It’s not like you really had much recourse before anyway, if someone sold you a fake ticket or one that’s already been used, are you really going to sue them or the platform? Charge back and hope you get the money back?
not 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
I 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.
Well 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.
DHCP does give you a globally unique IP address when your ISP has allocated a prefix to your router, that's how all the Internet-connected IPv6 devices get their addresses. Where is our misunderstanding?
For many of these systems, I don't control the user's router. I don't know how you imagine I'm supposed to create DNS records for each device when they're assigned some random IP address at some random network I don't control.
Have the device ping a central server and create randomword.centralserver.com, for example. However, if the problem is the DNS record, why has this thread been exclusively about globally routable IP addresses until now?
In https://news.ycombinator.com/item?id=45957048, addisonj suggested that the problem stems from the distinction from "local" and "global", and that with IPv6, you don't need that distinction.
That quite naturally flows into the question: okay, how are these devices supposed to get global IPv6 addresses then?
Yes, with IPv6, there are are enough addresses that you don't need to use NAT. All IPv6 devices that are connected to the internet have global IPv6 addresses. I don't quite understand the question here, it seems to me that we're asking "but how could we possibly do this entirely mundane everyday thing?".
Not all devices connected to the Internet have globally unique IPv6 addresses, SLAAC and often DHCPv6 makes local v6 addresses. Where's the globally unique IPv6 address supposed to be coming from?
So you're talking about being assigned temporary globally unique addresses, if the network the device happens to be on at any given time happens to be set up in a certain way?
I still don't understand how this is supposed to help.
In https://news.ycombinator.com/item?id=45957048, addisonj suggested that the problem stems from the distinction from "local" and "global", and that with IPv6, you don't need that distinction.
This helps because you don't have a NAT distinguishing between "local" and "global", all devices are in the global namespace.
All the comments after that have been about solving an arbitrary and ill-defined problem with goalposts that keep shifting from globally unique addresses to DNS hostnames to permanent addresses.
How does getting a temporary globally unique IPv6 address from DHCPv6 solve any of the issues surrounding how new web technologies aren't available in "insecure contexts"?
I assumed that the suggestion was that you could assign a device a permanent IPv6 address, because I can easily imagine that as a part of a solution to the HTTPS issue. When every device has a permanent IPv6 address, and if every device is reachable through said IPv6 address, you could, in principle, also automate assigning each device a DNS record and set up SSL that way. It would be a pretty terrible solution that's way more complicated than just using a local address over HTTP, but it makes sense.
I have no idea how to even begin translating maybe getting temporary unique addresses through DHCPv6 into a solution to the HTTPS issue.
You can get a static prefix from your ISP. After you get the static prefix, it's up to your local network to make the local parts of the address static. There's no reason why your DHCP server can't give the device a static address, it's not like it's going to run out.
Then again, you don't need a static address to get a TLS certificate. You don't need an address at all! All you need is a domain name.
You'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.
You 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.
Not 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.
I 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.
Actually in Python it can. Since the type hints are accessible at runtime, library authors can for example change which values in kwargs are allowed based on the type of the argument.
So on the language level it doesn’t directly change the behavior, but it is possible to use the types to affect the way code works, which is unintuitive. I think it was a bad decision to allow this, and Python should have opted for a TypeScript style approach.
You can make it change the behaviour at runtime is different than it changes the behaviour at runtime I think?
Lots of very useful tooling such as dataclasses and framework like FastAPI rely on this and you're opinion is that it's a bad thing why?
In typescript the absence of type annotations reflection at runtime make it harder to implement things that people obviously want, example, interop between typescript and zod schemas. Zod resorts instead to have to hook in ts compiler to do these things.
I'm honestly not convinced Typescript is better in that particular area.
What python has opted for is to add first class support for type annotations in the language (which Javascript might end up doing as well, there are proposals for this, but without the metadata at runtime).
Having this metadata at runtime makes it possible to implement things like validation at runtime rather than having to write your types in two systems with or without codegen (if Python would have to resort to codegen to do this, like its necessary in typescript, I would personally find this less pythonic).
I think on the contrary it allows for building intuitive abstractions where typescript makes them harder to build?
If the tone of the article wasn’t so flippant I’d maybe have read all the way through it. I’m not going to read an article that sounds like it’s written by a petulant child.
Unless you're never sexually active (meaning, you eventually do have sex), it's worthwhile getting since there is a risk to yourself if you get infected.
Next time I would recommend to just wait until you’re less emotional and respond then. Your comment now doesn’t really add anything to the conversation, whereas one with a level head might.
Yes, exactly. The article is pretty clear that it’s rejected without prejudice and that a few points need to be ironed out before he gives a preliminary approval. I suspect a lot of folks didn’t read much/any of TFA.
I do wonder if all of the kinks will be smoothed out in time. Not a lawyer too, but the timeline to create the longer list is a bit tight, and generally feels like we could see an actual rejection or at least a stretched out process here that goes on for a few more months at least before approval.
