Chrome & Firefox now force .dev domains to HTTPS via preloaded HSTS

Mattias Geniar, Sunday, September 17, 2017 - last modified: Wednesday, February 7, 2018

tl;dr: Chrome 63 (out since December 2017), will force all domains ending on .dev (and .foo) to be redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.

Update 07/02/2018: Firefox now also forces .DEV domains to HTTPS.


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.

Wait, there's a legit .dev gTLD?

Yes, unfortunately.

It's been bought by Google as one of their 100+ new gTLDs. What do they use it for? No clue. But it's going to cause a fair bit of confusion and pain to webdevelopers.

The .dev gTLD has nameservers and is basically like any other TLD out there, we as developers just happen to have chosen that name as a good placeholder for local development, too, overwriting the public DNS.

$ dig +trace dev. NS
dev.			172800	IN	NS	ns-tld4.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld5.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld3.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld2.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld1.charlestonroadregistry.com.

Google publishes some of their domains on there, too;

$ dig +trace google.dev A
google.dev.		3600	IN	A	127.0.53.53

So yes, it's a legit TLD.

Consequences of redirecting .dev to HTTPS

A lot of (web) developers use a local .dev TLD for their own development. Either by adding records to their /etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to 127.0.0.1.

In those cases, if you browse to http://site.dev, you'll be redirect to https://site.dev, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)

Such fun.

What should we do?

With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else.

If you're looking for a quick "search and replace" alternative for existing setups, consider the .test gTLD, which is a reserved name by IETF for testing (or development) purposes.

There's also 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.

I do hope the Chromium team reconsiders the preloaded HSTS as it's going to have rather big implications for local webdevelopment.



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Hanno Sunday, September 17, 2017 at 12:03 - Reply

A few comments from me.

First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway.

