I'm not shocked. ASN blocking is well-known among people who I can easily called experts (veterans which can set up a reasonable-ish firewall from base principles) and ASN control is exposed in major cloud firewalls, but younger people (except those who were trained with deep networking skills) don't really understand ASNs for some reason.
Some notes that I have noticed. First, why does it seem that the V8 date parser is heavily inspired by the Windows date parser (https://devblogs.microsoft.com/oldnewthing/20200304-00/?p=10...)? EDIT: Apparently not, "new Date('Savvyday 29 Oatmeal 94')" is invalid both in Firefox and Chrome.
Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):
Question 14:
new Date("12.1")
> "12.1" is interpreted as the date December 1st, and as before for dates with no year the default is 2001 because of course.
Firefox returns an Invalid Date object instead.
Question 16:
new Date("12.-1")
> The dash here is ignored, so this is interpreted the same as "12.1".
Again, Firefox returns an Invalid Date object instead.
Question 19:
new Date("maybe 1")
> "may" in "maybe" is parsed as the month May! And for some reason this expression cares about your local timezone, which happens to be BST for me right now.
Seems a broken record, but this is still an Invalid Date for Firefox.
Question 20:
new Date("fourth of may 2010")
> "fourth of" is ignored, this is just parsing "may 2010" and again local timezone is important.
Ibid in Firefox.
Question 21:
new Date("May 4 UTC")
> UTC is correctly parsed as a timezone.
No, Firefox is still not accepting this one.
Question 22:
new Date("May 4 UTC+1")
> You can add modifiers to timezones and it works as you would expect.
Neither this one.
Question 23:
new Date("May 4 UTC+1:59")
> It also supports minutes!
Firefox: Not really.
Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!
It's probably improved the past 8 years or so, but I remember Safari was particularly bad for bugs around DST and just dates in general back then, even when using valid input.
We ended up with a bunch of Safari specific workarounds that weren't necessary on Chrome (it was mostly a webview use case so Safari and Chrome were the two we cared about at the time)
Yeah, as I understand it this isn’t backed by any spec. I decided to go with Node’s (v8’s) implementation for the quiz. Fun to see how much divergence there is!
The TLS verifier workaround that you've constructed is reasonably sound (based on how TLS validation works in browsers), but the boring answer to workaround certificate problems is to do what Firefox actually does: skip AIA and only rely on known intermediates. You can import Mozilla's intermediate list as roots (https://wiki.mozilla.org/CA/Intermediate_Certificates, requires additional processing to convert to usable certs) to emulate this.
Haha, so this rabbit hole keeps getting somehow even worse. I do not envy anyone attempting to implement browser-compatible TLS with actual security in mind.
Pre-Starlink, no, not really. Some discount due to the bulk payment, yes, but the bandwidth is simply not there to allow for such discounts, especially in high-demand areas like Africa and the Pacific where satellites have a double-duty to serve land-based customers.
> With a limit of 10 million different serial numbers, I wonder how China does it.
The author has issued a correction, it's 100 million numbers per service indicator. But even then, it's probably not enough.
The boring answer is that your shipping options are either get untracked postal service (which the S10 standard does not apply) or use a private courier (which also does not use the S10 standard).
If you insist, you got two options for UPU-based postal tracking: normal e-commerce parcel aka H-codes, practically 2,300,000,000 trackable packages per year [1]. EMS is the other route, and there are another 2,300,000,000 trackable packages per year [2]. However, in my experience tracked postal delivery is only used in certain countries where it is more advantageous than private delivery (like until very recently in the US, for complicated reasons [3]), while other destinations has a more-than-willing private delivery partner (that is not the Big Three [4]) or even set up the delivery systems themselves.
1: 23 service indicators: HA-HW, HX-HZ are reserved for multilateral/bilateral use only
2: another 23 service indicators: EA-EW, EX-EZ are reserved for multilateral/bilateral use only
> ATC is a safety-critical function that has what amounts to a 100% uptime requirement. Whatever system they're running currently either works or has known flaws that they know how to work around, and air traffic controllers have been trained on these systems for more than a generation now.
The problem is that Eurocontrol (for example) has modernized their systems without much fuss, and UK NATS even has remote tower ATC now (https://www.youtube.com/video/Ii_Gz1WbBGA). It seems that FAA is stuck in the past, not just using old systems because it's reliable.
> Upgrading merely for the sake of being up to date would have been foolish no matter how much funding Congress would have given them.
I would agree if the system is still fit and proper, but even in 2005 the ATC systems in the US is not really fit and proper that there has been multiple plans to rehaul the system. It is really miraculous that the only system failure happened in 2023 (NOTAM offline), but that's due to tireless dedication that's certainly burning unneded manpower.
Unlike in Europe where civil servants have the sway to just do it, it seems that the US is an expert in political bickering on things that aren't really political.
My understanding is that remote tower ATC is something that had to happen at that airport due to geographic constraints rather than some kind of next step for ATC in general. Given a choice between being able to physically look out the window and not, from what I understand being able to see out is always preferable.
The rest I don't know enough to comment on, so I'll assume you're correct.
> How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)?
I think that, franky, even without DoH, that ship has sailed. WhatsApp and Telegram (to name a few) is known to embed IP addresses into their applications. It is silly to assume that not standardizing DoH will not result in the same situation, and I imagine there are custom DNS bootstraping happening, for good or evil.
Frankly, the article is doing a lot of disservice (and should be removed in HN because of its grossly outdated information). As josephcsible pointed out, there are many, many options for DoH.
> A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS.
You forgot the "let's intercept in a public place (e.g. public Wi-Fi hotspots)" one where blocking port 853 is super trivial while blocking port 443... is impossible. Sure, Google DNS will be blocked easily but there a lot of DoH providers!
There's a ton of minor ones, it's easy to spin up your own, and the hope is that eventually, with ECH, it won't be possible to block them without blocking basically the entire Internet like North Korea does.
Malicious DNS in terms of returning bad results is generally irrelevant because if you can't trust the network then returning the wrong IP address and routing the right IP address to the wrong server are the same. Also, you're using HTTPS/TLS/SSH/etc. on the actual connection anyway, right?
So the point of this is to prevent Comcast from seeing your DNS queries. And then it works fine to trust the network to say "no, really, use this one and not the default DoH one" as long as that setting is one that Comcast would get in trouble for misusing. Notice that they don't return bad results for use-application-dns.net as it is.
At that point you might as well use DoH. But you're also reasoning axiomatically about something we have a lot of documentary evidence for: the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
What benefit is the additional complexity and overhead of HTTP buying you there?
> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.
When the DNS operator is your ISP, letting them block encrypted DNS is bad.
So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.
I don't think we need any way to distinguish these situations any more than we needed to preserve the non-ephemeral key exchanges in the jump from TLS 1.2 to TLS 1.3, which were opposed for the same reason. You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring. The 2025 TCP/IP protocol stack should not be going out of its way to give network operators more visibility into what applications are doing.
> You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring.
This would be a great argument if it was actually feasible, but then you have Chromecasts hard-coding Google's DoH servers to prevent ad blocking etc., and devices doing automatic firmware updates to change things like that after you've already bought them.
Pass the law that says the customer has to be given root and the ability to install custom firmware on any device they buy before saying that is reasonable.
You're not going to get either of those things. The market has converged on DoH and applications will continue to run it, and you're not going to get a law giving you root on all the devices that go on your network. If you're concerned about Chromecast's DNS, don't hook up a Chromecast. I don't, and I'm doing fine.
Saying "the market" when you're mainly just talking about Firefox and Chrome implies that it couldn't be changed just by convincing a small set of specific people.
And we'll yet see about that law. Right to repair is pretty popular.
