Wondering Why Your Internal .dev Web App Has Stopped Working? (theregister.co.uk)

Kieren McCarthy, writing for The Register: Network admins, code wranglers and other techies have hit an unusual problem this week: their test and development environments have vanished. Rather than connecting to private stuff on an internal .dev domain to pick up where they left off, a number of engineers and sysadmins are facing an error message in their web browser complaining it is "unable to provide a secure connection." How come? It's thanks to a recent commit to Chromium that has been included in the latest version of Google Chrome. As developers update their browsers, they may find themselves booted out their own systems. Under the commit, Chrome forces connections to all domains ending in .dev (as well as .foo) to use HTTPS via a HTTP Strict Transport Security (HSTS) header. This is part of Google's larger and welcome push for HTTPS to be used everywhere for greater security.

Comments

Re:Fuck off with this security bullshit.

[Junta]

This is of course true, but bad practice. I disagree with the idea of baking in this sort of thing into the browser software, however whenever you stray from officially reserved values, you can land in a world of pain.

For example, you use '.dev' for your internal sites. Sure, you control DNS and you can do that. Suddenly, a workstation needs access to something google is hosting on .dev. Suddenly, you have a self-inflicted wound because you didn't stick to private use reserved values, and you don't have a clean way out of reconciling this.