But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated.

Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)


    Weldon Sunday, September 17, 2017 at 15:36 - Reply

    @Hanno I think it’s silly to pay a CA for a development certificate. Even with the free services it’s silly; there’s literally nothing to be gained by having a third party “verify” your own identity to you. The right solution there is to implement an internal CA (which you should really be doing anyways) and install its signing certificate on your local browsers. Then you can secure anything you want locally, including just IP addresses.


      DevSecOps Jones Sunday, September 17, 2017 at 17:43 - Reply

      There is no cost to LetsEncrypt certificates, and using these is Development is appropriate.
      The hosts need not be reachable from the internet, you can use DNS records to prove domain ownership.

      I would be recommending use of globally trusted, gratis certificates on dev from LE.
      The certificate issuance process should use different key material for prod,
      but should be configured in the same way.
      Ideally production and development instances of your site should be created using a similar process but with different data sets.


        Fernando Sunday, September 17, 2017 at 18:52 - Reply

        You dont always want to expose your project names to public DNS or CT logs.
        also, Lets Encrypt API limits are so low , that using it in dev mode, would exhaust it in just 5 deploys.

        a better idea is to use something like hashicorp vault for CA management.


        Weldon Monday, September 18, 2017 at 22:04 - Reply

        There’s no financial cost to LetsEncrypt, but now you’re adding a trust dependency that you don’t have if you just run your own internal CA for internal PKI. It’s really surprising to me that apparently a lot of companies don’t do this; I had assumed it was universal.


    JB Friday, November 10, 2017 at 15:40 - Reply

    Hanno,

    since you highlighted this discussion in your latest newsletter, you need to understand that there are some very solid reasons for using unencrypted connections to physically secured (or not) test servers:

    A) The connection is so physically secure that no amount of crypto or DNS can do anything but hurt security. This is the case when mapping to 127.0.0.1 or any other address on or near your own machine.

    B) To debug the plaintext protocol carried over TLS etc. it is often necessary to inspect the packets with a tool such as tcpdump or WireShark. Encryption (and especially PFS encryption) intentionally prevents that and thus must be turned off in such laboratory tests.

    C) During development of a new device or server, there will often be points in time where the TLS integration has not yet been done.

    D) To ensure bulletproof HTTPS implementation on a website, developers need to test the mechanisms that redirect, block or otherwise handle incoming HTTP connections. Having the browser prevent the simulated mistake prevents testing the second and third layer of defense.


    Jens Monday, December 11, 2017 at 17:26 - Reply

    Stupid comment. What does google or anyone have to do with what .tld I use LOCALLY on MY MACHINE ? Think before you speak!

    Googles “nice guy” halo is really starting to look crooked. They make a lot of weird decisions affecting everyone on the web just because they can.


    leo Tuesday, January 16, 2018 at 07:09 - Reply

    Hell, you think that dev is stupid.
    But using hsts for no reason – that’s just disgusting. Moreover, it breaks things.


    Dave Sunday, February 11, 2018 at 16:11 - Reply

    Well I’ve been using .dev for almost 20 years and using development certificates issued by my own internal CA for almost as long. It has made its way into so much development infrastructure that it will take me weeks to move to some other domain name (only to find that ICANN greed results in that becoming a new TLD down the track).

    Your suggestion to use a subdomain of some real domain is pretty stupid if I don’t own any real domains, and paying for wildcard certs for a client’s temporary development is even more absurd when the TLS in this instance is unwanted in the first place and when the site’s only user is me on localhost or in a VM.

    While I have been frustrated for several hours by this strange behaviour of all my browsers (which is why it took so long to diagnose), now that .dev is a TLD I can’t really complain about the HSTS treatment by its owners.
    What is annoying is that the behaviour was silent and that it was triggered despite me having never visited the (now real) .dev domain and been sent a protocol upgrade redirection.

    Incidentally my choice of .dev for internal development back in the 90’s wasn’t random. At the time using .dev was as safe as 192.168 – it was ensured by the ISI NEVER to be a TLD because NetNames and Network Solutions hadn’t yet turned the domain registration system into a squatters paradise and global namespace hierarchies still made some sense (excluding the special treatment given to the US). Basically the Internet was still managed by computer scientists instead of millennials, hipsters and porn moguls.


    Dawesi Sunday, August 19, 2018 at 14:47 - Reply

    Forcing https makes both firefox and chrome non-standard browsers.

    Making a policy on a domain, and forcing a browser to obey it are two worlds that should never meet according to standards.

    Another example of Google abusing their godless powers to do evil.,


leonixyz Sunday, September 17, 2017 at 12:09 - Reply

another solution: change browser


hintss Sunday, September 17, 2017 at 12:24 - Reply

protip: you can type “badidea” at the https error screen to skip it, avoid using the mouse


WhyNoMas Sunday, September 17, 2017 at 18:11 - Reply

Changing browser and recommending your clients to do so is the way to go. Chrome is now what IE used to be.


Kees Sunday, September 17, 2017 at 19:56 - Reply

