Google .dev domain early access(domains.google)
domains.google
Google .dev domain early access
https://domains.google/tld/dev/
474 comments
Hi. I'm the Tech Lead of Google Registry, the team that is launching .dev (not to be confused with the linked Google Domains, which is one of many registrars selling .dev domains to end users).
You'll be glad to know that TLDs can't simply be discontinued like other products might be. ICANN doesn't allow it. The procedures in place preventing a live TLD from shutting down are called EBERO; more details here: https://www.icann.org/resources/pages/ebero-2013-04-02-en
The way it works is that all registries must send daily full backups to a third-party escrow provider, which are then used to restore the TLD under a different operator if the original operator shuts down unexpectedly. This is not some theoretical backup/restore procedure that goes untested; it's been used in the past, e.g. with .wed: https://www.icann.org/news/announcement-2017-12-08-en
But this typically only happens when the registry operator goes abruptly bankrupt, and is thus quite rare. Many, many widely used TLDs have been seamlessly sold/transferred across registry operators without you ever realizing it, including .io last year. That would be the "worst" you would expect from TLDs launched by large established players like Google. You actually get a lot more protections with gTLDs than you do with ccTLDs (such as .io), as ccTLDs aren't bound by contract with ICANN and thus aren't forced to do EBERO, or anything else for that matter.
You'll be glad to know that TLDs can't simply be discontinued like other products might be. ICANN doesn't allow it. The procedures in place preventing a live TLD from shutting down are called EBERO; more details here: https://www.icann.org/resources/pages/ebero-2013-04-02-en
The way it works is that all registries must send daily full backups to a third-party escrow provider, which are then used to restore the TLD under a different operator if the original operator shuts down unexpectedly. This is not some theoretical backup/restore procedure that goes untested; it's been used in the past, e.g. with .wed: https://www.icann.org/news/announcement-2017-12-08-en
But this typically only happens when the registry operator goes abruptly bankrupt, and is thus quite rare. Many, many widely used TLDs have been seamlessly sold/transferred across registry operators without you ever realizing it, including .io last year. That would be the "worst" you would expect from TLDs launched by large established players like Google. You actually get a lot more protections with gTLDs than you do with ccTLDs (such as .io), as ccTLDs aren't bound by contract with ICANN and thus aren't forced to do EBERO, or anything else for that matter.
If I register a domain, can google boot me off it at a later year if they don't like my politics? Or do I own the domain with the continuing option to re-register it or transfer to another domain registrar? Does google ultimately own the domains and simply lease them to me with no guaranteed option to continue?
Along those lines, if Google decides I’m a bot or nefarious developer as seems to mistakenly happen on occasion judging from recent hacker news posts, will I then lose my domain name? Or at least access to it? At this point tying any major asset solely to a Google account feels risky.
But don't worry, if a mistake happens, I'm sure you can just call Google's customer service and get it straightened out. Ha!
Paid google products, like google domains, have a 24-hour helpline https://domains.google.com/contactus
I've heard that if you call during the day you get someone who's actually competent, not just some T1 support person.
I've heard that if you call during the day you get someone who's actually competent, not just some T1 support person.
Doesn't matter the level of support, the CEO of Cloudflare was involved and still ended up bringing politics into infrastructure.
Who is a good/trustworthy registrar then?
https://namesilo.com - reliable, cheap & they offer free whois privacy. All they do is sell domains.
I couldn't recommend namesilo more! They almost always have the slowest price, very close to what the registry charges them.
Their UI is dead simple and gets things done well and fast.
Their UI is dead simple and gets things done well and fast.
Amazon Route 53. Full blown registrar.
cloudflare?
Problem with Cloudflare is that their CEO has taken down a domain for political reasons.
While I agree with him taking the domain down, but what about the next CEO?
While I agree with him taking the domain down, but what about the next CEO?
That's just false information. They didn't take any domain down. They stopped offering their CDN/proxying service to a customer. That customer is/was free to host their own content using their own or a different service. No company should be required to offer services to anyone and everyone unless they are the only option on the market. And cloudflare is very far from the only CDN on the market.
Unless I'm thinking of something else, it's not a domain registered through CloudFlare. The taken down site was using CloudFlare's reverse proxy service. IIRC, Matthew wrote about the incident in length.
I personally don't use CF for various reasons, but this site take down is not one of them.
I personally don't use CF for various reasons, but this site take down is not one of them.
The full context here is: https://en.wikipedia.org/wiki/The_Daily_Stormer#Site_hosting...
care to explain this? Thanks
And would I have any way to actually reach a human at Google, aside from media heat from a Reddit/HN/etc front page story?
Probably none, going by the track record.
It really depends on the product. E.g. if you buy Google Wifi, you can call them or chat with customer support, etc. If you need help with constructing a web search query, not so much.
So, please do not over generalize or compare apples to oranges.
So, please do not over generalize or compare apples to oranges.
As a customer, I can't be expected to have a mental model of which Google services come with actual support, and which ones come with Google-it-yourself support.
Comparing Google products to Google products should not be comparing apples to oranges. If Google is frustrated with customers assuming they don't support their products, maybe they should support all of their products, not just a select few.
Comparing Google products to Google products should not be comparing apples to oranges. If Google is frustrated with customers assuming they don't support their products, maybe they should support all of their products, not just a select few.
Ask yourself "Do I pay for this Google product?" If the answer is yes, then the product comes with actual support.
They should quote that on the GMail sign up page.
I am frustrated by Google’s lack of support as anyone else, but it is completely unreasonable to expect support for a free product, regardless of how they might otherwise profit off you.
I'm not frustrated because I don't rely any Google services.
I was serious, though. People would be less frustrated if they had that helpful reminder on sign up.
Obfuscating that GMail isn't a real product is just another one of their sleazy business tactics, I guess.
I was serious, though. People would be less frustrated if they had that helpful reminder on sign up.
Obfuscating that GMail isn't a real product is just another one of their sleazy business tactics, I guess.
You can't say for sure that any new Google product is guaranteed to have horrible customer support, but you probably should assume that any new Google product has horrible customer support until you see proof of the contrary.
Google Fi’s support might be great. But you have to pay for it through Google Payments which is another potential single point of failure. If you ever trip any of their fraud flags you’ll probably never be allowed to pay for anything through google again, and good luck getting it fixed.
https://onemileatatime.com/google-fi-review/
https://onemileatatime.com/google-fi-review/
Sorry, but I reserve the right to be cynic. I belong to the old group of people who got to know Google as "do no evil" company, who tossed that to the wind as soon at it suited them better.
I wouldn't lease the domain through Google domains. Use a different registrar --- if possible, one that you'll be able to trust. That registrar will work with the registry of the TLD, which would be google in this case, and has a much better chance of actually resolving issues than if you were a direct customer of Google Domains.
Now you have two entities who can fuck it up for you instead of just one.
While this is true there are very few reasons why a domain registrar will give you a lifetime ban let alone automatically do it for some perceived TOS crime, let alone refuse to tell you what your alleged misdeed was, let alone automatically reject evidence you submit to the contrary and keep your domains. Imagine the liability!?
Meanwhile someone got their Adsense account banned and in those cases Google refunds the allegedly fraudulent revenue to the advertisers and do not pay you the non-fraudulent revenue. The person who got banned went to court over it because it looked like Google schedules these things to maximize how much they could keep, Google fought for four years to conceal where the non-fraudulent revenue went and then settled for $11 million to keep that shrouded in mystery.
https://www.searchenginejournal.com/adsense-lawsuit/248135/
Note the nobody who will say what happens to your domains when your account is banned despite relevant Google personnel participating in this page, but they have time to detail how we're covered by ICANN if Google with $106+ billion in savings goes bankrupt in thousands of years...
They designed this awful system exactly the way they wanted it to work and they choose to keep it this way, everyone else should probably not use them for domains or web hosting in case yourself or someone associated with your account is irreversibly judged to have committed a TOS transgression somewhere within their empire.
Meanwhile someone got their Adsense account banned and in those cases Google refunds the allegedly fraudulent revenue to the advertisers and do not pay you the non-fraudulent revenue. The person who got banned went to court over it because it looked like Google schedules these things to maximize how much they could keep, Google fought for four years to conceal where the non-fraudulent revenue went and then settled for $11 million to keep that shrouded in mystery.
https://www.searchenginejournal.com/adsense-lawsuit/248135/
Note the nobody who will say what happens to your domains when your account is banned despite relevant Google personnel participating in this page, but they have time to detail how we're covered by ICANN if Google with $106+ billion in savings goes bankrupt in thousands of years...
They designed this awful system exactly the way they wanted it to work and they choose to keep it this way, everyone else should probably not use them for domains or web hosting in case yourself or someone associated with your account is irreversibly judged to have committed a TOS transgression somewhere within their empire.
What registrar would you suggest? I have some on Google but I think I want to transfer now.
I also have some on Namecheap, are those safe?
I also have some on Namecheap, are those safe?
I've been using https://www.hover.com/ for many years and they're great. Mostly because the prices aren't too bad, the dashboard makes sense, and they never contact me.
That's a redundant question, because just about every registry can dictate what their TLDs can be used for. It's part of the design laid down by ICANN.
- For Verisign with .com, they don't care if you're really a company or not.
- With Minds & Machines and .law, they only want qualified lawyers, courts, legal schools, etc. using the TLD.
Keep in mind that the registry and registrar are different things.
- For Verisign with .com, they don't care if you're really a company or not.
- With Minds & Machines and .law, they only want qualified lawyers, courts, legal schools, etc. using the TLD.
Keep in mind that the registry and registrar are different things.
I think the difference is that Google boots folks off YouTube for political purposes while VeriSign does not kick people away from their .com.
Godaddy banned Gab for political reasons as well. While you can split hairs and say that's just a registrar, you can also split hairs and say that youtube is just a hosted content platform. If you're thinking of running another infowars then I would advise avoiding registering domains with any major tech platform in general.
@bduerst,
Forgive my ignorance, but just to distill it down to brass tacks:
In this case, Google is the registry and thus the supreme court of who can and cannot be on this domain and there is no recourse if they yank your claim on the domain?
Is it more nuanced than that?
In this case, Google is the registry and thus the supreme court of who can and cannot be on this domain and there is no recourse if they yank your claim on the domain?
Is it more nuanced than that?
I mean, the entire domain name infrastructure is set up so that someone along the path can revoke registrations, all the way up to ICANN itself.
IME you're much more likely to be banned by the registrar than the registry itself. Registries want people to use their TLDs, so they're not going to reject post-registration unless you've changed how you're using the TLD and it's violating the rules they originally laid down. Registrars are much more consumer facing and will act accordingly - i.e. GoDaddy banning Gab.
IME you're much more likely to be banned by the registrar than the registry itself. Registries want people to use their TLDs, so they're not going to reject post-registration unless you've changed how you're using the TLD and it's violating the rules they originally laid down. Registrars are much more consumer facing and will act accordingly - i.e. GoDaddy banning Gab.
Google has a track record of being capricious with bans, whereas other companies do not.
And just like that, the 'Tech Lead of Google Registry' has fallen silent.
[deleted]
You talk about the protections ICANN gives your customers in case Google goes bankrupt, but what are the protections or recourse your registry or Google Domains created for your customers to ensure recoverable domains and unimpeded uptime if their Google account is banned?
What prevents Google from charging an absurd rate like some of the other TLD or other practices that effectively change the service?
The trend across the gTLD industry has been one of decreasing prices, not increasing prices. I'm not sure what you're referring to?
i guess he is talking about the premium domains:
> During both the Early Access Program and General Availability, there is a $12/year cost for .dev domains. Annual fees may vary for Premium domains.
> During both the Early Access Program and General Availability, there is a $12/year cost for .dev domains. Annual fees may vary for Premium domains.
"Premium" domains are resold domains. The prices are typically dictated by the person holding them.
Premium prices are set at the registry level, and for Google's TLDs, are charged annually. The EAP fee is a one time only up-front cost.
Domains being sold by resellers are something different entirely, but yeah, some registrars that participate in reseller networks may lump those in as "premium" as well, which is confusing. Those prices tend to be one-time acquisition costs.
Domains being sold by resellers are something different entirely, but yeah, some registrars that participate in reseller networks may lump those in as "premium" as well, which is confusing. Those prices tend to be one-time acquisition costs.
Because this is your area of expertise, can I ask you why more registrars are not selling 10 or 20 year domain ownership? Who wants a domain for just a year (if you agree with the premise behind individuals owning domains in the first place)?
If I could buy a domain for 50 years, I'd do it.
If I could buy a domain for 50 years, I'd do it.
Most TLDs allow registration lengths up to 10 years. And registrars will happily sell you registration for 10 years. Buy the domain, then immediately renew it for 9 years. I suspect the reason they don't offer a choice of registration years in the initial checkout flow is to reduce purchasing friction -- they don't want you to have to make another choice and then potentially back out of the sale. It's the same reason e-commerce sites will ask you for as little information as they can get away with when checking out your cart; for digital sales many retailers just do zip code instead of full address since they're not shipping anything.
As for longer registration periods than that, I suspect it's the same reason you can't, e.g., call up your cable company and try to pre-pay 50 years of service. They have no idea what things will be like that far down the road, and they don't want to have such longstanding obligations weighing on them.
It comes down to business decisions, not technical issues; technically speaking the spec allows for up to a 99 year registration period, though I'm not aware of any TLDs that support that. https://tools.ietf.org/html/rfc5731#section-2.5
As for longer registration periods than that, I suspect it's the same reason you can't, e.g., call up your cable company and try to pre-pay 50 years of service. They have no idea what things will be like that far down the road, and they don't want to have such longstanding obligations weighing on them.
It comes down to business decisions, not technical issues; technically speaking the spec allows for up to a 99 year registration period, though I'm not aware of any TLDs that support that. https://tools.ietf.org/html/rfc5731#section-2.5
I recently read an HN thread about Romanian ccTLD registry selling domains for lifetime. They have stopped it and asked the former customers to pay up though.
And also ccTLDs can make up whatever rules they want, whereas gTLDs are all bound by the same common set of rules. There are many ccTLDs that don't even use EPP (the spec I linked to above).
We already have enough sleazy domain squatters holding names for years and trading for ridiculous prices. Instead of long ownerships, we should have some way to prove you're actually using the domain after a certain number of years.
I disagree. At the end of the day, they are still vanity domain names. Adding more paperwork and process doesn't change that.
For example, pitch a solution that doesn't just make squatters upload some bare bones index.html. Or check a registrar's checkbox to park the domain somewhere with content. Or, well, upload the minimum amount of substance that you think is necessary.
For example, pitch a solution that doesn't just make squatters upload some bare bones index.html. Or check a registrar's checkbox to park the domain somewhere with content. Or, well, upload the minimum amount of substance that you think is necessary.
Think about how you could possibly design such a program to ensure use, and how you'd prevent parking site services from cropping up that would make a site just meet the requirements for continuing registration. And if it's not a purely automated process, then the base registration price would have to go way up to pay for all the human work going into validations.
And now imagine the public outcry that can happen every time people have their domains taken from them (rightly or wrongly).
No, no registry wants to be in the business of doing that. You continue to pay for the name, it's yours.
And now imagine the public outcry that can happen every time people have their domains taken from them (rightly or wrongly).
No, no registry wants to be in the business of doing that. You continue to pay for the name, it's yours.
We should stop calling organisations who hog domains in order to accrue an exaggerated profit from them "domain squatters". A real "domain squatter" should be someone who employs the "domain hogger's" domain until the domain hogger decides to actually do something with it themselves.
We wouldn't need such a profusion of TLDs (most of which are awful: .dev is an exception) if real domain squatting was made feasible.
We wouldn't need such a profusion of TLDs (most of which are awful: .dev is an exception) if real domain squatting was made feasible.
The biggest problem with squatters is that they pay 100x less then you do for a domain. If they had to pay the same price they would squat on way less domains.
Many of the new TLDs do their own domain squatting. Short, pronounceable domain names are flagged as "premium", and sold at a higher price.
It's a nifty business hack actually, as unlike a 3rd party squatter, the TLD itself has no financial risk in upmarking domains.
It's a nifty business hack actually, as unlike a 3rd party squatter, the TLD itself has no financial risk in upmarking domains.
The trend in browsers is being precise about standards and yet only yesterday google took an existing standard and tried to corrupt it.
I'm not trying to be snarky and thanks foe answering questions but this particular comment was a non-answer.
I'm not trying to be snarky and thanks foe answering questions but this particular comment was a non-answer.
It sounded like they were referring to something specific, but didn't provide examples. I want to know exactly what they're worried about so that I can answer the question, but I haven't been given enough to go on. It sounds like they're worried about prices being jacked up by large amounts, but I'm not aware of that even having happened. Absent that, the current prices are what they are; pay them or don't, but you know what you're getting into.
I think they might be referring to Chrome's upcoming use of &targetText= for linking to specific words or paragraphs, which caused some controversy here yesterday. See:
https://news.ycombinator.com/item?id=19168442
https://news.ycombinator.com/item?id=19168442
I doubt that's it.
Yet here I am about to lose my .eu domain, because of Brexit. I'm paid up for 10 years, but the EU can just change the rules, and I lose my domain.
[deleted]
[deleted]
[deleted]
[deleted]
> Hi. I'm the Tech Lead of Google Registry, the team that is launching .dev
/remindme! 2 years
/remindme! 2 years
Hi, just wanted to say how absolutely horrid this entire idea is. Domain name squatting and auctioning is already bad enough, and you're telling me we should give one of the richest companies in the world thousands of dollars for a domain name for development. This is completely counter to the spirit of the internet, and spits in the face of open source and passionate hobby developers who don't have silicon valley stock vesting every quarter. Instead of trying to get these domain names into the hands of real developers at a reasonable price, you're going to sell them to the highest bidders, squatters looking for new investments, and corporations.
Really not at all impressed by this, and it only serves as a stark reminder of the failed state of TLDs.
Really not at all impressed by this, and it only serves as a stark reminder of the failed state of TLDs.
I don't understand the bile here, nor the alternative. Today there are no .dev domains, so anything is an improvement: today you can't use them, tomorrow you can choose to if you think it makes sense.
Re: price, say the .dev registrar decides to offer domains for a hobby-dev-friendly $1 flat fee, first come first served. Wouldn't that just immediately lead to a resale market where predatory squatters register all the domains and extract the market price from anybody who wants one?
Re: price, say the .dev registrar decides to offer domains for a hobby-dev-friendly $1 flat fee, first come first served. Wouldn't that just immediately lead to a resale market where predatory squatters register all the domains and extract the market price from anybody who wants one?
I think it’s not cool to offer “early bird” registration for thousands of dollars. So Google is endorsing that rich developers should get the best domain names? How are they reserving for themself?
I think it would be cooler to have programming challenges or something neat.
But a cash grab just seems kind of, lame I guess.
I wouldn’t say I have bile, but I went from “this might be cool” reading the headline to “this is really stupid.”
I think it would be cooler to have programming challenges or something neat.
But a cash grab just seems kind of, lame I guess.
I wouldn’t say I have bile, but I went from “this might be cool” reading the headline to “this is really stupid.”
But if you don't think the dutch auction style is a good one, what would your alternative be?
Because the problem of resellers buying up TONS of domain names is a real one, and thus far a dutch auction style seems to be one good way to combat that (since buying 10000 names and selling 10% of them for an overall profit is a LOT more risky when getting them first means shelling out a LOT more money).
A challenge or something would probably drive costs up across the board, and it would still exclude those who want to use the domains that might not be able to complete the challenge (IMO a worse situation), and other methods of "verification" would either be gameable or would exclude many devs.
I don't know of any more "fair" way of allowing people to buy domains. Why should a hobbyist be able to buy "paypal.dev" when potentially thousands of devs could use that domain at paypal, and similarly "klathmon.dev" would be awesome to have for me, and it's pretty unlikely that someone will buy that out from under me with this scheme.
Not to mention that the timeline here is literally half a month. After Feb 28th, there is no additional charge. So we are talking about 2 weeks of waiting.
Because the problem of resellers buying up TONS of domain names is a real one, and thus far a dutch auction style seems to be one good way to combat that (since buying 10000 names and selling 10% of them for an overall profit is a LOT more risky when getting them first means shelling out a LOT more money).
A challenge or something would probably drive costs up across the board, and it would still exclude those who want to use the domains that might not be able to complete the challenge (IMO a worse situation), and other methods of "verification" would either be gameable or would exclude many devs.
I don't know of any more "fair" way of allowing people to buy domains. Why should a hobbyist be able to buy "paypal.dev" when potentially thousands of devs could use that domain at paypal, and similarly "klathmon.dev" would be awesome to have for me, and it's pretty unlikely that someone will buy that out from under me with this scheme.
Not to mention that the timeline here is literally half a month. After Feb 28th, there is no additional charge. So we are talking about 2 weeks of waiting.
In an idealized economic model, "rich developers" will get their desired domain names anyway as they can offer a large sum of money to the "poor developers" to give up their domain name.
https://en.wikipedia.org/wiki/Coase_theorem
https://en.wikipedia.org/wiki/Coase_theorem
[deleted]
I can't tell if your argument is that we should artificially limit TLDs to increase competition? Is that the point you are making?
Literally: "We will create monopolies and increase competition."
Unbelievable.
Literally: "We will create monopolies and increase competition."
Unbelievable.
I think the risk isn't that they become your competitor, it's that an algorithm flags your website for perceived abuse and that cascades down to you and your workplace being banned forever from Google, with no recourse because they choose to provide fake support despite having $100+ billion in savings and plenty of funding for eg global tax evasion.
It's risk management through diversification attempts. Google, like any other large scale extremely successful single product[1] company, hedges market risks in occupying "hot" spaces. Same with MS, Apple and all other giants, even in non-tech.
[1] see financial report of the last year (10K). Search for "We operate our business in multiple operating segments. Google is our only reportable segment. None of our other segments meet the quantitative thresholds to qualify as reportable segments" and "How we make money" (Source: https://www.sec.gov/Archives/edgar/data/1652044/000165204419... )
[1] see financial report of the last year (10K). Search for "We operate our business in multiple operating segments. Google is our only reportable segment. None of our other segments meet the quantitative thresholds to qualify as reportable segments" and "How we make money" (Source: https://www.sec.gov/Archives/edgar/data/1652044/000165204419... )
It's kind of amazing that after all this time, they haven't created anything worth reporting outside of the add business.
Youtube, maps, phones?
Youtube - money loser
Maps - money loser (but we will see after their recent huge price increases shake out)
Phones - money loser. they are selling fewer phones annually than apple sells in a week.
Is Youtube really a money loser? I thought they'd turned it profitable years ago.
Maps - in flux like you said.
Phones are more than hardware sales. They also run an app store and license their own ecosystem.
Maps - in flux like you said.
Phones are more than hardware sales. They also run an app store and license their own ecosystem.
Acquired, acquired, acquired.
Originally, perhaps. But in the last ten years how many times have these platforms been rewritten?
Hosted services like Drive, Photos, and GSuite are also entirely in-house.
Hosted services like Drive, Photos, and GSuite are also entirely in-house.
In any other area that would be a red flag of “money laundering”.
I am not accusing them of it. Just stating facts.
I am not accusing them of it. Just stating facts.
You made a fully general argument against anything that Google touches.
This isn't useful, because everyone knows that argument already. I'd rather know what Google's track record is specifically having to do with DNS (or fundamental Internet infrastructure).
This isn't useful, because everyone knows that argument already. I'd rather know what Google's track record is specifically having to do with DNS (or fundamental Internet infrastructure).
I think their 8.8.8.8 DNS server has a pretty impressive track record for I think over 10 years. I know many people who changed their dns to 8.8.8.8 when they thought their DNS was shitty.
Back in highschool (15yrs ago) pinging a DNS server was something I sometimes did when fixing people's internet, always used 212.142.28.66. No idea why it's still in my head so much later, 8.8.8.8 sure is a lot easier to remember.
Back in highschool (15yrs ago) pinging a DNS server was something I sometimes did when fixing people's internet, always used 212.142.28.66. No idea why it's still in my head so much later, 8.8.8.8 sure is a lot easier to remember.
And so is 1.1.1.1
Which is cloudflare's IP, to be clear. I'm a fan, but I like transparency.
1.1 is even easier (1.0.0.1)
Remembering two distinct numbers is harder than remembering one distinct number
You misunderstand, `1.1` _is_ `1.0.0.1`, there are multiple ways to represent IP addresses.
If I had to bet, the majority of .dev pages will be engineers posting their portfolio, not startups building developer tools.
Github.com/devname is way better than devname.dev
Can't agree with that. Taking a minimal amount of time and effort to host your own site on a TLD shows, at least, a moderate understanding of DNS and all that, much more than clicking things on Github Pages IMO.
If your github profile is your resume, yes it is.
But it not so good if your resume contains other things.
Haha. I totally agree. As a shareholder, I almost feel like an activist campaign is needed. Sure, Verily and Waymo are interesting moonshots, but then the rollout of Youtube Plus or Premium seems like the most mismanaged rollout of a big tech company outside of the Amazon phone. Why is Google bothering with domain registry is a good question. Google code probably could have been what GitHub had it not been abandoned is another example of mismanaging product or service vision.
> ... might decide to randomly become your competitor in 2 years
think of the bright side. they might be willing to buy your neato .dev domain name back ... for $12.
think of the bright side. they might be willing to buy your neato .dev domain name back ... for $12.
To be honest, TLD business is probably not one of them.
Even fi google becomes your competitor, they won't touch the domain.
A while ago, some posts on HN went around saying that you shouldn't use third-world TLDs for your startup because some of them are unreliable stewards who would put your domain at risk. Does registering a .dev domain make you dependent on Google in the same way that registering a .ly makes you dependent on Libya?
There was this one guy who lost a valuable Twitter handle due to him using his custom domain email (via GoDaddy) as a login email.[0] I'd like to think imagine Google is better than GoDaddy when it comes to security and fighting social-engineering attacks but who knows. But if Google is a weak link wouldn't that also mean all our gmails are not as safe as we think?
[0] https://medium.com/@N/how-i-lost-my-50-000-twitter-username-...
[0] https://medium.com/@N/how-i-lost-my-50-000-twitter-username-...
I'd say Google would be one of the most resistant organizations to social engineering by virtue of the fact that you can never really talk to an actual human even if you are a legit user and want help on an issue.
I don't really understand the worry here though. Aren't you always trusting your registrar when you buy a domain name? Google at least has a pretty solid track recordin wrt security.
I hate to be that guy, but I honestly hope you don't make decisions based on anecdotes, and instead rely on data.
You are dependent on your vendors, period. Choose them wisely. This is not a mystery.
You are dependent on your vendors, period. Choose them wisely. This is not a mystery.
>You are dependent on your vendors, period.
You aren't dependent on your vendors if you can switch them out without destroying your company. The real mystery is why people turn their own businesses in to little barnacles on the skin of behemoths and expect to not get brushed off.
You aren't dependent on your vendors if you can switch them out without destroying your company. The real mystery is why people turn their own businesses in to little barnacles on the skin of behemoths and expect to not get brushed off.
The short answer is that yes, this domain is administered by Google through a holding entity. See https://www.iana.org/domains/root/db/dev.html
It’s a good question. Does anyone know who legally owns the domain and what responsibility google has to ensure you can use the TLD in perpetuity?
Names in the DNS aren't personal property (and they certainly aren't real property). So "owns" is probably the wrong word.
But ICANN, which is responsible for the entire hierarchy, expected that eventually at least some of the new gTLD registry operators would fail, and so there is an escrow agreement for each one. If the gTLD is popular enough that somebody else will operate it, the last daily backup from escrow is given to the new operator and things continue from there. I guess your new registry operator may set fees or other conditions your current registrar doesn't like, but if you like the new you can move to a registrar that's OK with them. The list of names in the registry doesn't vanish unless both your registry AND the third party escrow company screw up.
If the gTLD is grossly unpopular, it may not be possible to find a new operator for that gTLD registry. I don't know what happens in that case, although whatever it is by definition won't happen to many names.
I also don't know what happens for the very stupid gTLDs that are essentially for private use by a single organisation, like .kerrylogistics. And I don't really care, so long as the fees roll in to pay for everything. Actually I'd have billed them for their original request, .kerrylogisitics [sic] as well, but I guess someone felt that was too mean.
But ICANN, which is responsible for the entire hierarchy, expected that eventually at least some of the new gTLD registry operators would fail, and so there is an escrow agreement for each one. If the gTLD is popular enough that somebody else will operate it, the last daily backup from escrow is given to the new operator and things continue from there. I guess your new registry operator may set fees or other conditions your current registrar doesn't like, but if you like the new you can move to a registrar that's OK with them. The list of names in the registry doesn't vanish unless both your registry AND the third party escrow company screw up.
If the gTLD is grossly unpopular, it may not be possible to find a new operator for that gTLD registry. I don't know what happens in that case, although whatever it is by definition won't happen to many names.
I also don't know what happens for the very stupid gTLDs that are essentially for private use by a single organisation, like .kerrylogistics. And I don't really care, so long as the fees roll in to pay for everything. Actually I'd have billed them for their original request, .kerrylogisitics [sic] as well, but I guess someone felt that was too mean.
"ICANN requires all registrars and gTLD registries to contract with a data escrow provider in order to safeguard registrants ... in case of registry or registrar failure, accreditation termination, or accreditation relapse without renewal." Basically if Google screws up then ICANN will give the data to someone competent who will take over the domain. https://icannwiki.org/Data_Escrow
[deleted]
I trust Google a heck more (to stay around and honor contracts) than I trust Libya.
,,.dev lets your clients know what you do before they even open your site.''
I hate the new trend of companies having multiple domains with different TLDs, as I never know this way if it's the same company or not.
I hate the new trend of companies having multiple domains with different TLDs, as I never know this way if it's the same company or not.
I'm in favour of this trend for this very reason. One should never implicitly assume you know it's the company you expect in any case.
That’s a bit of a stretch, not? If I visit dev.somesite.com, I can reasonably assume it belongs to the same owner as somesite.com. The same can not be said about somesite.dev.
Not sure I understand the point here, you're comparing subdomains to TLDs?
Yes because not everyone understands x.y.z and y.x are not owned by same person.
Should we design standards for the dumbest of the lot lol? Not everyone understand that TLD is then maybe they should be educated rather than appeased to.
Also it seems to be primarily USA's issue. Every other nation uses their domain for internal websites (like cats.de) where's Americans tend to just clump everything in `.com` and act all confused by simple TLD scheme.
Also it seems to be primarily USA's issue. Every other nation uses their domain for internal websites (like cats.de) where's Americans tend to just clump everything in `.com` and act all confused by simple TLD scheme.
I don't think a person qualifies as "dumbest" because they do not know what a TLD is. Not everyone has to understand everything else in the world to be a human and use it. Not everyone knows how to be a mechanic but lots drive vehicles and fly in planes.
The issue with your generalization of America is flawed. The internet started in America so "we" clumped everything into .com because we could. TLDs for countries came as a way to organize and route better. A German requesting amazon.com, should goto amazon.de. (This all happened before amazon and CDNs and other things.)
It is ignorant to think a fundamental concept of domain resolution, TLDs is something everyone should understand to use the internet. Do you know how your cell provider takes a request to dial a number and resolve it to another person across towers and potentially hard wired cabling? Most don't and they all make calls.
The issue with your generalization of America is flawed. The internet started in America so "we" clumped everything into .com because we could. TLDs for countries came as a way to organize and route better. A German requesting amazon.com, should goto amazon.de. (This all happened before amazon and CDNs and other things.)
It is ignorant to think a fundamental concept of domain resolution, TLDs is something everyone should understand to use the internet. Do you know how your cell provider takes a request to dial a number and resolve it to another person across towers and potentially hard wired cabling? Most don't and they all make calls.
In this particular instance at least, .dev is targeting developers, who do tend to know these things.
“Don’t you guys have phones?”
Compare and contrast whitehouse.gov and whitehouse.com
A company owning whitehouse.com and a government entity owning whitehouse.gov? I'd call that working as intended.
The .com used to be a porn website, in the 90s. That might have been working as intended, but has surprised quite a few people.
And the original discussion was someone claiming that having different TLDs were superior to subdomains for maintaining identify.
My point was more about the assumption about who owns somesite.com. Assuming two domains are owned by the same company is a somewhat secondary concern to authenticating the owner of either; both of which are larger issues in their own right.
As commented by someone else, see e.g. whitehouse.com. The fact of whitehouse.gov being a different owner is much less of concern than that of whitehouse.com not having the expected owner in the first place (from the perspective of most visitors).
As commented by someone else, see e.g. whitehouse.com. The fact of whitehouse.gov being a different owner is much less of concern than that of whitehouse.com not having the expected owner in the first place (from the perspective of most visitors).
> You can purchase an SSL certificate through one of our web partners or a Certificate Authority. Read this article to learn more.
Really? No mention of Lets Encrypt? Does anyone still buy certificates nowadays, especially for dev sites?
Really? No mention of Lets Encrypt? Does anyone still buy certificates nowadays, especially for dev sites?
They explicitly mention letsencrypt as a free provider when you click the "Read this article" link.
It's not like they made any effort to make it visible, though. And "purchase" implies that the options they present are non-free.
Which is interesting, I would expect Google to promote Lets Encrypt... Or do they assume devs already know about it?
Which is interesting, I would expect Google to promote Lets Encrypt... Or do they assume devs already know about it?
They probably don't want to cause ill will by being partial to a particular CA, even if they're supporting it.
Of course they do.
Let's Encrypt provides DV (Domain Validation). Not OV (Organization Validation).
Obviously .dev is intended for software development and most domains there would probably be using DV only so this might not apply to it, though.
Let's Encrypt provides DV (Domain Validation). Not OV (Organization Validation).
Obviously .dev is intended for software development and most domains there would probably be using DV only so this might not apply to it, though.
OV is useless. No consumers look at it. It’s just a sad attempt for CAs to trick people into paying for something they don’t need.
[deleted]
Do you even use Amazon or Internet banking?
It might sound useless for those who doesn't know what it is.
However, for those who does it is very useful and getting more useful.
Browsers might (if not yet, coming soon to you) raise red flags if you try to use a website whose certificate was signed by a rogue CA that, according to DNS instructions, shouldn't be able to do so for that domain.
Browsers might demand OV from high profile websites in theory.
etc, etc, etc.
Maybe we are
It might sound useless for those who doesn't know what it is.
However, for those who does it is very useful and getting more useful.
Browsers might (if not yet, coming soon to you) raise red flags if you try to use a website whose certificate was signed by a rogue CA that, according to DNS instructions, shouldn't be able to do so for that domain.
Browsers might demand OV from high profile websites in theory.
etc, etc, etc.
Maybe we are
Seeing the organisation name next to the lock icon definitely gives me an extra layer of warm and fuzzy feelings. I’d say it has some value for those that can pay for it.
You are talking about EV certificates. OV-validated certificates require (the best case) the user to click on the padlock icon to reveal more information about the certificate.
Not all certificates are created equal
> Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
> Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
I buy them. I don't like paying for them, but I want a certificate I know will just work for years without having to run certbot or one of its clones on my server. Well, that and LE didn't yet allow wildcard certs when I bought mine. They've already dropped their maximum validity from three to two years though, so I'll probably throw in the towel when they further reduce their validity to less than six months.
Let's Encrypt certs are valid for 90 days.
There are 2 reasons: 1. To limit damage from key compromise and mis-issuance 2. To encourage automation.
What is the issue with running the certbot on your server? It's not like you have to run it manually.
Here are official reasons: https://letsencrypt.org/2015/11/09/why-90-days.html
P.S. Wildcard certs are available for almost a year now: https://community.letsencrypt.org/t/acme-v2-production-envir...
There are 2 reasons: 1. To limit damage from key compromise and mis-issuance 2. To encourage automation.
What is the issue with running the certbot on your server? It's not like you have to run it manually.
Here are official reasons: https://letsencrypt.org/2015/11/09/why-90-days.html
P.S. Wildcard certs are available for almost a year now: https://community.letsencrypt.org/t/acme-v2-production-envir...
[deleted]
The issue might be executing 3rd party code on a server.
ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust.
We actually did our own DNS-based implementation for our infrastructure.
I don't want to run someone else's code on my server just for this (the default certbot wants root access too, yikes), nor do I want to analyze someone else's implementation before running their code, and I sure as heck don't have the time, patience, or interest to write my own implementation of ACME just for the one service that uses it.
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.
Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.
Take a look at https://github.com/joohoi/acme-dns/ (which of course still requires trust in the client lib)
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
ACME protocol is fairly straight forward to implement, and you can easily write your own implementation with existing code (OpenSSL, Apache/nginx, etc).
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.
I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.
Well that's nice. But that mean you'll have to manually buy, upgrade install and test them. I have better things to do.
Takes about 5 minutes of time. It really isn't a big deal.
A certificate that last for years... That's exactly how you end up with a certificate that expired and no one realized. An automated process is a way more reliable.
Until the automated process breaks. I've encountered more "invalid certificate" warnings on Let's Encrypt sites than any others.
This "early-access" price which decreases over time is an approximation of a Dutch auction: https://en.wikipedia.org/wiki/Dutch_auction
Dutch auctions are incentive-compatible - they allocate the resource to the person that gains the highest utility for having it. Maybe Google got some of the people working on ads auctions to design this pricing structure.
Dutch auctions are incentive-compatible - they allocate the resource to the person that gains the highest utility for having it. Maybe Google got some of the people working on ads auctions to design this pricing structure.
I’m, that’s an icann rule for launching new tlds. The early access period is always higher, then there are several other periods that happen before a tld gets to General availability.
This pricing structure is not just for .dev domains.
This pricing structure is not just for .dev domains.
FYI, there is no ICANN requirement that any sort of auction be involved in launching a new TLD. We used to use a standard auction (called the landrush phase in TLD parlance), but have since switched over to a descending price Dutch auction because it's significantly less operational burden for us.
It's generally a good idea to have some kind of auction for the reasons the parent comment mentions, as it is a more economically efficient way to allocate the limited namespace to those who want it the most.
It's generally a good idea to have some kind of auction for the reasons the parent comment mentions, as it is a more economically efficient way to allocate the limited namespace to those who want it the most.
I think you forgot to suffix that speech with "you peasant."
Google has a long history with the Dutch auction, they used it in their IPO, back in '04.
I remember people calling that a bit of a fiasco... was there anything theoretically wrong with the application of a Dutch auction for that purpose, or was it just that the underwriting community and their clients had every reason to make the situation look bad?
The price basically ended up being set by the underwriters because they big players bought most of the shares and bid at the price they underwriters told them to bid at. It wasn't really a fiasco, it just didn't accomplish what they wanted.
Thank you for mentioning this. Memories are increasingly short, and this is nothing new!
Or companies that value the $100-10k for the early registration fee so little that it's a drop in the bucket compared to individuals.
I'd like to have a very short domain personally but it's hard to anticipate what the demand will be like here.
I'd like to have a very short domain personally but it's hard to anticipate what the demand will be like here.
Yeah, there are domain names out there that are so valuable that they've sold for eight figures USD. There definitely are domains that buyers (typically companies) are willing to spend well over $10k on acquiring. It's with this in mind that the EAP prices are set.
> they allocate the resource to the person that gains the highest utility for having it
I don’t think that’s necessarily true. Any large company is able to drop a ton of money on something that has marginal utility for them, whereas a small business that would gain much more utility from it may be outbid just by virtue of having the wrong opponents.
I don’t think that’s necessarily true. Any large company is able to drop a ton of money on something that has marginal utility for them, whereas a small business that would gain much more utility from it may be outbid just by virtue of having the wrong opponents.
This assumes bidders have similar amounts of money to spend on domains, which may or may not true for any particular domain.
We can say that, when bidders do have similar bankrolls, whoever wants the domain the most is likely to buy it first. If they don't, whoever has the bigger bankroll will probably be able to buy it first.
We can say that, when bidders do have similar bankrolls, whoever wants the domain the most is likely to buy it first. If they don't, whoever has the bigger bankroll will probably be able to buy it first.
I reserved unix.dev for the regular domain reservation price, not the crazy "premium domain" price because unix.dev was not part of the premium domain list.
However, Google determined that no, unix.dev should be a premium domain, and "stole" the reservation from me (after I have already paid for it). They later added it to the premium domain list, and they asked me for $11k to keep the reservation.
TBH, I expected to lose the domain because of trademarks or whatever, but apparently it was simple highway robbery.
Btw, I didn't even get my money back, just "store credit".
However, Google determined that no, unix.dev should be a premium domain, and "stole" the reservation from me (after I have already paid for it). They later added it to the premium domain list, and they asked me for $11k to keep the reservation.
TBH, I expected to lose the domain because of trademarks or whatever, but apparently it was simple highway robbery.
Btw, I didn't even get my money back, just "store credit".
Hey, I just want to correct some misunderstandings here.
"Reservations" mean nothing. Google Domains is merely one of many registrars that have customers all vying for domains in the same namespace. A "reservation" just means that the registrar will make their best effort to attempt to get that domain for you at the specified price; it doesn't mean that some other registrar won't get it first, or that some other customer isn't willing to spend more and will get it on an earlier day of EAP.
Until the domain is actually created with you as the registrant, it isn't yours in any sense of the word. There are even registrars out there that will, upon acquiring a domain, auction it off amongst all of their customers who pre-registered it.
"Reservations" mean nothing. Google Domains is merely one of many registrars that have customers all vying for domains in the same namespace. A "reservation" just means that the registrar will make their best effort to attempt to get that domain for you at the specified price; it doesn't mean that some other registrar won't get it first, or that some other customer isn't willing to spend more and will get it on an earlier day of EAP.
Until the domain is actually created with you as the registrant, it isn't yours in any sense of the word. There are even registrars out there that will, upon acquiring a domain, auction it off amongst all of their customers who pre-registered it.
And what were you going to do with unix.dev, if I may ask?
There are quite a few Russian lastnames that end ”dev”, like Medvedev. I think there is going to be quite a rush for these.
120KB of javascript and still the accordion doesn't open on OSX Safari.
I recently found out that the sidebar menus on pages within https://developers.google.com/web don't work with JS off (usually a trivial thing: show sub-items by default and hide them with JS). Almost every Alphabet website has something like that.
So yes, minor anecdote, and I genuinely appreciate the hundreds of Google employees who really help the Web and share useful knowledge (and don't lead developers into using techniques best suited for billion-user websites, as FB often does) but I'll reserve to right to side-eye anything Google says.
So yes, minor anecdote, and I genuinely appreciate the hundreds of Google employees who really help the Web and share useful knowledge (and don't lead developers into using techniques best suited for billion-user websites, as FB often does) but I'll reserve to right to side-eye anything Google says.
Also the site claims to about “web fundamentals”, but the content pushed out are all articles about cutting edge, experimental features in Chrome. There’s nothing wrong with documenting new features in your browser, but calling it fundamental is fundamentally misleading.
Not working with JS disabled is bad, but not working on a major modern browser is ridiculous.
Safari is the new IE8.
Every web dev I know bitches about it.
Every web dev I know bitches about it.
It's not. I'm a web developer and it's my browser of choice.
Every bad web dev bitches about it.
There's nothing about Safari that makes it "the new IE8". Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
There's nothing about Safari that makes it "the new IE8". Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.
HN is quite diverse and I'm pretty sure those are two disjoint sets of users. (I'm in the former group myself --- not a fan of presenting information in such a way as to decrease its accessibility while also increasing resource usage.)
I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it... but no, most "modern web devs" would rather pile on the bloat of their libraries and "best practices" to make something that works only in the very latest version of the one browser they personally use.
HN is quite diverse and I'm pretty sure those are two disjoint sets of users. (I'm in the former group myself --- not a fan of presenting information in such a way as to decrease its accessibility while also increasing resource usage.)
I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it... but no, most "modern web devs" would rather pile on the bloat of their libraries and "best practices" to make something that works only in the very latest version of the one browser they personally use.
> I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it.
<summary>/<details> tags with JS polyfill is all you'd need.
https://caniuse.com/#search=summary
<summary>/<details> tags with JS polyfill is all you'd need.
https://caniuse.com/#search=summary
Your post shows the big difference in mentality that's partly responsible for why we see so many broken sites --- I haven't ever used those tags before and would just go for plain old DOM style manipulation with JS (which has been around for a very long time), whereas you started with something much newer and took backwards-compatibility as an afterthought to be added on. Your solution requires less initial effort (providing you knew about the new tags) but then additional effort to work on older browsers --- that might not even be done --- whereas my solution may take a little more effort initially, but then naturally doesn't need any further considerations for backwards-compatibility.
My mentality is to make the website usable without JS for most people (with the reasonable effort of installing FF or Chrome at most), then use as simple and compatible JS as possible if needed. Thus, old-style DOM fiddling isn't the first choice - and if we're talking very old browsers, it was also tricky to get right due to all the incompatibilities.
Why you think something would be broken when a polyfill is used as fallback, I don't know.
Why you think something would be broken when a polyfill is used as fallback, I don't know.
Why would anyone use an older browser? (Other than IE in old firms - but this is probably becoming rarer and rarer) I guess everyone should upgrade their browser regularly, at least to get security upgrades
It's not so much jumping on new things, it's implementing accepted features which has slowed down very considerably since the Blink fork.
Google was really carrying a big part of the webkit development.
Google was really carrying a big part of the webkit development.
> it's implementing accepted features
Define "accepted". Hastily implemented and shoved down everyone's throat by Chrome doesn't mean "accepted".
> Google was really carrying a big part of the webkit development.
Nope. Google is dominating the development space with utter disregard for public/dev opinion.
Define "accepted". Hastily implemented and shoved down everyone's throat by Chrome doesn't mean "accepted".
> Google was really carrying a big part of the webkit development.
Nope. Google is dominating the development space with utter disregard for public/dev opinion.
It's support for video codecs is pretty limited, and has been for a long time, but I think you're right about most of the other things being very new "standards".
It's annoying that it throws exceptions when you try to access LocalStorage in Private Browsing.
And, hilariously, iOS Chrome, because it uses the same renderer as Safari.
Also, the navigation and some other parts aren't usable with ad blocker enabled, since there are no non-JS links/anchors. Embarrassing for an entity that once tried to position itself as a supporter of usability and user-friendly web pages.
If you're not supporting their ad business, you don't matter to them.
You may get a kick out of this...
Google Support
<SUPPORT_PERSON>12:53 PM Thank you for contacting Google Domains. My name is <SUPPORT_PERSON> and I'll be happy to assist you. Let me quickly read your notes here.
<SUPPORT_PERSON>12:54 PM Hi there
<SUPPORT_PERSON>12:54 PM How are you?
<ME>12:54 PM Hi. I'm trying to read your website but it's broken in one of the dominant web browsers in the world.
<SUPPORT_PERSON>12:54 PM Hi you said that the link https://domains.google/tld/dev/ doesn't work on Safari?
<ME>12:55 PM The accordion links are broken.
<SUPPORT_PERSON>12:55 PM Have you tried in Chrome already though or maybe a private window in Safari already?
<ME>12:55 PM "Is this a one-time payment? Will I still need to pay $12 every year to keep my domain?" click (nothing happens)
<SUPPORT_PERSON>12:55 PM It's just maybe a cache
<ME>12:56 PM It's not just a cache
<SUPPORT_PERSON>12:57 PM Alright but have you tried other browsers maybe?
<SUPPORT_PERSON>12:57 PM I've checked it here and the link you sent works just fine
<ME>12:57 PM Did you test in the latest Safari on the latest macOS? Because it doesn't work fine.
<SUPPORT_PERSON>12:57 PM Sorry, not using Mac
<SUPPORT_PERSON>12:58 PM But we'll look into it if we get feed backs similarly
<SUPPORT_PERSON>12:59 PM We apologize for the inconvenience but please take a look into it on a different browser like Chrome for the time being
<ME>12:59 PM here are other reports https://news.ycombinator.com/item?id=19178833
<SUPPORT_PERSON>12:59 PM Oh alright thank you
<SUPPORT_PERSON>1:00 PM Let me check that
<SUPPORT_PERSON>1:04 PM We are already looking into it <ME>
Google Support
<SUPPORT_PERSON>12:53 PM Thank you for contacting Google Domains. My name is <SUPPORT_PERSON> and I'll be happy to assist you. Let me quickly read your notes here.
<SUPPORT_PERSON>12:54 PM Hi there
<SUPPORT_PERSON>12:54 PM How are you?
<ME>12:54 PM Hi. I'm trying to read your website but it's broken in one of the dominant web browsers in the world.
<SUPPORT_PERSON>12:54 PM Hi you said that the link https://domains.google/tld/dev/ doesn't work on Safari?
<ME>12:55 PM The accordion links are broken.
<SUPPORT_PERSON>12:55 PM Have you tried in Chrome already though or maybe a private window in Safari already?
<ME>12:55 PM "Is this a one-time payment? Will I still need to pay $12 every year to keep my domain?" click (nothing happens)
<SUPPORT_PERSON>12:55 PM It's just maybe a cache
<ME>12:56 PM It's not just a cache
<SUPPORT_PERSON>12:57 PM Alright but have you tried other browsers maybe?
<SUPPORT_PERSON>12:57 PM I've checked it here and the link you sent works just fine
<ME>12:57 PM Did you test in the latest Safari on the latest macOS? Because it doesn't work fine.
<SUPPORT_PERSON>12:57 PM Sorry, not using Mac
<SUPPORT_PERSON>12:58 PM But we'll look into it if we get feed backs similarly
<SUPPORT_PERSON>12:59 PM We apologize for the inconvenience but please take a look into it on a different browser like Chrome for the time being
<ME>12:59 PM here are other reports https://news.ycombinator.com/item?id=19178833
<SUPPORT_PERSON>12:59 PM Oh alright thank you
<SUPPORT_PERSON>1:00 PM Let me check that
<SUPPORT_PERSON>1:04 PM We are already looking into it <ME>
> Hi. I'm trying to read your website but it's broken in one of the dominant web browsers in the world.
Don't we all hate reports like this one. "Yeah I know what information you need but my high horse told me to write this crap instead."
Don't we all hate reports like this one. "Yeah I know what information you need but my high horse told me to write this crap instead."
> <SUPPORT_PERSON>12:54 PM Hi you said that the link https://domains.google/tld/dev/ doesn't work on Safari?
Where exactly do you think that came from? Kindly note the words "you said".
It's almost as if there was a "please tell us what you're asking about" field that you fill in before being connected to a chat agent or something.
Where exactly do you think that came from? Kindly note the words "you said".
It's almost as if there was a "please tell us what you're asking about" field that you fill in before being connected to a chat agent or something.
It works great in Edge, Firefox, and Chrome on my PC. I think he's too high up on his horse to realize that the problem may be on his beloved religion/platform.
Made for developers, by developers!
> A domain just for developers
> $11,500 for 9 days early access
Makes video games early access look like childs play.
> $11,500 for 9 days early access
Makes video games early access look like childs play.
It's a nice way to earn a bit of cash from larger companies who do not want "company.dev" associated with porn or malicious content. Imagine if "unity.dev" or "disney.dev" pointed to a cesspool of viruses.
There are icann rules for launching a tld. There is a period for tm holders. Most companies are going to get their company.dev during the tm period. If they don’t, three is always the udrp process.
So big companies with big money won't have to shell out cash because there's a TM period for them but smaller one got to buck out 10,000 bucks to prevent cyber squatting ?
So soft handed implied blackmail? Seems legit.
> A domain just for developers
> Can I buy a .dev domain even if I'm not a developer?
> Yes! From tools to platforms, programming languages to blogs, .dev is a home for all the interesting things that you build.
> Can I buy a .dev domain even if I'm not a developer?
> Yes! From tools to platforms, programming languages to blogs, .dev is a home for all the interesting things that you build.
[deleted]
The .dev TLD worked fine before it was bought. Now we have to use .test or .local.
I don't get what Google thinks they'll get out of sponsoring putting sites under development online.
I don't get what Google thinks they'll get out of sponsoring putting sites under development online.
It's always best to follow the RFCs [1] to avoid issues like this. ".dev" worked but it was never safe to use it.
1: https://tools.ietf.org/html/rfc2606#page-2
1: https://tools.ietf.org/html/rfc2606#page-2
Why do you have to use either one of those?
If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services.
You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services.
You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
Why do you have to use either one of those?
I’m not the OP, but I’m in the same boat.
Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
I’m not the OP, but I’m in the same boat.
Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
If you've any developers on your team that use MacOS, avoid .local since it does some listening on this for Bonjour: https://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-dom...
I believe .localhost is the "official" recommended TLD for local development.
I believe .localhost is the "official" recommended TLD for local development.
According to RFC 2602 [1],
> 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.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
[1]: https://tools.ietf.org/html/rfc2606
> 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.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
[1]: https://tools.ietf.org/html/rfc2606
.test, .example, and .invalid are also reserved by the RFC and don't have this problem.
> ".test" is recommended for use in testing of current or new DNS related code.
This one looks the safest and least prone to confusion.
> ".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.
Both of these look problematic from a terminology standpoint, not a technical one.
This one looks the safest and least prone to confusion.
> ".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.
Both of these look problematic from a terminology standpoint, not a technical one.
.test is also problematic for the purpose of hosting internal (but not development/testing) domains on a private network.
There is a draft RFC to reserve .internal for this purpose, which I think makes a lot of sense.
https://github.com/wkumari/draft-wkumari-dnsop-internal
There is a draft RFC to reserve .internal for this purpose, which I think makes a lot of sense.
https://github.com/wkumari/draft-wkumari-dnsop-internal
Plus "DNS related code" can be stretched pretty far to "code that uses DNS." so it's the one I prefer.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
Way more things than MacOS use mDNS for service discovery. That TLD is reserved for that use.
.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.)
I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use?
It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
I guess I just don't like multi-billion dollar companies coming in and dictating that I change my workflow for their cash grabs.
Who bought it is irrelevant. It could have been released to the public in a similar way to .com and the same issue would remain.
The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow.
Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow.
Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
Then you should not have built your workflow on a non-reserved TLD.
Eh, I'll just keep doing what I've been doing, but thanks.
https://twitter.com/byuu_san/status/1096885634923294720
https://twitter.com/byuu_san/status/1096885634923294720
One company I worked at thought it would be a good idea to use .local for their global internal network.
Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
Google weren't supposed to make it generally available. From their application[0]:
> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.
[0]: https://gtldresult.icann.org/applicationstatus/applicationde...
> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.
[0]: https://gtldresult.icann.org/applicationstatus/applicationde...
Why do you need to use .test or .local?
Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
HSTS is required for .dev
Install a root cert? Takes 1 minute.
Yeah sure takes one minute, one minute of wondering if you really wanna bash your head against a wall getting openssl to spit out an X509 cert and then some.
Or use any of the million utilities for setting up a machine-local CA.
mkcert is one.
mkcert is one.
You mean wait six to eight months for the IT security department in another division of the company in another state to -maybe- approve my cert request.
Not all web development is three guys on Linux laptops at WeWork.
Not all web development is three guys on Linux laptops at WeWork.
Why would you need a real cert? This is for your local machine, right? Use the tool, generate a CA, important into Mozilla's trust store, and go nuts.
I'm trying to imagine a webdev workflow where you couldn't get a machine-local CA working.
I'm trying to imagine a webdev workflow where you couldn't get a machine-local CA working.
No admin privileges to manipulate the certificate store is one.
You shouldn't need admin to add a CA to the Windows User Trusted Root Store.
https://docs.microsoft.com/en-us/windows/desktop/seccrypto/s...
https://docs.microsoft.com/en-us/windows/desktop/seccrypto/s...
I do development. I do not use Windows.
If you're a big org, presumably you could just get your org to just buy the TLD if it's that much trouble.
Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
[deleted]
When in doubt, racketeer.
I've been annoyed by how Google uses Adwords for a while; suppose you're company in a competitive, undifferentiated space. I just searched for "enterprise rental cars," and the first thing below the search box, an ad, was for getaround.com. The second was an ad for Enterprise, the third was the organic result for Enterprise. Google is effectively telling these companies "You wouldn't want someone to happen to see a competitor first and click them when they search for them, would you? Then pay up." That's a racket.
Same with this. They're inventing the demand for this TLD, then telling developers to pay up if they don't want someone to take their name.
I've been annoyed by how Google uses Adwords for a while; suppose you're company in a competitive, undifferentiated space. I just searched for "enterprise rental cars," and the first thing below the search box, an ad, was for getaround.com. The second was an ad for Enterprise, the third was the organic result for Enterprise. Google is effectively telling these companies "You wouldn't want someone to happen to see a competitor first and click them when they search for them, would you? Then pay up." That's a racket.
Same with this. They're inventing the demand for this TLD, then telling developers to pay up if they don't want someone to take their name.
They're inventing the demand for this TLD, then telling developers to pay up if they don't want someone to take their name.
For a lot of developers the demand was already there because they had their local virtual hosts on .dev. It wasn’t standard, but it was extremely common.
Then one day Google announced that it owns .dev and all the developers had to move their development domains to a different imaginary TLD or .example since Chrome would no longer let them test web sites on their development environments.
I am a developer. I will not pay Google or anyone else to use .dev simply because I have learned that Google can not be trusted. What prevents Google from taking .dev back in-house one random day and kicking everyone’s web sites to the curb? Absolutely nothing. Because you don’t own the domain. You only rent it.
I keep my development and testing on locally routed .dev and simply don’t use Chrome. Fortunately the people who sign my paychecks only care about Safari. Not everyone has that luxury, but I do, so I will make this minuscule stand that Google will never know or care about because an algorithm cannot know or care.
For a lot of developers the demand was already there because they had their local virtual hosts on .dev. It wasn’t standard, but it was extremely common.
Then one day Google announced that it owns .dev and all the developers had to move their development domains to a different imaginary TLD or .example since Chrome would no longer let them test web sites on their development environments.
I am a developer. I will not pay Google or anyone else to use .dev simply because I have learned that Google can not be trusted. What prevents Google from taking .dev back in-house one random day and kicking everyone’s web sites to the curb? Absolutely nothing. Because you don’t own the domain. You only rent it.
I keep my development and testing on locally routed .dev and simply don’t use Chrome. Fortunately the people who sign my paychecks only care about Safari. Not everyone has that luxury, but I do, so I will make this minuscule stand that Google will never know or care about because an algorithm cannot know or care.
You could make the argument with a lot of the (mostly pointless) TLDs that have been released recently, such as .uk, which was a clear money-grab targeting existing .co.uk owners, or .sucks, which feels like an attempt to extort all domain owners.
True. Also, the new TLDs have gotten out of hand to the point that ICANN launching a new TLD has become noise. Their restraint has been so lacking that I'm expecting punycode emoji TLDs in the next few years. If you thought .sucks was bad, just wait for the poo emoji.
Ugh. I wish I had something more insightful to say, but I read your comment and audibly groaned, because I just know deep down that you're correctly predicting the future.
google.com isn't a public place, it also isn't a particularly valuable plot of "land" aside the private goliath built upon it.
The fact people go to Google gives them their power to extort business for ranking. But thats because Google remains valuable - people use it because it works, or at least because of inertia that nothing is remotely better yet, and so long as people still value the search companies can do the cost benefit analysis to know if paying the rent is worth it.
And its fortunate the only people who really care about search ranking are those trying to make money off it. There are a lot more egregious crimes being committed in the privacy space by Alphabet or by rent seekers across the economy than a business making money as a parasite off other businesses trying to make money.
The fact people go to Google gives them their power to extort business for ranking. But thats because Google remains valuable - people use it because it works, or at least because of inertia that nothing is remotely better yet, and so long as people still value the search companies can do the cost benefit analysis to know if paying the rent is worth it.
And its fortunate the only people who really care about search ranking are those trying to make money off it. There are a lot more egregious crimes being committed in the privacy space by Alphabet or by rent seekers across the economy than a business making money as a parasite off other businesses trying to make money.
I'm aware of free speech in privately owned "public places" (usually shopping centers) in some jurisdictions (California), but I didn't think that applied to racketeering.
I find it hilarious that most solo or indie developers (who they are targeting, and the vast majority of developers) won't be able to get a .dev domain judging by these prices. If they really cared, they would have some program where they validated you were a real developer and actually put some effort into screening out squatters.
Instead they have implemented a braindead dutch auction-style system that ensures developers will not be represented fairly. The marketing and implementation of this are out of touch and its doubtful this effort will be successful.
Instead they have implemented a braindead dutch auction-style system that ensures developers will not be represented fairly. The marketing and implementation of this are out of touch and its doubtful this effort will be successful.
Really? Because starting feb 28th it's only 12$/year, that's lower than pretty much any other decent TLD. Do indie devs really need the high demand domain names?
When I think of 'developers' I don't think of corporations with a $12k budget, sorry. What was cool about domain names back in the day was that anyone could register them, and you could get a cool name as an individual. I realize things are different now, and it's all about money.
It would be like Github launching a new web site and allowing 'developers' to select their usernames on a first-come basis if they paid $12k for the privilege. It's incredibly tacky and shows a lack of self-awareness on the part of Google.
It would be like Github launching a new web site and allowing 'developers' to select their usernames on a first-come basis if they paid $12k for the privilege. It's incredibly tacky and shows a lack of self-awareness on the part of Google.
Dude, 12 dollars a year. Not 12 thousand.
Google is such a big company, I find it bizarre they are trying to make money in this way.
It would be interesting to know what they make at the end of the pre-sale.
It would be interesting to know what they make at the end of the pre-sale.
My guess would be that this isn't primarily about the money (there are probably domains they could get more than $11,500 for), but rather about allocating the most in-demand domains in a way that reflects how badly people want them. A Dutch-auction-type thing like they're doing is a crude solution to this problem, but if they just went straight to GA too much valuable real estate would immediately be claimed by squatters and trolls.
The squatters defense is a good point - however, this also seems to ensure that the megacorps get the best pieces before anybody else gets to choose.
If defending against squatters is the top priority, they could also make it an application-driven process: Let people submit proposals about what they want to do with the domains along with a link to their organisation and have some group grant applications (preferably along some previously published criteria)
If defending against squatters is the top priority, they could also make it an application-driven process: Let people submit proposals about what they want to do with the domains along with a link to their organisation and have some group grant applications (preferably along some previously published criteria)
That sounds just as empty except now with massive human overhead for processing applications that can pitch whatever they want. I'd even be tempted to write up some bullshit to get a domain I want. What are they going to do, research my details? You can barely get a human on the phone at Google even when you're a paying customer.
Not to mention all the hurt feelings when someone's application is denied and the domain stays undeveloped or becomes a terrible website.
Auctions seem unfair but money is an extremely simple system for allocating finite resources. And it's not like you need a dictionary word domain name to have an online identity. It's almost pure vanity.
Not to mention all the hurt feelings when someone's application is denied and the domain stays undeveloped or becomes a terrible website.
Auctions seem unfair but money is an extremely simple system for allocating finite resources. And it's not like you need a dictionary word domain name to have an online identity. It's almost pure vanity.
That kind of program, with us being in charge of deciding who gets each domain name, would be received extremely poorly. You can just imagine.
Domains would also be much more expensive, as there would need to be human evaluators in the loop for each domain name. The base price would likely need to be at least 10X higher to fund all this.
Domains would also be much more expensive, as there would need to be human evaluators in the loop for each domain name. The base price would likely need to be at least 10X higher to fund all this.
Bingo.
>I find it bizarre they are trying to make money in this way.
Why not? If they charged a flat rate at launch, domain speculators would snatch up all the valuable domains and you'll have to buy it from them at an inflated price. At least with this system google is pocketing the premium rather than third parties.
Why not? If they charged a flat rate at launch, domain speculators would snatch up all the valuable domains and you'll have to buy it from them at an inflated price. At least with this system google is pocketing the premium rather than third parties.
Maybe they aren't doing that great? What their last successful/profitable product?
I'm not familiar with ICANN rules, but I wonder if a company can do whatever they want to a gTLD once it's accepted, even if it's not within the intended usage in the gTLD application? As far as I know, Google said they registered .dev for internal use and for Google-related products and it will be completely closed to Google, according to their application[1]:
> The mission of this gTLD, .dev, is to provide a dedicated domain space in which Google can enact second-level domains specific to its projects in development. Specifically, the new gTLD will provide Google with greater ability to create a custom portal for employees to manage products and services in development.
> Charleston Road Registry intends to operate the proposed gTLD as a closed registry with Google as the sole registrar and registrant. The goal of the proposed gTLD is to allow Google to manage the domain name space for its projects in development. The proposed gTLD will provide Google with the ability to customize its domain and website names for its projects and signal to users that .dev websites are managed by Google
> Charleston Road Registry believes that given its intended use by Google, the .dev gTLD will best add value to the gTLD space by remaining completely closed for the sole use of Google.
…and now they're opening it up to the public... :\
[1]: https://gtldresult.icann.org/applicationstatus/applicationde...
> The mission of this gTLD, .dev, is to provide a dedicated domain space in which Google can enact second-level domains specific to its projects in development. Specifically, the new gTLD will provide Google with greater ability to create a custom portal for employees to manage products and services in development.
> Charleston Road Registry intends to operate the proposed gTLD as a closed registry with Google as the sole registrar and registrant. The goal of the proposed gTLD is to allow Google to manage the domain name space for its projects in development. The proposed gTLD will provide Google with the ability to customize its domain and website names for its projects and signal to users that .dev websites are managed by Google
> Charleston Road Registry believes that given its intended use by Google, the .dev gTLD will best add value to the gTLD space by remaining completely closed for the sole use of Google.
…and now they're opening it up to the public... :\
[1]: https://gtldresult.icann.org/applicationstatus/applicationde...
That application is bullshit. Everything in Google's network already uses their pseudo-"goto" TLD.
I don't think they use any domains beyond the few used for the registry page either.
I don't think they use any domains beyond the few used for the registry page either.
It's not a TLD, it's either a single-label hostname or a fully-qualified subdomain (both will resolve internally, the former obviously won't resolve externally but the latter will, you'll just get an auth error).
I believe they can change their business plan. Even if they say it will be closed they could offer domains to the public.
I always thought gTLD has the same restriction as sTLD (for example, .aero is strictly for airline-related domains, or .mobi that must be optimized for mobile, which TBL strongly disagrees[1], etc.) but in reality I guess it's more like ccTLD where they're free to do whatever they want with the domain.
[1]: https://www.w3.org/DesignIssues/TLD
[1]: https://www.w3.org/DesignIssues/TLD
To be fair, people are generally much happier with it being opened up than it being kept closed.
Damn, now I have to change my hosts file, I've been using .dev for local development
This is common, but sadly has always been incorrect.
.test is the TLD you want, specified by RFC2606.
.test is the TLD you want, specified by RFC2606.
This seems like one of those anti-patterns that has been passed down by blog posts and from engineer-to-engineer. I've seen this in almost every single developer team I've been apart of.
Either way, like you said, people should be using .test so you don't have to worry about future collisions.
Either way, like you said, people should be using .test so you don't have to worry about future collisions.
It literally happened to me yesterday, setting up a VM and aliasing it to a .dev domain for local testing. Took me an hour to figure out what was wrong =/
I doubt they'll buy .local.
https://security.stackexchange.com/questions/14802/if-someon...
But generally speaking a subdomain on a domain you really own seems like a better idea.
https://serverfault.com/questions/17255/top-level-domain-dom...
https://security.stackexchange.com/questions/14802/if-someon...
But generally speaking a subdomain on a domain you really own seems like a better idea.
https://serverfault.com/questions/17255/top-level-domain-dom...
I guarantee you that ICANN will never allocate .local because the risk of collision is too high. They've already made that determination for .corp, .mail, and .home: https://www.icann.org/resources/board-material/resolutions-2...
This may sound like an ignorant question, but since Google is pretty aggressive about data collection:
If I buy a .dev domain, does that expose me to sending more data to Google?
If I buy a .dev domain, does that expose me to sending more data to Google?
They run the authoritative nameservers for .dev, so they'll have some information about how much traffic your domain is getting, and from where.
Beyond that (and knowing you own the domain), running the registry doesn't give them any more info than they already get about you & your domain from their other services.
Beyond that (and knowing you own the domain), running the registry doesn't give them any more info than they already get about you & your domain from their other services.
At the very least they know who you are as the domain owner -- which is part of why they got in the registrar business to begin with.
Does anyone know how the “premium” renewal prices are set and governed? I’m going through this right now with .app domains (also owned by Google). Apparently domains categorized as “premium” have a much higher yearly pricing, and how it’s priced is not specified anywhere on the registry website. I called a few registrars and they said that the premium pricing is set by the registry. What’s concerning is that the registrars admitted that there really isn’t anything stopping the registry from increasing the premium pricing at will.
Anyone have anymore info about this? Seems concerning that a registry has no restrictions on what they can do with pricing after an individual has invested into an expensive domain.
Anyone have anymore info about this? Seems concerning that a registry has no restrictions on what they can do with pricing after an individual has invested into an expensive domain.
AFAIU, the ICANN New gTLD registry agreement means you can't have "premium" prices for renewals:
"Registry Operator must have uniform pricing for renewals of domain name registrations (“Renewal Pricing”). For the purposes of determining Renewal Pricing, the price for each domain registration renewal must be identical to the price of all other domain name registration renewals in place at the time of such renewal, and such price must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal."
REGISTRY AGREEMENT - 2.10 (b)
https://newgtlds.icann.org/sites/default/files/agreements/ag...
"Registry Operator must have uniform pricing for renewals of domain name registrations (“Renewal Pricing”). For the purposes of determining Renewal Pricing, the price for each domain registration renewal must be identical to the price of all other domain name registration renewals in place at the time of such renewal, and such price must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal."
REGISTRY AGREEMENT - 2.10 (b)
https://newgtlds.icann.org/sites/default/files/agreements/ag...
Hmm, this definitely isn't the case for .app. There are numerous tiers of pricing as of right now. Google categorized specific names as "Premium", which you can see when searching for a lot of .app domains. These Premium domains vary in both initial purchase price AND the yearly renewal. One of my examples is in this thread. Purchase price was around $1000, yearly renewal is $280. Other names are even higher...
Ah, yes, the (c) clause says they can charge you more if you agreed to it "at the time of the initial registration", but not after you have invested in the domain.
But I suggest people read the whole article themselves, I have no industry expertise.
But I suggest people read the whole article themselves, I have no industry expertise.
Premium names are common across the domain industry. Different registries handle them differently (some have an up-front cost whereas others like us use annually recurring), but the registrar you're using should be making it very clear what costs you're signing up for during the registration flow.
Are you saying the registry can arbitrarily change the .app domain renewal price without control, or that they can charge a different renewal price for different .app domains?
I've experienced weird price fluctuations with .io domain renewals in the past, but haven't owned one in a few years.
I've experienced weird price fluctuations with .io domain renewals in the past, but haven't owned one in a few years.
According to registrars, yes. So for example, let's say I paid $1000 for a premium .app last year when they were released. Renewal price is marked for something like $280/yr, which I didn't expect, because I thought the premium pricing was an initial purchase price only. I thought the renewal price was standard .app renewal rates.
When I called to clarify with a few registrars, they said that this premium price ($280) is specified by the registry (Google), and that there's no guarantee that pricing will stay at $280. I used a hypothetical, and asked them if it were possible for Google to raise the price to something like $1000/yr or $10k/yr, and they confirmed that there is technically nothing stopping the registry from doing so.
When I called to clarify with a few registrars, they said that this premium price ($280) is specified by the registry (Google), and that there's no guarantee that pricing will stay at $280. I used a hypothetical, and asked them if it were possible for Google to raise the price to something like $1000/yr or $10k/yr, and they confirmed that there is technically nothing stopping the registry from doing so.
What registrar did you use? They should have made it very clear during the checkout flow what the annually recurring charge was. Can you try it again now with persona.app (another premium) and post a screenshot of what exactly they're displaying?
Yikes! My one was and still is $63.70/year. I wonder what makes a domain "premium" anyway, and what makes it more or less premium? Never even seen a live .app domain anyway so that sort of makes them not premium at all.
One criteria I've seen used to price domains as "premium" is shorter names and popular dictionary words. Not sure if this is consistent across registrars, but I would think "premium-ness" is established at the registry level.
It's unclear to me if premium-ness is a function of time, and/or if there's an objective formulaic criteria here.
It's unclear to me if premium-ness is a function of time, and/or if there's an objective formulaic criteria here.
.io is a ccTLD. They aren't bound by the same kinds of rules that gTLD operators are.
I'm unsure how it is determined but when I asked my .app registrar they said it should be $120/year for each renewal, which was less than I paid to register it. Guess I'll find out.
I believe in the original .app launch thread on HN they stated that premium domain pricing was based on machine learning. So...who knows.
I believe in the original .app launch thread on HN they stated that premium domain pricing was based on machine learning. So...who knows.
On my so far unused premium .app it is the same as the initial price but who knows what happens if I put something successful on it.
You could try transferring your domain to another registrar if you feel like you're getting gouged
I think the pricing is up to the registry and not the registrar. There is only one registry per TLD.
The renewal price is the same at any registrar, the pricing comes from the registry.
How long until Google will start removing domains that don't fit their "values"?
Surprise! Pretty much every provider has a terms of service.
Good thing I don't need to bother with public DNS if I just want to serve things for a private LAN - oh wait, thanks to HSTS I now do!
"Our ML predictor calculated with 95% confidence that in the next 3 years your software will become our competitor, damaging our projected profits. We decided to terminate your domain ownership and auctioned it off to PigsDoAds Inc., effectively immediately.
Our ensemble of customer support chatbots wishes you a wonderful day! "
Our ensemble of customer support chatbots wishes you a wonderful day! "
Buy and transfer to namecheap?
Namecheap is also participating in EAP for .dev, so you can skip the transfer entirely.
Good question. Nobody seems to know the answer here.
HN seems to be generally knowledgeable, but in this case nobody seems to be able to provide answers with good references, just guesswork. Google operates the domain. How much regulatory power it has? What is the agreement with ICANN. What is the dispute solution mechanism?
----
edit
after looking around, operator agreement with ICANN seems include public interest commitments etc. Operator can't do whatever they want and their policy should be transparent.
> Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.
https://newgtlds.icann.org/sites/default/files/agreements/ag...
HN seems to be generally knowledgeable, but in this case nobody seems to be able to provide answers with good references, just guesswork. Google operates the domain. How much regulatory power it has? What is the agreement with ICANN. What is the dispute solution mechanism?
----
edit
after looking around, operator agreement with ICANN seems include public interest commitments etc. Operator can't do whatever they want and their policy should be transparent.
> Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.
https://newgtlds.icann.org/sites/default/files/agreements/ag...
Very quickly.
What if they remove domains owned by open source projects that refuse to implement a CoC?
I don’t think they will, but buying a domain from a company that’s so involved in politics doesn’t seem wise.
I don’t think they will, but buying a domain from a company that’s so involved in politics doesn’t seem wise.
Then you yell a lot on the internet and find out if you're on the good side of the cultural Zeitgeist.
I don't know how this stuff works, what gives google the ability to sell these domains early? Also why is everyone cursing google for taking their local .dev? Google is not the only place you can buy these. Namecheap has .dev in the works, and GoDaddy is taking pre-orders as well (I didn't keep searching but I'm sure it's available at many other registrars), but nobody is cursing and shaking their fist in the air at those services. So what does google have to do with it? Why are we all holding them responsible?
How much did it cost to buy the TLD? Looks like a very good investment that will repay itself quite easily.
>The evaluation fee is US$185,000. Applicants will be required to pay a US$5,000 deposit fee per requested application slot when registering. The deposit will be credited against the evaluation fee. Other fees may apply depending on the specific application path. See the section 1.5 of the Applicant Guidebook for details about the methods of payment, additional fees and refund schedules.
Section 2.2 https://newgtlds.icann.org/en/applicants/global-support/faqs...
Section 2.2 https://newgtlds.icann.org/en/applicants/global-support/faqs...
There's a nonzero chance that the investment could be a dud if people simply don't like the TLD, the same way how no one (except a few people [1]) like the .bike TLD.
[1] http://poop.bike
[1] http://poop.bike
It costs USD$185,000 to submit a TLD application, and there are probably additional costs beyond that.
Yes, you do need to hire a good domain attorney that is well versed in tld applications.
Last time I considered a new tld you are looking at about $500k in total costs, such as application, atty fees, and marketing fees.
That’s if it doesn’t end up in auction. Google paid $25m for .app, I believe.
Last time I considered a new tld you are looking at about $500k in total costs, such as application, atty fees, and marketing fees.
That’s if it doesn’t end up in auction. Google paid $25m for .app, I believe.
I'm surprised there is no site to crowdfund TLDs by taking a deposit from people in order to reserve a name
I guess the usual ~$200k.
I was already irritated that they took the .dev TLD. This sort of blatant money grab over it is simply gross. $8k premium to get in on the first day.
I feel like if they're going to force https on .dev domains they should just bundle certs with the domain itself. I like https as much as the next guy but it's simply not necessary in many types of websites (e.g. a website with documentation and third party binary links), and they're not making it as painless as it could be to comply with their own rules
>it's simply not necessary in many types of websites (e.g. a website with documentation and third party binary links)
I see debates about HTTPS as being a bit like debates about wearing pants in public. "Technically, if a subway station is empty and the AC is working, you don't have to wear pants." "You don't gain anything by wearing pants in a deserted forest when the weather is nice." "Wearing pants is a lot of work, and every day before putting them on I check to make absolutely sure that I will suffer dire consequences if I leave them off."
In all of these cases, you are betting big that none of the situations will go sideways for unexpected reasons (how sure are you that you have thought of 100% of the ways in which going pants-less in a subway station could get you in trouble, and how sure are you that none of them will happen?), but the reward for taking on that risk is almost nothing.
I see debates about HTTPS as being a bit like debates about wearing pants in public. "Technically, if a subway station is empty and the AC is working, you don't have to wear pants." "You don't gain anything by wearing pants in a deserted forest when the weather is nice." "Wearing pants is a lot of work, and every day before putting them on I check to make absolutely sure that I will suffer dire consequences if I leave them off."
In all of these cases, you are betting big that none of the situations will go sideways for unexpected reasons (how sure are you that you have thought of 100% of the ways in which going pants-less in a subway station could get you in trouble, and how sure are you that none of them will happen?), but the reward for taking on that risk is almost nothing.
I take your point, but to be fair, there is a cost to me for thinking in this way where I better consider every possible action I take being offensive. I have no malicious bone in my body, but I am certainly callous at times (unintentionally).
What are some good use cases for a .dev domain? For example, .ai for Artificial Intelligence, .io for startups. One thing that comes to my my mind is .dev is good for developer tools and related projects. Any other projects or products that .dev domain can be used for? Thanks!
All kinds of (Russian?) names end with dev.
President Medvedev and Art Lebedev studio come to mind.
President Medvedev and Art Lebedev studio come to mind.
I've had .dev domains for years. (Internally with Apache, virtual hosts IIRC?)
It seemed like the obvious choice of suffix for my localhost experiments, and I can't be the only person using it (e.g. https://headsigned.com/posts/setting-up-local-development-do...), will this new TLD break that?
I suppose I can always edit my hosts file but if I didn't know a new TLD was dropping would it screw me silently?
It seemed like the obvious choice of suffix for my localhost experiments, and I can't be the only person using it (e.g. https://headsigned.com/posts/setting-up-local-development-do...), will this new TLD break that?
I suppose I can always edit my hosts file but if I didn't know a new TLD was dropping would it screw me silently?
You should never ever invent your own TLD for internal use. There TLD defined for that purpose. Look at RFC2606.
[RFC2606] https://tools.ietf.org/html/rfc2606
[RFC2606] https://tools.ietf.org/html/rfc2606
Is the gouge for early access normal for registrars with a new TLD?
Sadly, yes. The whole domain business is like that, profiteering at every turn.
All of those new gTLDs are pure racketeering. Sub-domains worked fine (and still do!) for testing or development purposes. Or even company-dev.com
I fail to see what value there is in a .dev tld.
I fail to see what value there is in a .dev tld.
> I fail to see what value there is in a .dev tld.
Then don't buy one?
Then don't buy one?
Sure. I'm not really impacted. The racketeering targets big companies who need to buy all domains in all tlds for all of their trademarks. It's disgraceful but of course it's hard to feel sorry for large corporations.
Yet, Internet companies (like Google) who participate in this should lose a little respect from everyone.
Yet, Internet companies (like Google) who participate in this should lose a little respect from everyone.
Having used "sudo vi /etc/hosts" to add .dev domains, this gets no <3 from me.
I'm going to avoid buying one, but if there are any popular .dev domains I hope I will forget about it before long. I don't want negative feelings from this so often. On the other hand there are plenty of reminders of negative things in politics and the environment, so I guess I've gotten used to it and developed outrage fatigue.
I'm going to avoid buying one, but if there are any popular .dev domains I hope I will forget about it before long. I don't want negative feelings from this so often. On the other hand there are plenty of reminders of negative things in politics and the environment, so I guess I've gotten used to it and developed outrage fatigue.
We have RFCs for a reason, so people follow predictable behavior everywhere. And so you don’t build up a ton of work/customization and then suddenly have a surprise like this. Worse, you embed that custom design into a system and then leave and someone else needs to fix that mess.
.test is what you should have been using, precisely for this reason.
.test is what you should have been using, precisely for this reason.
Nope. Testing is a meaningful term in software development, and what I was using it for doesn't entirely fit into my concept of testing. Much of it was just development.
/etc/hosts doesn't accept wildcards, so you probably didn't catch much. This was settled a long time ago:
https://tools.ietf.org/html/rfc2606
.test is only one more letter.
https://tools.ietf.org/html/rfc2606
.test is only one more letter.
That's why I was editing it with vim. I manually added the two dozen or so names and put them in my team's git repo.
.test doesn't convey the meaning I intended.
.test doesn't convey the meaning I intended.
Ok, but you are wrong, just like the folks who insist on using clever DoD IP addresses instead of RFC 1918.
At least you aren't directly accusing me of failing to RTFM!
I've been vaguely aware of what's in that RFC, but I don't think reserving those TLDs for local stuff means that other TLDs are off limits. I certainly don't use example.com for all example emails. Developer happiness comes first.
I got burned by going with domains outside that doc, but I think the blame goes on Google, not on those who decided to use .dev without making it an official standard. I think if it was an official standard Google might still have muscled their way into getting .dev, and I wouldn't be surprised if they do the same with .test in the future.
I've been vaguely aware of what's in that RFC, but I don't think reserving those TLDs for local stuff means that other TLDs are off limits. I certainly don't use example.com for all example emails. Developer happiness comes first.
I got burned by going with domains outside that doc, but I think the blame goes on Google, not on those who decided to use .dev without making it an official standard. I think if it was an official standard Google might still have muscled their way into getting .dev, and I wouldn't be surprised if they do the same with .test in the future.
I'm a developer too, I always use example.com because accidentally triggering bogus outbound mail from corporate IP addresses can make a mess for Operations.
And Google gets baseless accusations because you feel entitled to something. Enjoy the feeling, you're entitled to it.
And Google gets baseless accusations because you feel entitled to something. Enjoy the feeling, you're entitled to it.
You can only purchase on Google Domains if your billing address is in a supported country (15 countries listed).
Would .dev domain be available from other countries?
Would .dev domain be available from other countries?
It seems like some companies and individuals started to register their names with .dev TLD. There are 573 registered .dev domain names now.
You can see all of them on dofo.com: https://dofo.com/search/?extension=dev
Pretty sure the first domains acquired will be targeted at local development setups, like tmp.dev, staging.dev, production.dev, etc. etc.
edit: just a reminder that .local is the reserved one https://en.wikipedia.org/wiki/.local
edit: just a reminder that .local is the reserved one https://en.wikipedia.org/wiki/.local
Most likely the domains like tmp.dev, staging.dev, and production.dev are premium domains that will never be released by the registry.
Many premium domains are held back by the registry, which are a part of icann rules. Those domains are typically not able to be registered and used by anyone.
Many premium domains are held back by the registry, which are a part of icann rules. Those domains are typically not able to be registered and used by anyone.
[deleted]
Just to make sure, you can't get multiple domains with early access, right?
If you're looking for a live .dev domain (for testing purposes etc) https://v8.dev/ has existed since September 2018.
Speaking of Domain, I am still waiting for .Web. What happen to it?
https://icannwiki.org/.web
Looks like it's still proposed, not even delegated. Registrations usually happen a few months after delegation depending on the registry's intentions.
Looks like it's still proposed, not even delegated. Registrations usually happen a few months after delegation depending on the registry's intentions.
[deleted]
Joining the bandwagon of anything from Google, be cautious. Do I really need to be using this? Is there any alternative?
I'm assuming some repos use .dev as a development domain. If so, then enforcing HSTS could break a lot!
Would it be wise to hoard a bunch of brand name domains in hopes they become valuable?
No, because doing so is against ICANN rules, so the maximum value of a brand domain is the cost to open an ICANN dispute.
Most likely the registry won’t let you buy trademarked domains if you can’t prove you have the trademark. There is a period set aside for tm holders.
I would stay far away from any brand or tm domains at any time. You will eventually lose the domain through a udrp. And you could likely get sued as well.
I would stay far away from any brand or tm domains at any time. You will eventually lose the domain through a udrp. And you could likely get sued as well.
Only if both the company and the registry give enough of a shit. For example, microsoft.ba has been sqatted since 2006.
Despite Microsoft having a presence in the country, they still can't get .ba thanks to an incompetent registry in charge of .ba TLDs.
Despite Microsoft having a presence in the country, they still can't get .ba thanks to an incompetent registry in charge of .ba TLDs.
Game theory at work! I like it.
Looking forward to have an AI-driven dynamic pricing platform.
Looking forward to have an AI-driven dynamic pricing platform.
Now, I get it why they forced us to use .test or .local.
Well planned.
I really actually hope Google decides to not index .dev domains/sites. It’s crazy how many times have I seen a site in dev or staging that gets indexed by google but shouldn’t be indexed.
That wouldn't make sense since the TLD isn't just for the staging phase of a website. It's for anything.
Um. Wait? Didn't Google recently propose (effectively) an alternative to domains? I realize that's a long way off, if ever. None the less $12k feels excessive.
I hope something nice lands at jaiguru.dev
Why is this such a popular story ? There’s literally hundreds of new gTLDs and they get released all the time.
Is this .dev only avaliable through Google Domains? WTH? Google Domains is still not available in my country.
It's available through other registrars as well. Gandi is a European registrar that supports it, for example.
Is everyone at Google fucking bored of the free massages so just makes stupid shit like this?
A domain just for developers! Until it abruptly shuts down Feb 19, 2021. Why would anyone trust Google with something with any kind of long-term requirements as important as a name? They should have registered ".chump" instead, because that is really what users of a Google-managed TLD are declaring
"Dear VALUED developer, thanks so much for being a part of the .dev experiment! After a long hard period of staring at our shoes, we realized we cannot extract sufficient value from our users in this manner. As of midnight, your name will automatically be migrated to our newer, better, faster TLD, .plus, the future of the open web"
"Dear VALUED developer, thanks so much for being a part of the .dev experiment! After a long hard period of staring at our shoes, we realized we cannot extract sufficient value from our users in this manner. As of midnight, your name will automatically be migrated to our newer, better, faster TLD, .plus, the future of the open web"
I don't think this is a huge concern - at least ICANN has the power to designate a successor registry, and I guarantee someone will break down the doors trying to get that particular gtld.
Yeah it will never happen. As long as you pay the registration fee you won’t lose your domain even if the registry goes bankrupt.
A TLD "with benefits" from Google is a money-printing press. While Google has a certain track record, this makes it rather unlikely for them to discontinue it in the near future.
I mean, I get your point, but I think this is a meme exclusive to HN. Other than Google Reader, there really isn't much Google has shut down without having a newer, better product you can transition to.
When it comes to something like this (AKA not a consumer product, makes money, relatively easy to run, etc), I genuinely can't see them shutting down a TLD like this.
If anything, the complaint should be the lack of official support you should probably expect for it.
When it comes to something like this (AKA not a consumer product, makes money, relatively easy to run, etc), I genuinely can't see them shutting down a TLD like this.
If anything, the complaint should be the lack of official support you should probably expect for it.
Google Wave shut down without a replacement google service. [0]
Google code shut down without a replacement google service. [1]
Google plus is shutting down too. [2]
[0] https://support.google.com/answer/1083134?hl=en
[1] https://opensource.googleblog.com/2015/03/farewell-to-google...
[2] https://support.google.com/plus/answer/9195133?hl=en
Google code shut down without a replacement google service. [1]
Google plus is shutting down too. [2]
[0] https://support.google.com/answer/1083134?hl=en
[1] https://opensource.googleblog.com/2015/03/farewell-to-google...
[2] https://support.google.com/plus/answer/9195133?hl=en
Also, can I add Google Code Search? That thing was such an incredibly valuable resource for figuring out how to work around inane edge cases in eg GTK. Just search for the function that's giving you issues, and find a dozen projects with extensive comments describing their workarounds.
Google Inbox is about to close in a month or two.
[deleted]
You may've missed the recent news on Google Fiber pulling out of Louisville (https://news.ycombinator.com/item?id=19106998) as well as Google Plus shutting down.
Some folks make a hobby out of the stuff Google spins up and then abandons: https://killedbygoogle.com
Some folks make a hobby out of the stuff Google spins up and then abandons: https://killedbygoogle.com
This is an amazing list. It might not be 100% fair since a few products got replaced with something better, but I think most didn't.
Fundamentally, Google is just an advertising company that happens to employ very smart people. If you go to work for Google, you have to understand from the outset that you're working for an advertising company and you're not going to change the world. You might be allowed to work on a fun project, but if it doesn't directly serve the needs of advertising it will be shut down. But hey, it'll look good on your resume.
Fundamentally, Google is just an advertising company that happens to employ very smart people. If you go to work for Google, you have to understand from the outset that you're working for an advertising company and you're not going to change the world. You might be allowed to work on a fun project, but if it doesn't directly serve the needs of advertising it will be shut down. But hey, it'll look good on your resume.
The 'Google Graveyard' meme is known far and wide beyond HN - I'm a long time member on a [n ostensibly] design-focused forum where it's been a long time running gag (of the acerbic kind) too.
Tlds generally won’t be shut down and can’t be shut down.
Yeah, that won’t happen. Even if a registry goes out of business the domains and tlds will still resolve, most likely operated by another registry.
Domains will be useful for Google search ...
Somebody makes this post on every HN thread involving Google now. But the three big public deprecations I'm aware of are Reader, Inbox, and G+. All consumer products. All the other stuff on that killed by Google site is stuff I've barely even heard of, and all consumer products.
To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
> To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN meme at this point.
It's not like these complainers actually read articles they're commenting on. You could see this in the Chromecast DNS rantfest - the path is "Google in title => rant about your pet peeve" not "Read article => complain about topical thing".
It's not like these complainers actually read articles they're commenting on. You could see this in the Chromecast DNS rantfest - the path is "Google in title => rant about your pet peeve" not "Read article => complain about topical thing".
> But the three big public deprecations I'm aware of are Reader, Inbox, and G+.
Google Code. Also Wave and half a dozen chat apps, but Code was a serious one that broke a lot of the developer web.
Google Code. Also Wave and half a dozen chat apps, but Code was a serious one that broke a lot of the developer web.
>Google Code. Also Wave and half a dozen chat apps, but Code was a serious one that broke a lot of the developer web.
What did it break?
What did it break?
It hosted repos, and broke links to those repos and links within them. It also broke processes that relied on the repo, e.g. automatic issue creation in CI, but that's less serious.
URLs that change without good reason are a PITA.
URLs that change without good reason are a PITA.
They have a process for setting up redirects. They also provide read only access to all public code AIUI:
https://code.google.com/archive/about
https://code.google.com/archive/about
Setting up a redirect works if you are the administrator of the project...and are still alive. Migrating a project was simple if it didn't have a wiki. There are a lot of details that caused some real headaches. I remember it being like a mini Y2k at the time, and there's no telling how much we just collectively lost from it.
This is simply incorrect. As the person who (led? handled?) the shutdown/archiving, the vast majority of the 'developer' web had gone to github. The handful of active projects were given white glove treatment once we decided to shutter the site.
> the vast majority of the 'developer' web had gone to github
I see hundreds of thousands of repositories on Github responding to the search "Automatically exported from code.google.com", which means they only transferred _after_ the shutdown was announced (when the export tool went live). Any wikis would have had to be hand-converted to not be broken, since the markup between the two systems was not compatible. I mean, thank you for handling it as well as it was handled, and thank you for (if you were part of that) the export tool, but let's not pretend that it wasn't disruptive.
I see hundreds of thousands of repositories on Github responding to the search "Automatically exported from code.google.com", which means they only transferred _after_ the shutdown was announced (when the export tool went live). Any wikis would have had to be hand-converted to not be broken, since the markup between the two systems was not compatible. I mean, thank you for handling it as well as it was handled, and thank you for (if you were part of that) the export tool, but let's not pretend that it wasn't disruptive.
I heard that old google cloud offering price was increased 10-fold on short notice.
Not the same, but close
Thats made up, but ok.
It happened, but in the transition from preview to product, so not at all the same thing as a deprecation.
https://www.informationweek.com/cloud/platform-as-a-service/...
https://www.informationweek.com/cloud/platform-as-a-service/...
Every year google deprecates at least one "cloud" service/api. Not to mention the appengine pricing story.
The famous app engine pricing increase happened when app engine left preview. People still mention it often, but it was never meant for production usage while at the preview price.
You haven't been watching long enough https://cloud.google.com/appengine/docs/deprecations/
Most of those sound like "you have to upgrade to the latest version"?
$11,500 screams greed to me, how much money is enough?
localhost.dev should be fun
If someone ends up buying it, please set your DNS records to point to something in 127.0.0.0/8
I would have thought localhost as a second level domain name would be reserved but it seems like it's not.
Besides the usual disregard decency let's HSTS preload a TLD people have been using for local development for decades...
This is terrible gatekeeping and I hope Google perishes soon. Wow. I can't get over how fucking dumb this is.
This is the mark of a corporation filled with people that thinks putting a price tag on supposedly scarce good early will deter bad actors. Clearly everyone who thought this up has way too much money in their account.
This is terrible gatekeeping and I hope Google perishes soon. Wow. I can't get over how fucking dumb this is.
This is the mark of a corporation filled with people that thinks putting a price tag on supposedly scarce good early will deter bad actors. Clearly everyone who thought this up has way too much money in their account.
Yes, this, though I really am disappointed in ICANN here. ICANN should not have sold a TLD known to be in heavy use already. Their desire for cash from this process seems to have overwhelmed their good sense in managing the domain system.
Their desire for cash is the only reason this process exists in the first place. The “old” tlds were perfectly fine as they were.
Yeah, well. That's got nothing to do with .dev. All the new TLDs are fucking dumb. Just a cash grab for the ICANN. Might as well get rid of TLDs altogether.
Honestly I don’t think it’s a cash grab for icann. There are plenty of registries that are making plenty of money, as well as domain owners selling the domains in the aftermarket.
The reason the new tlds were needed is the lack of options for buying a new domain. I know plenty of smaller biz and startups who couldn’t get the dot com they wanted and ended up choosing a really good keyword rich new tld.
The reason the new tlds were needed is the lack of options for buying a new domain. I know plenty of smaller biz and startups who couldn’t get the dot com they wanted and ended up choosing a really good keyword rich new tld.
> Honestly I don’t think it’s a cash grab for icann.
Wasn't it $10k upfront to have your application for a new gTLD considered? This times ~1200 ... works out quiet good.
Wasn't it $10k upfront to have your application for a new gTLD considered? This times ~1200 ... works out quiet good.
To me potato.app is as sketchy and shitty as getpotato.com. They simply say "I wanted to buy potato.com but I couldn't"
Is steampowered.com sketchy? Even incredibly large companies often can't get the domains they want because they were bought twenty years ago by some Joe Schmo.
steampowered.com is super sketchy. It's just that most people use the Steam client and it's been around enough time for it to sink in.
Like if an app tried to register apppowered.com it would definitely hurt its image. Obviously massive players are above the rules somewhat.
Like if an app tried to register apppowered.com it would definitely hurt its image. Obviously massive players are above the rules somewhat.
If you've been using .dev for local development, that means you've either been setting it in your hosts or using your own DNS server until now, which you can continue to do with a .dev TLD.
Except that both Firefox and Chrome ship with the ENTIRETY of .dev on HSTS preload lists, so it'll be impossible to use those domains without clients either installing a CA or owning the domain and getting a cert.
Chrome requires an SSL certificate for all .dev hostnames.
if you have the technical savvy to be using .dev before the Google deployment, you have the technical savvy to install an additional root cert for use with Chrome.
What about internal use in organizations?
Sorry but this is pure malice by Google. I can invert this argument by saying if you're buying a .dev domain you have the technical savvy to get on an HSTS preload list, except you haven't broken anyone's workflow.
EDIT: And I mean... have you USED openssl's x509 toolchain? That's a few steps up from editing the hostsfile.
Sorry but this is pure malice by Google. I can invert this argument by saying if you're buying a .dev domain you have the technical savvy to get on an HSTS preload list, except you haven't broken anyone's workflow.
EDIT: And I mean... have you USED openssl's x509 toolchain? That's a few steps up from editing the hostsfile.
Editing the hosts file isn't a solution for internal use in organizations.
If it's just you, editing your hosts file, switch to .local or whatever. There was always a chance when using a "local" domain (which isn't actually some sort of standard) that such a TLD could be created in the future. If it's for an organization, create the root cert, and have that be one of the steps users need to take in order to access the dev site. Or just switch to .local or .test or .whatever.
I've been using .dev as a local test environment for years too, but I'd prefer to have more TLD options available and just switch to .local or .test because I'm not averse to change.
If it's just you, editing your hosts file, switch to .local or whatever. There was always a chance when using a "local" domain (which isn't actually some sort of standard) that such a TLD could be created in the future. If it's for an organization, create the root cert, and have that be one of the steps users need to take in order to access the dev site. Or just switch to .local or .test or .whatever.
I've been using .dev as a local test environment for years too, but I'd prefer to have more TLD options available and just switch to .local or .test because I'm not averse to change.
.local is reserved for multicast DNS/zeroconf, by the standard. You literally can’t use it on macos because it will always try to look it up in with mDNS first, and only fall back on /etc/hosts once that fails.
If you use .local for fake DNS for a dev setup, you’ll probably notice lookups are slow; that’s why.
(This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
If you use .local for fake DNS for a dev setup, you’ll probably notice lookups are slow; that’s why.
(This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
> (This is why I’ve always used .dev actually, although this may make me switch to .fuckgoogle or something instead)
Why not .fuckapple? Really, .local is defined for local address, if Apple is using it in a fucked up way this is an Apple problem.
.dev was never destined for local address, it was just because it wasn't registered in ICANN yet.
Why not .fuckapple? Really, .local is defined for local address, if Apple is using it in a fucked up way this is an Apple problem.
.dev was never destined for local address, it was just because it wasn't registered in ICANN yet.
Maybe you've never been in an environment where having to change internal domains is near impossible.
I work at the intersection of 3 corporations within our group. We provide a sort of "internal Heroku" using Kubernetes for anyone in the group that needs it. We recently ran into the 63 character limit on domain name labels (we have to use a wildcard cert because nothing else is approved by legal). You wouldn't believe the time developers would've had to spend on fixing the domain schema across hundreds of services if we hadn't found a way out of that dilemma. We're talking thousands of internal names, some of them given our to external partners (we use a partially publicly resolvable name, but we could've exposed our DNS as well) and some used in systems long forgotten.
I work at the intersection of 3 corporations within our group. We provide a sort of "internal Heroku" using Kubernetes for anyone in the group that needs it. We recently ran into the 63 character limit on domain name labels (we have to use a wildcard cert because nothing else is approved by legal). You wouldn't believe the time developers would've had to spend on fixing the domain schema across hundreds of services if we hadn't found a way out of that dilemma. We're talking thousands of internal names, some of them given our to external partners (we use a partially publicly resolvable name, but we could've exposed our DNS as well) and some used in systems long forgotten.
That is such specious logic it’s kind of sickening.
I use TLDs like .dev exactly because it’s convenient. Not because I’m “savvy”, and even if that were true, it doesn’t follow that it would be just as convenient to set up a local CA.
Using `echo ip >/etc/resolver/dev` to have a custom dns server for everything in the .dev domain is trivial. It’s one command. Getting a custom CA for all of that is not.
I use TLDs like .dev exactly because it’s convenient. Not because I’m “savvy”, and even if that were true, it doesn’t follow that it would be just as convenient to set up a local CA.
Using `echo ip >/etc/resolver/dev` to have a custom dns server for everything in the .dev domain is trivial. It’s one command. Getting a custom CA for all of that is not.
One man's "convenient" is another man's "savvy." If you've got the technical ability (you are 'savvy') to use this TLD, you've got the technical ability ('savvy') to use your own CA.
And I didn't say it would be convenient. The world doesn't revolve around your convenience. I said you've got the ability to use a CA.
And I didn't say it would be convenient. The world doesn't revolve around your convenience. I said you've got the ability to use a CA.
What's sickening is devs pretending their broken workflow is important (or should matter) to anyone else, and then getting fussy when it turns out that no, their non-standardized workflow is, in fact, not a standard.
Using .dev for local development is a bug, not a feature. The only reason it was used is because it wasn't yet a TLD . Not because it had some sort of special status as a "Local TLD".
Using .dev for local development is a bug, not a feature. The only reason it was used is because it wasn't yet a TLD . Not because it had some sort of special status as a "Local TLD".
Is there a good reason not to use HTTPs now if it’s a public facing site?
As of Chrome 63, you also need HTTPS on your local development if you're using .dev.
Wow we migrated our local development 5 or 6 years ago off of .dev, just buy a real domain and set its dns to localhost.
What will you build on .dev? A site so broken that it still has a horizontal scrollbar no matter how wide the browser window.
Are you on a mac? 99% of times it's because of an external mouse connected.
edit: the css for the element that overflows has: `grid-template-columns: 50vw 50vw;` and based on the spec: https://www.w3.org/TR/css3-values/#viewport-relative-lengths, scrollbars are not taken into account, therefore as long as you have a _forced_ scrollbar, the content WILL overflow regardless of your screen size.
By forced I mean a scrollbar you cannot remove and that's not enforced by your systems settings, you can clearly see this behaviour on mac if you toggle the "Show scroll bars" setting to "Always".
Safari and webkit based browsers can avoid this issues with `::-webkit-scrollbar{ display: none}` but it's not a cross browser solution nor a wise decision to hide scrollbars overall.
edit: the css for the element that overflows has: `grid-template-columns: 50vw 50vw;` and based on the spec: https://www.w3.org/TR/css3-values/#viewport-relative-lengths, scrollbars are not taken into account, therefore as long as you have a _forced_ scrollbar, the content WILL overflow regardless of your screen size.
By forced I mean a scrollbar you cannot remove and that's not enforced by your systems settings, you can clearly see this behaviour on mac if you toggle the "Show scroll bars" setting to "Always".
Safari and webkit based browsers can avoid this issues with `::-webkit-scrollbar{ display: none}` but it's not a cross browser solution nor a wise decision to hide scrollbars overall.
I think the fact that you tried to blame my peripheral devices says a lot about the state of web dev today.
It’s still a broken site.
I see it too (Chrome on Windows 10).
.deveap-hero grid-template-columns needs to be 49vw 50vw
49vw not 50vw, to approximately make room for the vertical scrollbar when it appears.
OK, on with my day ;)
49vw not 50vw, to approximately make room for the vertical scrollbar when it appears.
OK, on with my day ;)
Or just build a site that pitches your development services.
Chromium on Arch Linux. Can confirm.
Not very equitable of them. You get in line in order of wealth.
I'll never forgive them for competing with my hosts file.
.test is not as nice
.test is not as nice
You could replace it with .d, ICANN isn't giving out single letter tld's yet.
I hope they fail.
Google forced me to migrate my local .dev domains to .devo because Chrome refused to connect to my localy configured domain names via /etc/hosts.
Google forced me to migrate my local .dev domains to .devo because Chrome refused to connect to my localy configured domain names via /etc/hosts.
Isn't this just as silly as wishing Cloudflare's public DNS fails because you were using 1.1.1.1 as a development IP ?
- Cloudflare 1.1.1.1 doesn't prevent you from using 1.1.1.1 as a development IP, it just prevents you from accessing their service if you are. Google preloading everything to the HSTS list prevents you from using it without jumping through loops.
- The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
- The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
> - The IP address 1.1.1.1 as a public DNS has clear value to the public, DNS IP addresses needing to be for 0-255 values that are memorable. .dev has no real public value considering the plethora of other tlds.
Of course it has, TLDs that describes itself are valuable for some business, and this is exactly what this seems to be about.
Of course it has, TLDs that describes itself are valuable for some business, and this is exactly what this seems to be about.
I hate the very high prices for early access. This is anti-individual-developer, pro big company, rich people.
I can see it's a way to let big companies save off their amazon.dev domain or whatever. I think a much more preferable early stage practice would be to let people who can authenticate their name let them get their name .dev. I've been trying to buy my personal domain name for a while, a name squatter has been sitting on it for years, they don't even answer their contact email. A second domain that is commercial is also in a similar category. How do these companies keep their domains and never sell them?
Someone like say JohnAkbar.com has to wait and hope another JohnAkbar or a squatter doesn't get their name. I'm also jealous of people that have more unique names. People get vanity urls or twitter handle like things with my name and never use them. Sure, first world problem but
I can see it's a way to let big companies save off their amazon.dev domain or whatever. I think a much more preferable early stage practice would be to let people who can authenticate their name let them get their name .dev. I've been trying to buy my personal domain name for a while, a name squatter has been sitting on it for years, they don't even answer their contact email. A second domain that is commercial is also in a similar category. How do these companies keep their domains and never sell them?
Someone like say JohnAkbar.com has to wait and hope another JohnAkbar or a squatter doesn't get their name. I'm also jealous of people that have more unique names. People get vanity urls or twitter handle like things with my name and never use them. Sure, first world problem but
They also compete in random new industries each time this happens.
It doesn't seem like a smart move to lease a domain from a politically active mega-monopoly that might decide to randomly become your competitor in 2 years.