Source: The horse's mouth. I'm the guy who came up with the idea of launching .dev and .app as HTTPS-only TLDs, and I'm the one who had them added to the HSTS preload list.
It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes.
So yes, we didn't anticipate how many people weren't following the best practices, but that would have been hard to determine prior to doing the thing anyway. There were also lots of people who had the mindset of "We won't change anything until it stops working", so in some sense a lot of it was unavoidable. See e.g.: https://github.com/laravel/valet/issues/204https://github.com/laravel/valet/issues/294https://github.com/laravel/valet/issues/431 (note that Laravel users were responsible for a non-trivial fraction of the total problems experienced, and that we only discovered all this post-HSTS-preloading). The problem was repeatedly pointed out and the maintainers refused to fix it until it actually broke. So, inevitably, it broke, and then they fixed it.
Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google.
I've always hated Google for egoistically claiming this tld, and ICANN for letting them.
It enables zero config local development configuration, whereby at the time it would make your locally running dev server available on .dev
So instead of having to spin up a local server and then visiting say 127.0.0.1:3000,
I could instead just visit myappname.dev and it would show me what would previously show on localhost or it would spin up a server first for that app then show it to me.
They switched to .test in response to google’s change.
Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names.
Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther down the line. That's why you shouldn't use fake domain names. This problem has been known since at least the 90s and is not a good habit to get into. Them now being real makes them actually more useful (and not reliant on potentially unsynced local-only config).
My problem was that it also broke properly configured domains. We have machines in xxx.dev.example.com (for example) that I used to rely on the resolver searching for, so I could just type "xxx.dev" and it would then know to try it with example.com banged onto the end. Then everything in .dev started resolving so my abbreviations started resolving to other hosts.
I mean, I THINK this is "properly configured", but it also isn't a huge deal to avoid. Just was annoying when it started happening. Didn't FEEL like I was misconfigured. :-)
If your machines started exhibiting behavior you didn't expect or intend from a configuration you believe to be proper, then something has gone wrong. It may be the system, it may be the configuration, and it may be your understanding of either. Or any combination.
In this particular case it sounds like your resolver was set up to try an external resolution first and then append an internal domain if the external resolution failed. And as you say, this clearly worked just fine for a long, long time. Then it suddenly started failing one day, for reasons unrelated to anything you changed.
At this point, most people would find it reasonable to blame the external change for breaking their fully functional, correctly working, "properly configured" setup. Some, perhaps contrarian or perhaps more cautious, would note that the "properly configured" approach only worked so long as external systems played ball. I think it might be the case that you were bitten by this assumption that seemed safe at the time, leading to the awkward and uncomfortable conclusion that your systems were indeed misconfigured.
And also, from a larger standpoint, we have a choice of two mutually exclusive options here. It comes down to either (a) freezing the TLD hierarchy in place and never creating any new ones (e.g. not even for a new country, or .mars or whatever), or (b) not retaining indefinite backwards support for multi-label DNS search lists when they happen to collide with new TLDs.
I would argue that, of the two options, option B is the less onerous one, and less restrictive on the future growth of the Internet. It's not that hard to set up some aliases to be able to SSH quickly into the right hosts without having to manually type out longer paths.
I don't think fresh launches, even with bold new parameters, are always considered 'huge changes' in that sense. The fact that it could break local environment's was probably not even documented in those specific environments
There was a time when the creation of a new TLD was unthinkable, so it seemed safe to use a domain syntax internally that was never going to become a public TLD. Then the TLD money grab happened and what was assumed to be safely isolated wilderness was sold out from under everyone.
There never was such a time, and IANA never said "We won't make any more". TLDs have been continually created for at least the past two decades. Look up the history of e.g. .biz, .info, .museum, .aero, .mobi, .cat, .asia, all the various ccTLDs that are created as new countries form (.ss), etc. And none of that is even counting the new gTLD expansion round that kicked off in 2012.
Or I could just dig out my GPG key and sign a message.
So I respect your healthy skepticism, but I promise I'm really me, and not just someone pretending to be me! And I'll also note that, in all my time on HN, I've never once seen someone pretending to be anyone they weren't, at least not on seasoned accounts like mine. You can go back through my 5 years of comments on here, and every time I say I'm a specific person out there in the real world, it's always the same consistent person.
I actually confirmed your GitHub before I made the previous comment. It was just a frivolous reply that I found funny but HN didn't. Tough crowd. But I really, really appreciate your reply, thanks for taking your time to prove your identity. Hopefully I didn't waste too much of your Sunday morning.
My experience here is that humor (especially deadpan) tends to land very poorly on HN, both because people are never contextually expecting it and because they tend to downvote it when they do recognize it, as they dislike perceived low effort comments that they don't feel are meaningfully contributing to the discussion (i.e. adding noise, not signal). HN may as well put "Don't try to be funny" in the FAQ, because it almost never works out.
Mistake made and lesson learnt. After being introduced to the larger internet community via reddit, sometimes you slip up in more serious places like HN.
> If you give me your email I can send you a message from my _lastname_@ work address
Not disputing your account in any way, but please don't propagate the widespread myth that only people who own an email address can send from that email address. If you wanted to use your well-known email address as authentication, you'd need to offer to reply to a mail sent to that address.
You could check whether the email passed SPF, DKIM, and DMARC checks. Google has certainly implemented these for their SMTP servers. If all of the tests pass, you can be pretty certain that the sender is the owner of the address.
This is what I was getting at. It's definitely not possible to fully impersonate an email from an @google.com address. We've got all the security bells and whistles turned on.
Though, admittedly, it would be easier for a layman to verify ability to reply to an email than to verify all those features, so point taken.
Source: The horse's mouth. I'm the guy who came up with the idea of launching .dev and .app as HTTPS-only TLDs, and I'm the one who had them added to the HSTS preload list.