Slashdot Mirror
Chrome To Force Domains Ending With Dev and Foo To HTTPS Via Preloaded HSTS (ttias.be)
Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
All the strive to force users to go https has gone over the top. It's better to be nice about it.
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
Keep the https available for cases where users want to get the extra security. Assuming that users are stupid makes the users stupid.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I use the .local domain on my home network. Those IP addresses are definitely not 127.0.0.1. I have no interest in changing to .localhost and/or setting up certificates for my intranet websites.
that Google has. They already broke the "-ignore-certificate-errors" flag which was driven by their hate. I often have to change my clock for testing, and Google made the decision that I should not be allowed to use the web. We use Let's Encrypt certs that area also pretty hatefully limited to 90 days so they waste so much of our time having to maintain them, so you can't move your clock that far forward or backward before Google decides you shouldn't be able to work.
But it's a real pain for anything that you ship with a web interface, and expect to work unmodified for a long period of time.
Sure, that's a niche use-case, I get that, but not everything that's accessed by a web browser is something easily updated, and why should it be? If I build some device that's intended to be put on my local network, and give it a web interface, - like, say, a home router - will I be required to implement HTTPS on the device, and have it ship with a cert? A cert that expires after a relatively short period of time?
I happen to have an old computer lying around the house, and it can't run anything more modern than Chrome from about eight years ago. This browser is able to access anything on the web, other than newer HTTPS sites, because it doesn't understand their certificate. By building these mechanisms of trust, and then constantly changing them (for instance, change from Common Name to Subject Alternate Name - and whatever it is that old Chrome hates about modern certs), we are locking ourselves out of notions of backwards compatibility, and increasing the rate at which we have to throw away our devices, because we can't afford to release OS updates for old hardware, and can't afford to release browser updates for old OSs.
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
I think you missed a key point - Google bought the .dev TLD and their intended usage is only their own projects. So what they're doing here is asserting that all their dev domains will be encrypted.
The issue here is iCANN shouldn't have been dumb enough to grant a TLD that has been widely used internally, but unfortunately they have a financial incentive to hawk as many TLDs as possible.