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
Don't use spyware posing as a web browser.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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...
The sad thing is that these days on Slashdot there are many people with such little understanding of technology that they will actually think what you say makes sense.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The alternative is Firefox. Seems Google doesn't want us using their browser anymore, and who am I to argue with them.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
.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...
Says the AC who has no credibility to trade on.
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!
They aren't being evil
They manage the .dev gTLD and one of the rules for using a .dev domain is HSTS
They shouldn't have been given any authority to manage .dev, period. .dev has been used for years for local like .local*/.test et al. Since I don't use crappy Chrome I don't have an issue, besides anyone dumb enough to trust public DNS servers before their own deserves this nice FU from them. I'm sorry if I seem a bit jaded but this is another example of why this 800lb gorilla needs to be broken up.
Oh yeah, before I forget.
Fuck Google, fuck *their* rules, period.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I think there's another reason at play here. Google are enforcing strict HTTPS on all their domains. This means browsers should always be using HTTPS to access any site under a google owned tld, including .dev.
Chrome, by enforcing this at the code level, is enabling another level of security for customers; preventing third party operators trying to downgrade or degrade what should always be a secure connection.
The only people being burned are those folk who used a valid domain name for their internal dev environments, and have continued to do so for 2 1/2 years after Google took ownership of the TLD. I imagine it's those very developers, slow to respond to change, that Google wants to nudge more strongly towards site-wide encryption.
This is a shining example of why, if we disagree, we should participate in the RFC process rather than go off on our own. And if we don't get our wishes in the RFC process, we shouldn't stage a rebellion. We need a functioning network. Four TLDs are reserved for this. .test, .example, .invalid, and .localhost. If .dev should have been a reserved TLD, there were 15 years to get it added from the time RFC2606 was published until .dev became a TLD.
This is a shining example of why, if we disagree, we should participate in the RFC process rather than go off on our own. And if we don't get our wishes in the RFC process, we shouldn't stage a rebellion.
I've participated in IETF lists and made it to a few meetings when in country. ICANN is not the IETF. ICANN is driven by money not consensus. A rebellion is exactly what I advocate and very much hope to see happen.
Either "throw the bums out" or raise pain felt by entry of new TLDs by having more operators not blindly delegating everything to root servers.
We need a functioning network.
Which is why it is not ok for bags of slime to intentionally break shit in order to enrich themselves.
Four TLDs are reserved for this. .test, .example, .invalid, and .localhost. If .dev should have been a reserved TLD, there were 15 years to get it added from the time RFC2606 was published until .dev became a TLD.
Half the RFCs worth implementing don't even work in the real world out the gate. There is a bunch of tribal knowledge one must have to account for the difference between RFC and what is actually implemented in real world. It isn't ok to simply cite chapter and verse of text and blindly ignore reality. What is or is not written down in some document isn't an excuse. As I said before responsibility is bidirectional. The lack of ".dev" appearing in an RFCs that results in IANA reservations in the GTLD space does not excuse irresponsibility demonstrated in the act of assigning it.
Nor does Google have an excuse for mistaking the ".dev" Internet namespace they own with all namespaces everywhere.
Both instances of irresponsibility exist independent of judgments against individuals for using .dev.