Slashdot Mirror
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.
We got hit by this, and promptly rolled back our browser versions. They're internal fucking development systems for fuck's sake, they're allowed to be insecure if **WE** want them to be.
I'm so sick and tired of dealing with this fucking nanny state of modern day technology where some dipshit developer thinks they know best, and they're just going to outright disable a feature that worked perfectly fine before.
So on behalf of all the developers at my company, fuck you Google. Keep it up, and we'll actually be inclined to go out of our way to strip out your shit and replace it with something else (which I'm told we're probably doing, given the lack of options to override this behaviour).
Bullshit. There is plenty of reason to use HTTPS and eschew HTTP. For one thing it eliminates the need to explain to laypersons, which is most people, how to tell the difference. This reason alone justified it. Worries about snooping and government spying are just icing on the cake.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Because you didn't use a reserved TLD you numpty. The same people probably use non-private subnets for their internal networks and then wonder why some websites that had the audacity to use that IP don't work...
.test is a better replacement, strictly speaking, since IETF has reserved that TLV (as well .example and .invalid).
Of course, it's pretty damn weird for a browser to hard bake assumption about TLD ownership and policy.
XML is like violence. If it doesn't solve the problem, use more.
Because you didn't use a reserved TLD you numpty. The same people probably use non-private subnets for their internal networks and then wonder why some websites that had the audacity to use that IP don't work...
While there are times where I would tend to agree this is not one of them. Responsibility is bidirectional.
Opening the TLD floodgates was a predictable, preventable disaster done entirely for selfish reasons at the expense of the network and all its users.
Allowing TLDs like ".dev" to be handed out in the first place was much worse. They knew or should have known how this was being widely used at the time and what the global implications would be yet like TLD floodgates $$$ wins the day.
Then Google was like...hey we own this TLD and we own a web browser so we'll just leverage our verticals to enforce arbitrary rules over what we own anyway that suits our specific needs.
This is a shining example of what happens when $$$ is allowed to trump reason and why allowing monopolies to get too powerful and start exerting ownership over more and more of the stack is a bad idea. They can and will do whatever they want simply because they can. They can't help themselves nor can they even understand that their needs and goals are not representative of the rest of the world.
Today it is HSTS tomorrow it is waking up to find browsers doing UDP with user land congestion algorithms configured to be twice as aggressive as TCP...oh wait.. that already happened...
While I'm not a fan of Zero__Kelvin, he is right. Client authentication is extremely rare in https connections. (And the average technological understanding on /. is absolutely shit)
In case you don't understand what that means: The client neither has nor supplies any cert in the TLS handshake, therefore there is no cert that can act as a cookie of whatever kind.
CLI paste? paste.pr0.tips!