While I agree that this is not desirable, there is a specific TLD made for testing, .test (source: https://en.wikipedia.org/wiki/.test).


Mike Schinkel Monday, September 18, 2017 at 04:15 - Reply

Thanks for pointing this out.

As an aside, google.dev’s IP is not routable; see https://stackoverflow.com/a/25665936


    Aaron Cooper Monday, January 8, 2018 at 05:38 - Reply

    I do, on my test environment. Because that is it’s purpose. The same reason why I used .dev for development, not testing.

    Each to their own, but I find it a bit absurd to pass off the removal of a domain that has a phonetic link to the environment’s intention to use another one that has an entirely different intention.


      Dave Sunday, February 11, 2018 at 16:17 - Reply

      ^^^ this exactly. We use .test for our virtualised test environments, for which .test is served by internal DNS and is routable within the company, so this isn’t an option for local dev.


John McCormack Monday, September 18, 2017 at 12:57 - Reply

Yeah… I’m using Chrome less and less, using Firefox more and more.


Loïc Lavoie Monday, September 18, 2017 at 19:08 - Reply

You guys should remove the recommandation for .localhost as an alternative. Chrome and Safari force loopback on the locahost domain and any subdomain in it.

This means that any adresses ending with .localhost will force redirect to 127.0.0.1 without querying DNS’s or your hosts file.

https://webmasters.stackexchange.com/questions/88636/why-does-chrome-resolve-websitename-localhost-as-localhost


Zardoz Tuesday, September 19, 2017 at 10:13 - Reply

1. Drop Chrome, in fact drop evil google generally
2. use local.yourdomain.com with a *yourdomain.com cert for testing


Ashley Sheridan Tuesday, September 19, 2017 at 23:08 - Reply

To be fair, the .dev TLD was made available a long time ago, so any developer using it locally should have expected problems eventually. I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.


    Braeden Friday, January 5, 2018 at 22:01 - Reply

    There shouldn’t be a problem with using any .tdn if you mod your host file because that will redirect any existing domain name to your local machine. The problem here is that chrome is forcing HTTPS for a local site. I have code in place to detect whether I am on development or production so that .dev doesn’t use the same settings on production. But chrome forces https for .dev when it shouldn’t.


    rox0r Tuesday, February 27, 2018 at 20:04 - Reply

    > I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.

    You don’t have control over the public DNS system. Which is why people run their own local DNS system that is a complete fork. There is no standard against running your own private DNS system. This treats those domains special when there is nothing special about them. If anything, chrome/firefox is assuming that the user is using the public DNS system.


vjanzen Wednesday, September 20, 2017 at 21:19 - Reply

The IP 127.0.53.53 is a name collision entry.


tim Thursday, September 21, 2017 at 00:07 - Reply

I used use .local then found out about the clash with Bonjour. Then I switched to .server for my local servers (so far so good) and .dev for my local development (oh dear). But fortunately I use a dnsmasq server and can switch it out for something else. I name things as their full production domain plus .dev on the end, and that’s been fine for now. Many of the web apps I work with require a single domain name hard coded into a config file (such is life) so there will be one-time pain of updating those. I would support an official .localhost if it didn’t introduce untold security holes.


Fuck You Thursday, September 21, 2017 at 04:16 - Reply

f**king stupid google, go f**king eat s**t. We are using .dev for develop domain in our company, and all of a suddent we can’t access our dev sites anymore, WTF. Bulls**t!!!!


Anh Tran Thursday, September 21, 2017 at 04:43 - Reply

Don’t know what Google is up to, but this is not a smart step. Affecting all the developers in the world with a simple commit. A millions of working hours will be wasted.


ian Hobbs Friday, September 22, 2017 at 00:01 - Reply

interesting…. I just always used .site domain


Google Stupid Friday, September 22, 2017 at 09:04 - Reply

Google is evil. If they do that, let’s use https://blisk.io


Matthias Monday, September 25, 2017 at 17:07 - Reply

People. Just use the domain that’s actually reserved for testing. .test. You can, of course, easily get valid certificates for that. They just need to be in the local certificate store. Laravel Valet does that autimatically. Others do, too.


Burak Thursday, November 9, 2017 at 23:04 - Reply

Wtf, I wasted my days to find the issue. I was about to clean reinstall my Mac.


foogle Thursday, December 7, 2017 at 12:04 - Reply

Yes WTF Google is trying to do? What a pain they are causing to developers like myself, I think they trying to monopolize and we’r like their puppets that they can control go to hell google.


Sierk Bornemann Thursday, December 7, 2017 at 15:49 - Reply

RFC 2606 (June 1999): Reserved Top Level DNS Names
https://tools.ietf.org/html/rfc2606

[quote]
[…]

2. TLDs for Testing, & Documentation Examples

There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.

For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.

To safely satisfy these needs, four domain names are reserved as
listed and described below.

.test
.example
.invalid
.localhost

“.test” is recommended for use in testing of current or new DNS
related code.

“.example” is recommended for use in documentation or as examples.

“.invalid” is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.

The “.localhost” TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.

3. Reserved Example Second Level Domain Names

The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.

example.com
example.net
example.org

[…]
[/quote]


    Dave Sunday, February 11, 2018 at 16:28 - Reply

    “For example, without guidance, a site might set up some local
    additional unused top level domains for testing of its local DNS code
    and configuration. Later, these TLDs might come into actual use on
    the global Internet. As a result, local attempts to reference the
    real data in these zones could be thwarted by the local test
    versions. ”

    The purpose of this document was to reserve TLDs for use in documentation and test code for DNS server implementations.
    Note also that when developing enhancements for existing production systems I am often very deliberately ensuring that “local attempts to reference the real data in these zones could be thwarted by the local test versions” and my browser should not be trying to “help” me by playing Big Brother. Its almost as bad as the incessant insertion of www. before anything I type in the address bar.


Dani Thursday, December 7, 2017 at 18:06 - Reply

That decision is bullshit! Time for another browser.


Dan Friday, December 8, 2017 at 04:22 - Reply

Thank you for posting this article. I just wasted 3 hours of my life on this. Would have been nice if Google had just posted a simple error message. If not for your article, I don’t know what I would have done!


    katwekibs Monday, March 26, 2018 at 09:51 - Reply

    Missing the point. Google has nothing to do with this. Google might own the .dev tld, but like any other tlds, i could still be able to bypass the server lookup using my host file or local dns service.

    The problem is Firefox now renders our host file useless by not querying it first. This is a BS decision from Firefox them selves not google.


Marat Friday, December 8, 2017 at 09:22 - Reply

Thanks for info. Wasted hours on this


mostafa Saturday, December 9, 2017 at 11:26 - Reply

shit …
shiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit
:|


Adam Patterson Sunday, December 10, 2017 at 23:09 - Reply

I don’t really get why chrome forces the HTTPS though? Personally, I have to set my prefered domain. I handle the redirection of HTTP to HTTPS.

And Google owning the .dev TLD is kinda shitty to force this change on people, Weather you think its good in the long run. I would bet that no one owns a .dev and you probably won’t.


Changedev Tuesday, December 12, 2017 at 02:43 - Reply

I opened a incognito window and still got redirected to https. Thought something broke something. Thank you for saving my day trying to figure this out. I can now spend the rest of the day changing all my wordpress installs. Yay, such fun.


angry guy Tuesday, December 12, 2017 at 09:04 - Reply

Chrome tech leads and managers are idiots


Tesh Tuesday, December 12, 2017 at 14:18 - Reply

Time to use Firefox again like back in the old days!


Chrome TD Tuesday, December 12, 2017 at 20:24 - Reply

What happened to not being evil Google??


Svetlana Wednesday, December 13, 2017 at 11:29 - Reply

Saved my day. Thanks! I wonder why still no word from Google, would have been nice to hear something like “Hey webdevs, ditch your .dev-s, because now we rule your domain”… But no, of course, all of a sudden I just can’t reach my dev ground any more, as it’s all httpsssssed


    Tyler Reed Thursday, December 14, 2017 at 17:41 - Reply

    That, and some people have a “dev” environment AND a “test” environment. One of the projects I’ve worked one needed 6 environments (for coding, testing, acceptance, staging, etc.). Making our local sites end in “.test” would confuse our staff into thinking that our development environment is our test environment.


Cysioland Wednesday, December 13, 2017 at 19:52 - Reply

They urge people to use domains like .test, but also disallow these in their OAuth redirects.


Tamas Amon Thursday, December 14, 2017 at 00:22 - Reply

I made:
valet domain test
And now I using every directory with .test and not .dev
Not a nice feature form google chrome


ChromeDeveloper Thursday, December 14, 2017 at 12:30 - Reply

I have no words


Klaus Donnert Thursday, December 14, 2017 at 14:52 - Reply

I just switched to Firefox. Problem solved.


Alex Thursday, December 14, 2017 at 16:36 - Reply

I hate other browsers but i going to use safari or something.


Alexander Thursday, December 14, 2017 at 18:11 - Reply

Wasted half a day trying to reach my dev site… I use it with https but it still doesn’t work.
Although you said that “Have that self-signed certificate added to your local trust store (you can’t dismiss self-signed certificates with HSTS, they need to be ‘trusted’ by your computer)”
I’ve added certificate to my windows machine but it still doesn’t work.
Could someone, please, explain what is the correct way to add certificate “local trust store” so that I can continue to use .dev site via https?


Noname Friday, December 15, 2017 at 15:41 - Reply

Google idiots!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


google idiot Friday, December 15, 2017 at 17:16 - Reply

down grade google chrome fuck you google idiots


Alex Friday, December 15, 2017 at 17:32 - Reply

Hey, Google, why only .dev & .foo? Go on, redirect all domains to https…
Couple of idiots in Google tell me what TDLs I should use for develop.


Bruce Klein Friday, December 15, 2017 at 23:54 - Reply

Thank you for publishing this explanation.


TobiVino Saturday, December 16, 2017 at 06:34 - Reply

Same thing goes with .app prefix , damn chrome


    Boris van Katwijk Friday, March 23, 2018 at 15:32 - Reply

    When using docker-compose services, beware of naming your services dev, app or foo. These may cause the same redirects e.g. when using selenium to access your services.


Digital Apps Sunday, December 17, 2017 at 11:52 - Reply

so glad i found this article, half a day wasted on configuring my apache. google, its a bad idea.


Masa Sunday, December 17, 2017 at 15:39 - Reply

Crome team literally hate developers. :( They have made impossible configure self-verify certificates and now this. All this no other reason other than being ash. What it’s them what I do my computer?

There is cost LetsEncrypt certificates you haw to pay domain.


Kevin Monday, December 18, 2017 at 12:11 - Reply

Very thankful for this article, wasted several hours on this…


Emanuele Ciriachi Monday, December 18, 2017 at 13:09 - Reply

Well this is some annoying nonsense right here. Goodbye Chrome, welcome Brave.


toddz Monday, December 18, 2017 at 21:31 - Reply

Is there a Chrome Extension that can fix this – to allow “.dev” domains locally? I want to stay in Chrome because I like its Dev Tools, and changing the “.dev” to “.test” in all my databases would be a huge pain.


Jalcide Wednesday, December 20, 2017 at 19:01 - Reply

Ugh. This is so irksome. Of course Google’s update rolled out at the exact moment I updated my VM, sending me on a red herring goose chase.

I refuse to use .test, on principle. I’m not TESTing, I’m DEVeloping.

The .dev gTLD shouldn’t even be a thing. Clearly, it should be reserved for developing.

What alternative (not .test nor .localhost) are people using?


Thomas Wood Wednesday, December 20, 2017 at 19:48 - Reply

*.localhost (properly referred to as “localhost.”) is already defined in RFC6761 https://tools.ietf.org/html/rfc6761 to always resolve to the local loopback interface. The linked proposal RFC forces DNS resolvers to not use the domain search list if they encounter “localhost” as the final portion of the requested address, and to assume that “localhost.” (the localhost TLD) was intended.

Google are planning to open *.dev for public registration in early 2018: https://www.registry.google/


FML Thursday, December 21, 2017 at 04:02 - Reply

WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.

Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”


FML Thursday, December 21, 2017 at 04:04 - Reply

WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.

Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”

UPDATE: corrected email address, delete my other post if you wish.


Charan Thursday, December 21, 2017 at 13:21 - Reply

As Developer i will continue to use *.dev for Developemnt setup , what ever the google has to do with .dev domain let them do still localhost is all ours to lay rules !


jmandawg Thursday, December 21, 2017 at 13:25 - Reply

Unfortunately there is a bug, this also redirects http://dev/ (where dev is an entry in my hosts file) to https which is not *.dev


Ali Saturday, December 23, 2017 at 23:09 - Reply

I’m using dnsmasq and nginx to test my codes locally, I use self signed certificates for all .dev domains too.
The problem is that Chrome shows following error everytime I want to access my local domains:

Your connection is not private
Attackers might be trying to steal your information from *****.dev (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID

No more information.
Thank you google for ruining my development environment for the whole week :|


Chris Monday, January 1, 2018 at 02:02 - Reply

site.localhost doesn’t work in latest Chrome either but site.test works


Dave Wednesday, January 3, 2018 at 12:11 - Reply

Ow goody. Google better bring out a patch where you’re able to easily switch this off… within the development inspect window or something. Cause developing != testing. I’ve got .dev .test and .preprod urls that I use in my workflow and this move sh*ts all over that. Happy new year!


Gazsi Friday, January 5, 2018 at 19:22 - Reply

say goodby to chrome, welcome to new firefox


steve Thursday, January 18, 2018 at 15:22 - Reply

Oh well, that explains the last few hours of frustration.
I cant just ditch chrome, the dev tools are better and I use it in automated testing as well.
I guess i am going to have to sort out a self-signed cert solution – anyone have any pointers?


Jean Monday, January 22, 2018 at 19:54 - Reply

Im also very upset with all these decisions. SOFTWARES SHOULD EXECUTE WHAT YOU ASK AND NOT THE OPPOSITE. If I want to go to blabla.dev, I don’t want to go to https://blabla.dev. This is the first principle of software UX. I definitely think that google developers should go back to school !!


Renan Saturday, January 27, 2018 at 04:40 - Reply

What about using dev as a subdomain like dev.yoursite.com? I’ve changed my own hosts using prefix dev.* and fixed the issue.


    Berg Wednesday, January 31, 2018 at 22:45 - Reply

    Yeah you’re right. I also think this should be a good workaround.
    Here’s my setup:
    dev.my-app.com
    test.my-app.com
    stage.my-app.com


      Ben McIlwain Friday, February 2, 2018 at 03:52 - Reply

      Using real domains or subdomains that you own is actually the ideal, recommended way to set up testing/development sites. It solves the problem of name collisions and some services not allowing not-real domain likes (like *.test ones).

      So it’s definitely not a work-around, it’s a best practice!


        Dave Sunday, February 11, 2018 at 16:49 - Reply

        Only for your limited naive web-dev use case. Not all internetworked applications are the public face of your organisation. For example, one of my systems is a massively distributed swarm of microservices using unqualified service names for instance resolution through DNS. In this case a single public facing application with a single web UI hostname is backed by a few dozen private app hostnames that should only ever resolve within their datacentre. So we stage our apps through .dev, .test, .uat, and then to private domains named for their datacentre.
        It used to be simple to test parts of this system through the browser in development – now its broken and “just change to .test” isn’t an option. With Google about to publicly sell .dev domains the problem is about to move beyond the browser. All in all allowing the .dev TLD to be registered in the first place was a major fuckup by ICANN. .dev and .test were chosen by me many years ago (long before Larry or Sergei had even thought of Google) because the ISI naming rules of the time meant it could never become a TLD. So what you consider a poor practice today WAS best practice until the goal posts moved.


Javier Saturday, February 10, 2018 at 13:19 - Reply

Three days I can’t use FF for development, many thanks.


jalmos Tuesday, February 13, 2018 at 08:34 - Reply

Thanks for the notice. Haven’t run into any noticeable problems yet, thank His Noodly Appendage.

Must grant this does encourage some good practices, forcing people to use a cert from the start, as my experience tells, can sometimes prevent disaster in projects with first-time/unknown/multiple/platform-or-language-specific admins/devs. It’s also honestly ‘best practice’ to have dev traffic encrypted, even if it’s already happening at the netsec level (shit, it would be best to be hardwired to a gapped vlan, if you have anything worth stealing).

That said, I have a lot of work on a .xxx.dev, and so do plenty of others. All this makes me think is ‘how much work will I have to put in to resurrect FF or will it be quicker to do all the renaming work, given how bad FF is now?)”

This just feels like a ‘because f(*$ you, that’s why’ situation. My dev urls are all second subdomains, with 15-char random sequences at the top. What do I need SSL for until I’m ready for it? What moron was making easily-guessed dev sites for any parent site worth being included in a bot scanner list?

Of course the big S is better in general, but to apply like this? That’s not acting in anyone’s best interest. That’s just throwing your weight around. Excepting morons putting up data worth stealing, no one will benefit from this in any meaningful way.

After saying all that, I mist admit that, apparently, this will help a lot of morons. So, not a total loss in terms of ‘do the right thing’ (still violates ‘don’t be evil’ in my estimation).

Google, you’ve done enough to help them already.


Sobri Kamal Wednesday, February 28, 2018 at 08:21 - Reply

There you go right there straight up stupid decision from google..Im surprise such decision were made in google..Dictionary have to update their definition of ‘Google’ to -> Dumbass..How come they want to dictate what kind of domain i should for my local development? Plain stupid


Adnan Friday, March 2, 2018 at 07:43 - Reply

I have created vhost on my local machine. using wamp. I don’t think so this is a good approach.


Daniel Thursday, March 15, 2018 at 15:03 - Reply

You can disable the preloadlist at firefox.
Just change network.stricttransportsecurity.preloadlist to false.
Now your .dev-Domain will work again with http :-)


Dave Wednesday, March 21, 2018 at 15:40 - Reply

Thank you for this post!!! I’ve been having trouble with Chrome and Firefox so I had to switch to Edge. Fortunately, for once, Microsoft doesn’t fall in line with every body else and I was able to keep my development going. But what a pain in the a** this is!!!


tutoref Friday, March 23, 2018 at 21:00 - Reply

Is it legal if someone make an extension that reverses that behavior ?


tutoref Friday, March 23, 2018 at 23:52 - Reply

Ok I found a solution for Firefox but not for Chrome.
Check the solution here : https://tutoref.com/how-to-prevent-firefox-and-chrome-from-forcing-dev-and-foo-domains-to-use-https/
Note : For firefox you can do some alternatives.


John Sunday, April 1, 2018 at 19:45 - Reply

Fucking idiots at Mozilla breaking “localhost” development just because someone bought a domain on the internet!
How morons can their developers be?
I lost two days of work trying to fix this crap.
The only good fix is to downgrade Firefox to an older not so stupid version.


Ergo Wednesday, April 4, 2018 at 10:51 - Reply

Thankfully, Serverpress – the developers of DesktopServer (an excellent local server package for WP dev) have released a free solution to this for both their clients and the general dev community. It’s based on their own domain: dev.cc. Read about it here:
https://docs.serverpress.com/article/232-how-to-change-top-level-domain-dev-extension-google-chrome-users


Annie Wednesday, April 11, 2018 at 18:36 - Reply

THANK YOU – like so many others, I lost half a day trying to ‘fix’ this (when Firefox started pulling the same crap Chrome began months ago with all my dev sites) – and another half day switching them all over to .test, and undoing the various attempts I made yesterday to overcome the problem without knowing its origin. A little warning in the browsers would have saved a sh!tload of wasted time!


Rick Umali Tuesday, May 1, 2018 at 14:49 - Reply

Mattias: Thank you for posting this. I was so confused why my ‘.dev’ site loaded properly in lynx and curl, but not Firefox or Chrome. Danke!


Max Friday, May 4, 2018 at 09:25 - Reply

MAAAN, I was trying to figure out what was the problem with my local dev env… You know what, I am really tired of google doing different crap just because they can. I already changed my default search to duckduckgo, now i am seriously considering switching to Firefox from chrome. Hard to find the replacement for youtube unfortunately.


Gokuu Tuesday, July 24, 2018 at 15:00 - Reply

Gooood lord, google what the f***ing hell. Took us whole day to figure out what the hell is happening.

Tnx much for article.


Leave a Reply

Your email address will not be published. Required fields are marked *