if you have the technical savvy to be using .dev before the Google deployment, you have the technical savvy to install an additional root cert for use with Chrome.
Sorry but this is pure malice by Google. I can invert this argument by saying if you're buying a .dev domain you have the technical savvy to get on an HSTS preload list, except you haven't broken anyone's workflow.
EDIT: And I mean... have you USED openssl's x509 toolchain? That's a few steps up from editing the hostsfile.
Editing the hosts file isn't a solution for internal use in organizations.
If it's just you, editing your hosts file, switch to .local or whatever. There was always a chance when using a "local" domain (which isn't actually some sort of standard) that such a TLD could be created in the future. If it's for an organization, create the root cert, and have that be one of the steps users need to take in order to access the dev site. Or just switch to .local or .test or .whatever.
I've been using .dev as a local test environment for years too, but I'd prefer to have more TLD options available and just switch to .local or .test because I'm not averse to change.
.local is reserved for multicast DNS/zeroconf, by the standard. You literally can’t use it on macos because it will always try to look it up in with mDNS first, and only fall back on /etc/hosts once that fails.
If you use .local for fake DNS for a dev setup, you’ll probably notice lookups are slow; that’s why.
(This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
Maybe you've never been in an environment where having to change internal domains is near impossible.
I work at the intersection of 3 corporations within our group. We provide a sort of "internal Heroku" using Kubernetes for anyone in the group that needs it. We recently ran into the 63 character limit on domain name labels (we have to use a wildcard cert because nothing else is approved by legal). You wouldn't believe the time developers would've had to spend on fixing the domain schema across hundreds of services if we hadn't found a way out of that dilemma. We're talking thousands of internal names, some of them given our to external partners (we use a partially publicly resolvable name, but we could've exposed our DNS as well) and some used in systems long forgotten.
That is such specious logic it’s kind of sickening.
I use TLDs like .dev exactly because it’s convenient. Not because I’m “savvy”, and even if that were true, it doesn’t follow that it would be just as convenient to set up a local CA.
Using `echo ip >/etc/resolver/dev` to have a custom dns server for everything in the .dev domain is trivial. It’s one command. Getting a custom CA for all of that is not.
One man's "convenient" is another man's "savvy." If you've got the technical ability (you are 'savvy') to use this TLD, you've got the technical ability ('savvy') to use your own CA.
And I didn't say it would be convenient. The world doesn't revolve around your convenience. I said you've got the ability to use a CA.
What's sickening is devs pretending their broken workflow is important (or should matter) to anyone else, and then getting fussy when it turns out that no, their non-standardized workflow is, in fact, not a standard.
Using .dev for local development is a bug, not a feature. The only reason it was used is because it wasn't yet a TLD . Not because it had some sort of special status as a "Local TLD".
