Hacker News new | comments | show | ask | jobs | submit login
The days of .dev domains for testing code are over (medium.engineering)
73 points by micahgoulart 10 months ago | hide | past | web | favorite | 93 comments

OK, so after a few pages of unnecessary history, the story is that Google bought the .dev TLD and uses it only for internal purposes.

.dev isn't launched yet and we aren't using it for internal purposes. This is a common misconception about .dev that just will not die. It is delegated (will resolve in DNS) but not yet launched (not yet available for registration). Stay tuned for updates.

The "internal purposes" misconception stems from the TLD-wide wildcard DNS entry pointing to that is required by ICANN's Controlled Interruption process for all new gTLDs. For more info see here: https://www.icann.org/resources/pages/name-collision-ro-faqs...

(Source: I'm the lead engineer of Google Registry.)

Thanks Chrome. I use .dev quite a lot. Looks like I'll be using FFox for development from here on, until they also decide to usurp their position! And then I'll just use lynx.

Of course, I could change my ways and start using a different naming system: I notice a lot of development shops using .local, albeit for same machine dev & testing.

Edit: lol. tried to use 'star'.dev, but it came out in italics!

Definitely not evil, Google. Definitely.

Thank you.

While this is an interesting exploration of the history of the Internet, gTLDs, HSTS, and various other things, the story boils down to this: never make up an unregistered domain/TLD and assume it won't exist in the future; always use a reserved test domain/TLD from RFC 2606 (https://tools.ietf.org/html/rfc2606) or the updated RFC 6761 (https://tools.ietf.org/html/rfc6761): .test, .invalid, .example, or .localhost, depending on what semantics you need.

This.. seems to resolve every issue I might have otherwise had with the story, including the impulse to yell at Google about it, but the author himself makes a fair case for not doing that.

It turns out that part of the way the internet is declared to work includes reserved TLDs to be used for testing. So the burden of responsibility for avoiding a situation such as the article describes lies on the developer to use one of those reserved TLDs instead of ".dev", which anyone could (and now, has) come to control.

Yeah, fake domain names and TLDs are an issue with Microsoft sysadmins in regards to .local. I aggressively move environments away from using anything half-baked like ".dev.", and while some people like ".local", I'm not a fan. Ignore the spec at your own peril.


This might seem prophetic or cocky, but I've used a random b64 TLD for years that I expand with a macro. After we expanded past countries on the TLDs, I just figured that any short (or even sensible) TLD would eventually be taken, and I didn't want that to break any of my tests that had hardcoded domains (as rare as those are.)

to be fair, before icann introduced the gtld program, it was a fair assumption that there wouldn't be a .dev tld.

But also, the folks at medium made that assumption long after RFC 2606 had established a "right answer" for which tld to use when testing.

i think i wasn't being clear with my initial comment. it's a "fair assumption" in the same way that it's a fair assumption that emails can be validated with the regex

sure, it breaks for gmail aliases (with +), isn't RFC compliant, and the proper regex is a google search away, but it's understandable why that was chosen. same with .dev domains. yeah, you probably should have looked for a reserved tld, but why do that when .dev already didn't exist, and it didn't look like icann was going to delegate that any time soon?

see also: https://hn.algolia.com/?query=falsehoods%20programmers%20bel...

These don't strike me as comparable scenarios.

In the case of .dev, it didn't even appear in the weeds of usage when the DNS root servers were measured for traffic to identify potential new TLDs usage conflicts in the real world (e.g. https://www.icann.org/en/system/files/files/name-collision-0... p22). Even if .dev were in significant usage, that traffic was not reaching the domain name system. The complaint seems to be fundamentally to be about the pre-loaded configuration of Chrome, not the DNS.

In the case of your regex, it would breaks millions of production domains in used today and fail in a wide variety of scenarios. It is only understandable in the context of someone who hasn't done any cursory research into the topic.

To be honest, programmers should be more aware than most that the spec will change and previously "fair" assumptions won't hold.

The spec hadn't changed though; RFC 2606 has been around since 1999.

An implementation policy that is overtly not a stable specification changed.

Using “test" at some level of the domain name, including the top level if desired, has been the documented correct and safe answer for a long time, and .dev has always been an unnecessarily risky hack. (Amusingly, everyone else doing that hack got screwed because Google was using it as well and realized that if it didn't take control of the TLD and manage it to support it's pre-existing internal use, it ran the risk of someone else doing that.)

> The other option is to change your .dev domain and never look back. But what domain could we migrate to? With the gTLD gold rush, is anything safe?

Just buy medium-devel.com or something and make it resolve to in internal DNS. This gets you a couple of benefits:

- No one will ever take it from you

- You can configure it in external DNS if you'd like

- You can get a real, publicly-trusted SSL certificate for it, for free, because Let's Encrypt can resolve DNS challenges against it

(By the way, you want to get an SSL certificate for internal development, because of the policy - Chrome-initiated but now followed by the HTML standards folks in general - to require HTTPS for fancy new features like geolocation and service workers: https://www.chromium.org/Home/chromium-security/prefer-secur... If you don't have HTTPS of some sort, you can't test these features locally.)

- You can set up a service on the domain that logs the incoming requests on the domain, which can help you pinpoint misconfigured parts of your infrastructure

This is exactly what I've been doing for years and got my current workplace doing.

We set up `*.l.example.com` (where example.com is our company's domain) to all resolve to I personally have nginx set up to map `project.client.l.example.com` to `/path/to/webroot/client/project/`.

All of our infrastructure has hostnames under our domain and references other pieces of infrastructure using those hostnames.

Why is everyone putting so much effort into trying to operate outside of the established domain name system? To avoid paying the $10/yr?

If your public website has access to sensitive credentials, and you tend to be logged in on your development machine (imagine you're amazon.com, or google.com, or something), I would recommend using a separate domain registration instead of a subdomain of your production domain, just so that vulnerabilities in your development site don't risk exposure of production cookies or other credentials. As you say, it's <$10/year. It also lets you buy a wildcard cert for *.contoso-dev.com and make the private key readable to the entire company and not have to think about whether this is a security risk.

If your public-facing website is just a static landing page (e.g., you're a B2B company or a design agency or a hedge fund or whatever), then yeah, using .dev.contoso.com works.

(By the way, the same analysis applies to running internal services at out-of-date-wiki.corp.contoso.com - consider whether you'd be happier hosting them at out-of-date-wiki.contoso-corp.com instead, and having contoso-corp.com not exist in external DNS.)

Good points and appreciate the advice - I hadn't considered that. Thankfully our public-facing site is essentially static.

Even in the static-site case where the risk may be minimal, there's certainly no harm in moving these sorts of things to a separate domain - especially for anyone looking at this as a new setup due to .dev issues.

I absolutely hate this gTLD crap. The fact that companies can pick up any TLD on the global namespace is absurd. Even worse, the internet community never had a chance to object to these sales.

Something that pisses me off even more is that a few months back there was an IETF draft to specify the .home TLD to only resolve local network requests. It seemed pretty reasonable, but there was pushback and it was changed to home.arpa, since the .arpa TLD is already restricted. So big companies can pick up any TLD they want, but regular users will forever be forced to type in extra characters.

Never had a chance? The rules that would allow this kind of allocation were debated publicly and strenuously for many years in Internet governance circles, with many iterations of drafts and public comment periods. Some of those rules specifically governed which domains should be disallowed because they would have impact on existing utilization, as well as those that needed to be reserved for technical reasons.

“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now.”

I had no idea you could buy gTLDs for internal company use. That’s outrageous, and ICANN should have rejected the application. I don’t mind the idea behind gTLDs, but the while thing has been handled pretty poorly.

Especially something as generic as .dev. I could possibly see Google having a legitimate claim to a .google TLD, but not something like .dev that is in no way limited to Google.

As a side note, Google already owns and uses the .Google TLD.

That's why I mentioned it. I also disapprove of .google, but it's less ridiculous.

> for internal company use.

There are no gTLDs intended only for internal company use. There are many that are intended for only a single companyto use them, though externally.

For example, the .americanexpress gtld (https://www.nic.americanexpress/) will only provide domains to entities affiliated with american express.

Same with .dodge, and .google, and many many others.

ICANN handled this quite well -- they let others object to applications, let anyone who may have a trademark or reason to claim the word was generic come forwards, left time for comments, etc etc.

If you're objecting to this now, not back when the program was being formed, you clearly handled this poorly by not being involved in something you care about.

If you don't care and weren't involved, you also don't have the full picture and your outrage very well might be misplaced.

> If you're objecting to this now, not back when the program was being formed, you clearly handled this poorly by not being involved in something you care about.

> If you don't care and weren't involved, you also don't have the full picture and your outrage very well might be misplaced.

That's an unhelpful and unreasonable response. You shouldn't blame people for not being attuned to the activities an obscure bureaucracy (the gTLD process), just because they might be affected by it. The gTLD process has a problem, not the people negatively affected by it.

There really ought to be a long post-implementation objection period for gTLDs, and the existing process should be changed to allow for that. The top goal of the DNS system right now should be to not break stuff, and that should override any entity's desire to buy a gTLD for $$$.

You can't un-delegate TLDs once they've been delegated. That breaks the Internet. The creation of a TLD is thus irreversible, and deleting a TLD would cause a lot more harm than it would prevent.

What you can do is transfer the TLD to a different operator, and/or change its registration policies, though all of the existing domains on the TLD need to remain with their existing owners, as domain names are legally treated as property and cannot be confiscated except through due process (like a court seizure following a ruling on illegal activities).

> as domain names are legally treated as property and cannot be confiscated except through due process (like a court seizure following a ruling on illegal activities).

That's just current convention, though. If better governance means being less private-property absolutism, I'm for it. ICANN or whoever could just update the terms of their contract to allow revocation of the TLD (with a refund), if there's too much weeping and gnashing of teeth over it's issuance. People would just need to understand domains on a new TLD aren't going to be as ironclad as ones on more established TLDs.

But .dev is being used only internally, according to the article.

The article quoted Google's application, which only claims private registration, and then makes wrong assumption's about google's intended use of it. The article's wrong, or used internal to only mean "closed registration".

Having read https://tools.ietf.org/html/rfc6761, I have a use-case which I've seen often but doesn't seem to be covered: What TLD should I use for internal, production domains? ie. names that are only resolvable within my network, but are definitely not "test" domains and calling them .test would generate confusion.

Mostly I tend to see companies either inventing an unregistered TLD, often using their own company name, or they use ".local", which can cause issues - some systems treat this name specially.

A third option would be putting all internal names under an "internal.yourcompany.com", but that's long and annoying.

Ideally I'd like to see a ".private" or ".internal" TLD recognised as special-use under the same semantics as ".test". Does anyone have any better option?

> What TLD should I use for internal, production domains?

The currently safe way is to use a public domain that you own (you could use a distinct subdomain for this, which is not publicly exposed but which is in DNS on your internal network; e.g., intranet.example.com if you own example.com); as you note, this gives a long full domain.

> Mostly I tend to see companies either inventing an unregistered TLD, often using their own company name, or they use ".local", which can cause issues - some systems treat this name specially.

“.local” is a reserved domain with special semantics, see RFC 6762.

> Ideally I'd like to see a ".private" or ".internal" TLD recognised as special-use under the same semantics as ".test".

I'm kind of surprised that we haven't seen an RFC gain acceptance for this already, but I expect something like this will happen and be registered with the IANA special use domains registry.

My colleague has written a draft RFC for this very use case, in fact: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-interna...

It's still very much in the early stages though.

Even then, though, you can end up with all sorts of problems during mergers/acquisitions when previously separate intranets end up getting joined, exposing naming conflicts. Ultimately you always need to use a globally unique namespace, so either use a real domain name (guaranteed unique) or do something unique on top of .internal, e.g. .yourcompanyname.internal (still not guaranteed unique, but better).

See also: https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html

The third option IMHO is the best, although I'd consider using a domain just for this instead of a subdomain. (can be shorter and uglier then as well)

tl;dr - Google bought the .dev gTLD, specified it for internal use, and pushed changes in Chrome to require HTTPS.

Is that monopolistic behaviour?

"Is that monopolistic behaviour?"

No. Acquiring the TLD has nothing to do with any monopoly, so it's just a browser decision made by Chrome, and it isn't locking anybody out of any markets.

It's also technically not even a change to the status quo. Beforehand, you weren't supposed to be using .dev like that. As the article says, you should have been using .test or .invalid. After Google's actions, you still shouldn't have been using .dev and should have been using .test or .invalid. You can't hear my tone, but I don't mean that in the imperative or angry; we've pretty much all screwed that up at some point. But a screw-up it was.

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world.

This is like Ford registering ".car" gTLD for themselves (although actually worse).

> It's also technically not even a change to the status quo.

If it wasn't a change to the status quo, they would have just used the exact same test domains you mention. You're saying that what we should not have done, is okay for Google to do.

> You're saying that what we should not have done, is okay for Google to do.

No, what we should not have done is used an unregistered and unreserved TLD for testing/development. What Google has done is registered the .dev TLD, and started to use it for development.

They were already using it for development. Just like everyone else. They "officially" took it away from everyone else, and then forced it to be TLS-only.

This is the internet development equivalent of the copyrighting of the song "Happy Birthday to You".

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use.

And? What entitles any of us to use that domain? And as far as that goes, you can, as I understand it, still use that tld, since your local DNS resolver or hosts file can always override how hosts are resolved in there. The only real issue is if you hit the specific issue where a change in Chrome behaviour w/r/t this specific TLD, breaks something in your workflow.

> What entitles any of us to use that domain?

You're right. I didn't pay for it, so I'm not entitled to get to use it.

Just because there is only one internet, and only one top level domain namespace, and just because I don't have $150,000, does not entitle me to get to use some part of the internet in the same way as a single corporation with a lot of money.

What entitles anyone to use the internet? I don't pay for the root name servers. I don't pay for peering transit. I don't pay for core routers.

I guess your point must be that corporations [and nations] should use their money and influence to acquire large chunks of the internet and screw with it in any way that they possibly can. And we should not care, because we are not entitled to it.

You're right. I didn't pay for it, so I'm not entitled to get to use it.

Correct. So what was the point of the rest of your nonsensical rambling? Or do you have some other explanation of why you're entitled to you use that specific tld namespace? You can't just use arbitrary domains that you don't own, why should tld's be any different especially given the advent of gtld's which radically expanded the namespace?

You're also ignoring that that that you can still use .dev. The case where Google's ownership of it prevents you from using it (for internal use anyway) is a very specific, limited scenario.

does not entitle me to get to use some part of the internet in the same way as a single corporation with a lot of money

Nothing about this prevents you from using any part of the Internet. At worst it restricts, ever so slightly, the way you can name your resources. But there have always been restrictions on how you can name your resources.

The taking of a gTLD for private use simply to associate an entire generic concept with a single corporation is an abuse of the public's interest in top-level domains to be used to navigate resource on the world wide web.

The Chairman of ICANN said at the creation of gTLDs: "Today's decision will usher in a new internet age. We have provided a platform for the next generation of creativity and inspiration. Unless there is a good reason to restrain it, innovation should be allowed to run free."

Taking the entire ".DEV" TLD for a single corporation, as if Google is the only development corporation in the world, is not providing a platform for the next generation of creativity and inspiration. Potentially millions of users of this TLD no longer have the option.

I am not the only person who feels this way: https://www.theregister.co.uk/2015/03/13/google_developer_gt...

Google also tried to take ".BLOG", for sole use by its Blogger platform. Luckily they were outbid.

When Amazon proposed it taking the ".BOOK" TLD, publishers objected because, duh, this would be a hugely unfair attack on book publishers, sellers, and authors.

On top of the above, Google broke private use of the TLD for literally everyone who wasn't using TLS (and not just for domains Google registers in the TLD), but I'm sure lots of people simply don't care when Google does dick things, so nevermind that.

My position is that a corporation should not be able to stifle free and fair use of the internet. It's not about entitlement, it's about the fact that the internet is a global economic engine intended to be used by everyone, and not just exclusive corporations with money and influence.

"It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world."

You have answered the question "Was this selfish behavior?" or "Was this an asshole move?", with an answer I agree with. But that was not the question. The question was whether this was monopolistic behavior. The answer is no. As far as I know, several other TLDs have been similarly locked down by companies with no claim to monopoly power in any industry, which pretty much proves it's not related to monopoly power.

Not monopolistic, but pretty obnoxious. I don't think that move made them many friends.

Thanks for the tl;dr, but why buy a tld for internal use only? Just so nobody else would? (Maybe it's in TFA; I'll admit I didn't read it)

To ensure that nobody else does. Google uses .dev pervasively for projects - if someone were to buy .dev and sell domains in it on the global DNS infrastructure, then myfancynewproject.dev would resolve to something entirely different from within Google than from outside it.

> To ensure that nobody else does. Google uses .dev pervasively for projects - if someone were to buy .dev and sell domains in it on the global DNS infrastructure, then myfancynewproject.dev would resolve to something entirely different from within Google than from outside it.

So basically Google decided to break everyone else, because they were afraid someone would break them. They should be more considerate of other developers who use .dev internally like them.

Well, sure. If everyone had just followed the RFCs and used “test”, this wouldn't have been a problem, since lots of people didn't, most of them were going to get broken at sometime (unless someone submitted and got approved an RFC to reserve “dev” like “test”.)

Once the gTLD landgrab was announced, it was too late to push the new RFC approach, and it was likely someone was going to get the gTLD.

Someone who was using it for internal use like Google is probably less disruptive to existing users (even with their HSTS action) than if it had been someone who wanted to sell it for public use, which would have produced real chaos.

They should be more considerate of other developers who use .dev internally like them.

Why? What do they owe anyone?

>> They should be more considerate of other developers who use .dev internally like them.

> Why? What do they owe anyone?

Your attitude is the root cause of so many problems.

The have a moral obligation to not be jerks. If you're not aware, one of the things jerks are known for is acting selfishly with no concern for how their actions affect others.

Google shouldn't have been allowed to buy a gTLD like dev in the first place. But, since it has and Google only plans on using it internally, it should only use it in ways that don't break existing usages.

> Google uses .dev pervasively for projects

Do you have any source for this statement?

There is no source because it's not an accurate statement.

If that's true, wouldn't the right plan of action be for everybody to continue using dev as if it was a reserved TLD? Just pretend Google paid off ICANN to make it safe.

> Google uses .dev pervasively for projects

What are you talking about????

Edit: No real reply to the parent comment but on a slightly related/unrelated note: what I don't understand is why `maps/` and `shopping/` and any other google product when using Googles DNS goes to their servers, does this mean they plan on purchasing those gtlds?

Is this a real problem? Usually when I need a testing domain I make a subdomain on an address I or my company owns. dev.kluny.com. Easy.

It was a really bad practice that, for some reason, got really really popular - so especially in the Ruby community and it's derived branches - but it was still always a bad idea to make up your own domains for testing.

So it isn't exactly a shock that this bad practice is going to bite its users. I think the reason it's getting headlines is why it's biting those users now, all at once.

It's a real problem because a lot of folks do this and it's going to frustrate a few of them. However, this is also a great reminder for everyone to never make up your own TLDs.

The article outlines two options. There is a third.

Lobby google through petitions and collective developer action to surrender their .dev TLD and create an RFC that makes it reserved for developer used, similarly to .example and .test.

I'm not sure a strong case can be made that Google should be obliged to do that. There already exist TLD suffixes reserved for testing. ".dev" just isn't one of them.

I would beg to differ. As you've mentioned, there exists an official TLD suffix. However, de facto, .dev is the testing TLD. I've never seen .example or .invalid in real life. I've seen a tiny bit of .test. At every job that had a test dev, we used .dev. In many cases that decision was made by other developers. Judging by the comments here, and the article, it seems that many people have been using it.

A case can be made. How strong it will be remains to be seen. I hope Google can see the greater good in this. They have a lot of good will to win amongst the developer community.

Except, as you point out, .example and .test exist (and should have been used for this). What's the technical justification for the third?

Remember when APNIC got 1/8 from IANA and had to go test what would happen if they announced to the Internet? Just because something has been done historically doesn't mean we need to ban it entirely from the future.

There is no technical justification. There is a strong culture and habit of using .dev as the development TLD. It has not been codified and accepted formally.

Developers are humans. Technical justification is one of the things that should be considered when making decisions. There are many others.

Developers have not been widely using .example and .test as the spec recommends. They have been using .dev. It makes sense for it to be added as a reserved testing TLD. No one can force Google to do it. We can just petition them and hope that they do the right thing.

There is a lot of goodwill that Google can gain by allowing free use of `.dev`. Even more if they propose a spec to add it to the reserved domains. I would imagine it would be at least $185,000 worth of goodwill.

I really enjoyed this piece. We don't use .dev on my team so it allowed me to read it as purely educational. And it really was informative and surprisingly entertaining!

On a blog hosted at .engineering. Let’s just move away from all of these novelty Tlds.

Typical jerk move. This is not only taking the ball with you but closing the field and locking it requiring keys that only you have.

Not only is this problematic but so is HSTS, and the push for increasing reliance on CAs and in effect making self signed certs pointless.

The great concern for SSL by many people is simply ad supporting behavior masquerading as concern for privacy and state actors. Apparently ssl which is routinely mitm'd by small time corporations can protect privacy. Accept that with straight face while mitm vendors interests are paid attention to in standards meetings.

And Mozilla, the so called 'defender' cashing in on the public good will whenever it suits them conveniently caves in to Google at every opportunity.

Google will be buying up the 127.x.x.x ip range before you know it /sarcasm

i'm sure that icann can be persuaded to reassign ownership of that subnet if google paid enough money. it's not like there's much people using anything other than, so why not sell for some quick bucks? the only thing stopping them is the billions of legacy devices around that can't route to that address.

Wow, is it so hard to use a self-signed in your local dev config for nginx/whatever? I have a bash script that auto-spins up a new dev environment ala: ng create something.dev apps/php/laravel/app/public -- auto makes a self-signed cert, reloads nginx, and should still work in new chrome, since it uses https.

Am I missing something or are they whining over nothing? I would get a little perturbed if only .dev domains show up if you're on a google ip or something, but for now, using https is totally do-able.

If Google is only using .dev internally, and there won't be any public .dev domains, then who cares? As long as my hosts file routes .dev to the proper localhost nooks and crannies, nothing changes.

Unless you've bound yourself to Big G's browser. We only use that for last-minute rendering tests because management doesn't trust it not to leak info back to Mountain View.

Also, does Medium have a minimum word requirement? For some reason Medium articles always seem unnecessarily extra large.

Rather than maintaining a list of HSTS websites which isn't cross-browser, why is there not an optional HSTS flag attached to the DNS response? I don't know anything about DNS requests, so changing the protocol in a backwards compatible way might be impossible, but that seems like a much better way to maintain that information than with a separate list.

That would need to be combined with DNSSEC to be useful for security, but with that caveat that sounds like a good idea.

In my job we use our hostname.ourdomainname.com for internal things, so I don't see this problem as much. And it wont be accessible externally anyway.

We still have a huge number of the dev environments running on .dev, needless to say we were pretty pissed off when Google were able to buy the TLD to use as they wish. Anyway, not much we can do about it now other than start the process of setting up a new subdomain and reconfiguring all our CI/CD, Apps, Docs etc... I know we should have done it ages ago, there’s a ticket there for it... but resourcing.... sigh

Looks at `/etc/hosts`


isn't this solved by using Firefox instead?

No. If you waded through the history lesson, you'd eventually learn that Google maintains the list of domains requiring HTTPS that all the other browsers use. Unless something changes, Firefox will eventually pick it up.

Right up to the point where you need to at least look at the website in chrome to make sure it renders correctly.

No. All major browsers use the HSTS preload list.

Hmm. I have never seen this done or heard of it being done.

"Like a small child, your operating system believes in "stranger danger" and doesn't trust self-signed certificates."

[ ] True [x] False

First, is it the OS that distrusts certificates, or is it the HTTP client?

Second, CA certificates such as the ones trusted by HTTP clients (contained in "browsers") are self-signed certificates.

Pre-installed CA certificates in corporate HTTP clients (e.g., Chrome, etc.) and CA certificates in downloadbale "bundles" available from corporations (e.g., Mozilla) are self-signed.

As much as I agree with not using a public TLD as a dev environment, why the fuck was google allowed to register and privately secure not one but several domains for their own private use? Fuck them. That shouldn't have been allowed, especially for a TLD that's well known to be heavily used.

I really dislike allowing domains to be used in such a way. It seems extremely short sighted.

Anyone is allowed to buy any gTLD for any use. As a result, Google was allowed to buy .dev. They then chose to use it for internal use only.

Unfortunately, the time to oppose this was long ago when gTLDs were first being debated...

So I'm not allowed to disagree with something just because it happened a while ago? I was against it then because of exactly this kind of thing happening. My opinion hasn't changed. But, I guess it should because you say so right?

I see this kind of attitude a lot when it comes to technology "Oh it's already happened just accept it" Or "It's the way everything is so just go along with it"

I'm getting fairly sick of being told I shouldn't disagree with or be against something because"that's the way it is"

Since when has technology ever been about accepting things the way they are? The whole reason we even have an internet is because people decided the way things were weren't good enough.

Of course you're allowed to disagree! Without exception, any person is allowed to disagree with any thing at any time. It's a basic human right.

Whether or not that disagreement can be reasonably expected to have meaningful impact on what many others regard as a decision long made is a different question, and the one to which I was speaking.

That someone wasn't aware, or involved in a process doesn't make their opinion invalid.

I would like to add that clearly, those that was involved in the process have made a less than perfect decision in allowing .dev to be bought by anyone.

It's been in widespread - informal - use for decades, and the decision to allow it to be sold has now directly affected multiple third parties negatively. If one assumes the people involved in the process knowledge in the area of domain names, they knew this but choose to ignore it for no good reason.

TLD's with widespread historical, albeit informal use should absolutely have been reserved.

Being unaware of or uninvolved in a process does not in any way, shape, form, or manner render any person's opinion invalid. I apologize deeply and sincerely from the bottom of my soul for even accidentally creating a situation where such a thing could be interpreted from my words.

With all that said, whether or not one can have a reasonable expectation that one's perfectly valid opinion might have any impact on what many in the outside world regard as a settled matter is perhaps upon occasion a more subtle and complex question.

I appreciate the apology. I have zero expectation on my opinion affecting anything in the world. I'd still like to express it. I don't know the internet is a fairly important thing to me. Being able to freely access anything I wanted really helped me get through a lot of things. I never would have learned a good chunk of the things I know now without it and it's a tool that goes vastly unappreciated by a large majority of the people that rely on it every day. At the same time, large companies slowly take over and lock away large pieces of it or provide it through a narrow lense of whatever they see fit. It makes me sad. So much of the future I used to envision when I was young seems to have been usurped by people who don't understand technology beyond a means to make money. The amount of money spent each day towards nothing more than making more money using technology is fucking ridiculous. Just imagine a world that could be if that money was spent bettering humanity. This decision was not made to better humanity, it detrimented a good number of people working on a huge number of things to benefit a closed group of people beholden to stakeholders.

Every day I read comments, articles and opinion pieces making excuses for companies, entities and individuals stifling innovation for profit and closed environments. The spirit allowing all this technology and innovation to be created seems to be gone and replaced with the same culture of acceptance and worship you find in religions. Technology is supposed to be about benefitting humanity as a whole not private companies.

I don't give a shit how much money a compay has spent on research or investing in whatever. Any company that is large enough to have that kind of impact on the world has only gotten there from money contributed by billions of people around the world. If a company is big enough to have the same kind of influence, or more, on the world as a government they are no different. This world is shifting to some kind of corporate power structure. The largest companies in the world have more power and influence than many nations. These are not private individuals. Whether we like it or not, technology companies, food producers, weapons manufacturers, drug companies, media companies and any other companies that have enough money to buy governments are now the monarchs of this world. Accepting their control over the technology that allows us the small freedoms we have left means we fully accept our new fate as serfs in our modern technolgical oligarchy.

Fuck that. The only freedoms I've had in life come from the internet. The freedom to learn anything I want to communicate anything with anyone I want.

Computers in general. They provide an equalizing power the likes of which have never been seen in history. Every day companies find new ways to lock down or abstract away this technology in the name of security.

If someone doesn't disagree future generations may not know the freedom that comes with being able to host their own platform for data exchange or running code through a compiler and watching something they created come to life. This is something the common man has not had access to throughout most of history. Knowledge, freedom of expression and access to creative tools, were things reserved for the wealthy or those in power. This is a small window in history when commoners have access to the same technology and power of expression as the rich. They are slowly taking this away and no one will notice until it's gone and we're right back where we've been though the rest of history.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact