Introducing .app, a more secure home for apps on the web
blog.google
blog.google
Break up google.
ICANN has worked very well so far, but if they don't put up a strong response to registrar-based censorship on already-registered domains and make this contractually impossible, the internet is going to be in big trouble. We can't let "you can't have a domain because we don't want you to be able to talk, as a matter of corporate policy" become a thing.
And I suspect even then, you could still use a Signal server hosted by someone else.
It might affect your app's search rank if you don't comply ...
If you are creating a organization that is less focused on making money as a core element like a business is, then you should feel fine using .org or any other domain.
I could only find Google Terms of Services, so they also apply to .app ??? So what if I host e.g. adult related material on .app will they ban me? The usage policy is totally in the dark for this domain.
UPDATE: Found something here https://v4.gandi.net/static/contracts/en/app/pdf/special_con... and here https://portal.icann.org/servlet/servlet.FileDownload?file=0...
When Google bans you, they delete your drive, Gmail, photos and everything associated with it including the ability to search. Also they are associative; if one of your accounts are banned then any account, even business accounts, are all purged.
One of a startup in my previous cohort was completely deleted after one of it's employees who had a banned Google account logged into Google for business
Don't risk. Avoid
http://www.slate.com/articles/technology/future_tense/2013/0...
https://www.perrymarshall.com/2270/google-bans-your-account/
https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_...
Just curious, how can you even get a lawyer for issues like this? And in US it would all be a sham show (like the Zuckerberg senate hearing)
This sounds good but how does it really help users or developers compared to having a .com website that uses HTTPS? Expecting that users will think "oh, .app, must be secure" doesn't seem like an improvement over expecting them to look for key icons in the browser, or showing them scary alerts for non-https sites.
The only play I see here is that if the new TLD becomes so popular that everyone must have one, then, well, everyone must have HTTPS. But that's not going to happen either. Even .com never reached a high enough level of importance that absolutely every website, including those who weren't interested in providing HTTPS, needed to use .com for their domain.
HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Preloading the entire TLD rather than individual domains has a number of benefits, including the fact that (a) it's effective now rather than several months from now for a newly created domain, (b) you don't individually have to configure anything, and (c) it keeps the size of the list down (which is important since the list is built into web browsers).
And in addition to all that, you're right, it is a play to move more sites to HTTPS, which is better for the safety and security of the web overall. Chrome is soon going to display "Insecure" for every single http site, which is another nudge to help move the web towards a secure future.
What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.
The full list of registrars onboarded for .app, including annotations for those supporting EAP, is here: https://www.registry.google/about/register.html
It's just another fucking cash grab.
Outrage is great, but it's a good idea to read before firing off like this.
(You can use your TMCH SMD file to register your trademark.app for ~$20, but that’s not really what we’re taking about here.)
If you have a TMCH registered mark you can get your .app for ~$20, though.
1) The announcement is made by Google, yet Google is not accepting EAP registrations. Very confusing.
2) The registrars accepting EAP are not as widely known as you would expect for something like this, meaning that I am going to have to pay to registrar now and then a transfer fee to transfer to my primary register down the road.
3) GoDaddy is listed as an EAP registrar, however, they are only accepting pre-registrations at this time. On top of that, they found a way to be even more shady by charging a $173.99 for "Priority Pre-Registration".
Whether registrars support EAP, and how they implement it, is entirely up to each registrar. If you have complaints about any specific registrar practices, or about registrars not supporting it full stop, then those should be directed at the registrar in question.
They're just auctioning off all the good names - same as every other domain squatting rent seeker...
So you have your answer.
Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been any discussion within the Registry or Search teams about how to address these kinds of situations?
Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS.
As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases.
You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with.
The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.
Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.
Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution.
Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
Yes, they’re requiring "https" but it’s not like it is hard to acquire a certificate anymore.
All the ".app" domain will do is screw app developers into paying to register their chosen name on a particular domain. Again. After all, if you don’t register then someone else could, giving their site perceived legitimacy over yours. Let’s not forget, many apps are not making millions on top-10 lists; developers aren’t exactly eager to further cut into their meager earnings to cover web sites.
We already know that entire apps are being copied. Scammers have never been deterred from copying entire web sites either (just look at those E-mails from “your bank”). This new domain might serve mainly as a way for scammers to make stolen copies seem even more real. Frankly, I predict that all the real talented developers will be slowly discouraged from continuing to try to make money in an environment where obvious fakes can thrive so easily and the costs just keep going up.
In order to fully establish identity and provide strong authentication, you would need a much stronger centralized system. Additionally, browsers would need to refuse to make connections to endpoints not authenticated through this system, otherwise you'd have the same kind of lackadaisical user response as we see now to the padlock icon. I don't think anyone present here wants anything like that, and I'm sure that if we were proposing such a walled garden vision for the Internet, the responses would rightfully be much more negative. Instead, we just want everyone's connections to be encrypted.
As for some of your other points, having a strong, short, memorable domain name is good for overall Web security and does help cut down on fraudulent apps and the other problems you've identified. To give you one example, I recently saw an ad for an app called "Curb" (it's a yellow tax ride-hailing app). Out of curiosity I wanted to see more information about it, but there was no domain name on the app; it simply said "Download the Curb app". So I searched the app store for "Curb" and there were dozens of apps with that name, many of them clearly imitators. The best "security" measure was trying to remember what the app's icon looked like.
Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores. That's taking advantage of the global uniqueness property of domain names to guarantee that I won't be tricked away by a scammer. "curb.app" is short and memorable, gets users to the right place, and because .app is a fresh namespace, is still available. Good luck getting any domain name close to that good on .com. .com is fully mined out, and any good names that are available are being sold for minimums of tens of thousands of dollars by squatters and resellers.
I'll be talking about these issues and more in depth at I/O, if you'd like to watch/stream it: https://events.google.com/io/schedule/?section=may-8&sid=7ac...
Now imagine it's a year or two from now and you have the exact same problems that you had with curb.com.
What's the strategy for when .app gets mined out? Are we just going to keep creating new tlds over and over for eternity?
Bear in mind that the only way .app won't get mined out will be if either very few people use it, or if users ignore it and don't treat it any differently than any other namespace. Ironically, the only way this will be useful for developers like me is if Google's advertising campaign utterly fails and it's ignored by most people.
The solution to identity management can't be that users will stay one tld ahead of hackers. That's just never gonna happen. Users are slower than hackers.
Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.
In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squatters will always capture a rent, by guessing domain names that will be valuable latter on. The way to minimize that rent on the long run is to periodically reset the game by bringing new TLDs into existence, thereby devaluing the investment in older TLDs, thereby making squatting a more risky activity. The GTLD liberalization greatly diminished the price pressure on .com .org and the like.
Keep in mind the web has seen exponential increase in the last decades; the upside now is much more limited, maybe another order of magnitude until complete worldwide market saturation and web growth figures get more inline to global economic growth numbers. Once that is achieved the problem becomes much less serious.
Maybe a TLD like .app could increase the annual renewal fee to something like $100 while bundling premium features like business Gmail, Adwords credits or Google Cloud services, all usable only on that domain name. This way, low level owners get their money back, big corporations don't care and squatters are hurt since they can't make use of the services.
And this is the predictable response: https://news.ycombinator.com/item?id=16972813
There are a lot of benefits to allowing hobbyists and students to cheaply (or even freely) register domains.
Zooko's triangle is a triangle - decentralization is not the only thing we could sacrifice. We could even start to layer multiple naming schemes on top of each other to mitigate some of those sacrifices.
What OP (makecheck) was getting at was that the .app tld doesn't really solve any problems except to block one very specific injection attack, and it's problematic for Google to market it as significantly more secure than any other namespace. I agree with that.
The problem isn't that new tlds are unsustainable in the long term (although they are), it's that they don't even solve anything in the short term. Right now, at this moment, I can't credibly tell my parents that they should trust a .app domain more than a .com domain. Within a month of its release, people will be using it to phish older websites - because malicious actors will always be faster than regular users and developers.
If you're trying to block Sybil attacks, I wouldn't be that surprised if introducing new namespaces ironically ends up making the problem even worse.
I feel like there's some sort of legitimate blockchain solution to be had here that doesn't involve a centralised authority. Who got there first, what domains they have owned continuously, and what products they control perhaps...
Interestingly that will only ensure HTTPS only when using a browser with HSTS enabled with a preload list that includes the .app TLD.
Therefore non-web code, or code in browsers without the TLD in the HSTS preload list, will be able to make HTTP requests to a .app domain.
It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. Also, and this is just a feeling, it seems obtrusive for google to force such a policy across the TLD. Of course it’s their right since they own the TLD, but the cynic in me can’t help but think it sets an overbearing precedent. Based on Google’s behavior in the past, this looks like the second step of the “embrace/extend/extinguish” cycle Google has used so effectively in the past.
Incidentally, this is one of the major advantages of HSTS preloading at the TLD level, namely, that all .app domains are already preloaded and have been since 2017.
On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement.
.app will be HTTPS only from the start and for the foreseeable future, so (at least in my opinion) there's no need to care about HTTP, or even open port 80 at all.
Granted you could do this before with HSTS preload, but setting that up yourself requires fiddling with headers and waiting a bit while browsers update with the new list. With ".app" it happens automatically, so it lowers the barrier, making it easier for strong encryption to be used by everyone for anything and everything.
This makes HTTPS easier than HTTP, which doesn't look like much on paper, but is (again, in my opinion) one of the best ways to increase security overall.
Except the part where the `.app` domain is only "https-only" in Chrome.
Chrome maintains the list that most browsers use, but it's not the only browser using the list.
Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's.
You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly.
As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo).
[0] https://github.com/mozilla/gecko-dev/blob/master/security/ma...
What are examples of Google's use of EEE?
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Hangouts did very much the same with XMPP, a move which a Googler once suggested to me was viewed internally as a betrayal of the company's values.
I think we may be approaching EEE territory with email: Gmail's already centralized a large portion of the email industry, to the point that Google has about two-thirds of all emails on one side or the other, and now they're moving into introducing a proprietary email format (AMP 4 Email), which isn't being developed in a standards-focused way.
I'm sure the same argument could be made for their push into RCS over texting, browsers (now pushing Chrome-only websites and features in a lot of places), Android (embracing third party OEMs before moving into locking down much of newer Android functionality and launching a first party iPhone competitor), etc.
If there was a movie quote that best exemplified Google's business strategy, it would be "I have altered the deal. Pray I do not alter it any further."
AMP for email does seem a good example.
RCS is not developed by or supported exclusively by Google. They weren't even the first; Vodafone had it on their phones for years. Google is late to the party.
--
My opinion is not that Google is ethically above doing EEE; it's that they're often too disorganized and erratic to actually pull it off even if they wanted to.
Like Google+?
Just having the best app isn't EEE.
Some examples which might not qualify specifically as EEE, but certainly qualify as Google pushing for biased standards:
- Google AMP (not clearly EEE, but definitely anti-open web)
- Google Chrome (not quite EEE, but barrier to entry in browser market is now extremely high)
Some more clearly EEE examples:
- GChat (clear EEE strategy on XMPP)
- Google flights (EEE the travel industry)
- Google shopping (EEE affiliate offers)
- ....
Note that these examples are not solely "competing with an existing business" as you described, because the initial announcement of them was usually welcoming and open, e.g. opening with federated xmpp compatibility, promoting it, and then extinguishing it later. If developers back then had known google would shut down xmpp, maybe they would have put effort into building a better federated xmpp ecosystem instead of wasting time interoperating with google's system. That kind of bait and switch is the hallmark of an EEE strategy.
Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.
Google is an incredibly evil company and are hellbent on destroying the open web.
Chrome.
Sadly the Chrome team together with web devs everywhere are creating a web where "works best in IE6^h^h^hChrome" is making a very unwelcome comeback.
This should be so unnecessary in 2018.
I don't think the devs are necessarily doing this on purpose. I do however wish they'd be somewhat more considerate about the web ecosystem.
I'd also wish they hadn't used their dominant position in ads to push Chrome as "a better browser" for years to everyone including people who already used modern browsers.
AMP is embracing and extending website hosting.
Google News is embracing and extending free web news outlets.
Chrome is embracing and extending the open-source web browser community.
Android is embracing and extending the open-source mobile OS development community.
I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.
Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.
Gmail is very far away from extinguishing open email, because that's such a huge target, but it certainly managed to make a dent. How many users have forever left the open ecosystem of smtp/imap/pop tools and service providers because of Gmail's growth? If Gmail hypothetically reached the market share necessary to mortally wound that open ecosystem, do we have any doubt that it would eventually do it?
And remember, email is the largest open ecosystem in my list. Where is the fully open alternative to iOS? Answer: it doesn't exist because Android captured all the momentum from the emerging community, and channeled it into a platform that is now closed for all practical purposes. In this case, extinction has already happened.
echo ".app" >> lists/google/domains
/usr/local/xxxxxxxxx/ufdbConvertDB.sh
service ufdbguardd reload
Problem solved. It is just a matter of fashion, black or white dress? Last few years, black fits better.
Not that I think HTTPS-everywhere is bad, I just think there are better ways to spend one's effort now that we have HTTPS-nearly-everywhere.
actually that's a bad example because even then my grandma knows to be careful. but she's tech illiterate enough that if she hears something is "safer" she will put blind faith in it.
This isn't an issue for me and you, the readers of HN, this is an issue for Jane Doe, who already has low standards, and is now going to lower those standards even further for a set of websites.
And that someone will tell them that those are safer URLs. And that gets misinterpreted and soon you have people saying they are special approved by google URLs that are guaranteed to be safe.
Regardless of who the article is for, tech illiterate people are going to ask "what is this new URL thing, and should I trust it?"
"What's .app?"
"it's like .com or .org, don't worry about it"
"it's like .com or .org, but it has some stuff in there to make it more secure, and it's managed by Google"
I'm also not the only person my grandparents get to ask about things.
I'm not saying this is all a bad thing. Just that we should be aware that giving things a little security can make people more careless.
EAP is a 7-day period in advance of General Availability (GA) during which domains can be registered immediately (not pre-ordered). EAP is a descending price ("Dutch") auction, meaning that prices start off high and then decrease as the auction goes on. The reason for this is to efficiently allocate domains to those who want them the most, rather than allowing desirable ones to be snatched up by those with the intent of reselling them. It's the concert ticket problem in domain name form.
We are currently in the first day of EAP. Each price tier lasts for the entirety of the day, and then ticks over to the next lower tier at precisely 16:00:00.000 Z. There are price drops over the first four transitions, and then the final three days are all at the lowest price tier. EAP is a one-time acquisition fee; you do not pay that on subsequent renewal. Different registrars choose different amounts for EAP tiers just like they choose different rates for base registration. EAP began today at 2018-05-01 16:00:00 Z and ends precisely when GA begins, which is at 2018-05-08 16:00:00 Z.
The confusion around EAP is stemming from the fact that many registrars are offering preorders for specific EAP price tiers (or GA). So while we're not yet in the lowest price tier, you can put in a preorder for the lowest price tier now, and the registrar will then attempt to register the domain for you within the first moments of that price tier once it begins. Whereas if you buy a domain in the current price tier, the registration goes through immediately and there's no element of chance like there is for preorders. Typically preorders that you don't win are refunded, though some registrars may charge non-refundable application fees.
Separately from all of that, there are also premium domains; those prices are orthogonal to EAP and affect renewal prices as well as initial registrations. EAP fees disappear entirely once we hit GA, but premium fees persist. Again, the intent of all of these is efficient domain allocation. You may be asking "why both?", and the answer is that both pricing mechanisms are good at solving different aspects of the problem of efficient allocation.
For a full list of registrars selling .app, see https://get.app and https://www.registry.google/about/register.html
(a) transferring wealth from the secondary market to registrars, and
(b) guaranteeing that desirable domain names get allocated purely on economic value terms, thus effectively shutting out non-profit-oriented enterprises from the best domain names. If someone with some quirky desire to name a domain name after their cat would like to grab the domain name and refuse to sell, this pricing scheme guarantees that such sentimental value counts for zero in the "efficient allocation" measure.
Both of these seem pretty shitty to me.
The current approach is essentially saying "if you really desire domain X badly, put your money where your mouth is".
Do you have an alternative proposal on how these desirable domains could be allocated more efficiently?
Anything that wouldn't have been swooped up by squatters will _also_ still be available when the early access period is over and everything is $20.
(Not joking.)
Apparently the "additional fee" for early access is extraordinarily high from some registrars.
For example -> https://imgur.com/a/E9WRqTI
$11,080
then $3,205
$1,625
$1,130
$690
$580
This sucks. This is like, truly evil.
There's two hard problems:
Naming things
Cashing [sic] : Paying for the right to name things
https://shop.gandi.net/en/domain/suggest?search=whatthefucki...
Taking recommendations for what to do with my new domain, donaldtrump.app
And also security. I know there’s an implicit trust of .com and so I wonder if seeing just google will lead to people thinking it’s safer. I have Metcalfe.rocks and more than once I’ve had people try Metcalfe.rocks.com
If I were in their position I'd probably use it for new deployments, with a low priority task for evaluating the possibility of migrating existing systems.
It baffles me that TLDs are at the mercy of private companies... I guess I should read more about the history of the internet to understand how this came to be.
Finally, maybe the management of authoritative DNS is one of the few applications for which a blockchain could actually make sense. Still pondering on the specific model though, does anybody know of existing projects in this direction?
Then I guess my perplexity is towards IETF in that they allow for two conflicting standards to exist.
What if I want to use local.my.app for development; Or, in a more textbook example, i want to use workstation-1.building-a.my.internal.my.app without https?
Because IANA decided to start selling off the web for companies to abuse.
> What if I want to use local.my.app for development;
You can switch to .dev... oh right.
uh... don't do that?
if you're developing locally or internally, use my.app.local or workstation-1.building.internal. If you want to use public domains for non-public things i guess go ahead, but you can't expect everybody else to support your weird thing. Or if you really need to run your internal dev stuff on public domains, get a certificate for it.
I agree with your larger point. For instance, I believe Google purposefully avoided implementing some privacy-preserving features in its QUIC protocol.
However, in this case, it was the ISPs and wireless carriers that fought against deprecating HTTP, while Google and Mozilla wanted to deprecate it. It's why I think they only enabled the HTTPS version of HTTP/2 in their browsers. The carriers and ISPs wanted the web to stay on HTTP so they can mine everyone's data, as they're already doing with the sites that have remained on HTTP.
namecoin
Here are the important dates to be aware of in 2018:
Mar 29 - May 1: Trademark holders can register .app domains (known as the "Sunrise" period).
May 1 - May 8: Anyone can register available .app domains for an extra fee (known as the "Early Access" period).
May 8 and onwards: Anyone can register available .app domains (known as “General Availability").
Having a name ending in '.sh' is less reliable than the output of file for identifying shell scripts, since any file can be named with that ending.
cat199 said '.sh' is unnecessary and that is correct. I am surprised that this is controversial. (except wait, no, this is the internet... I'm not surprised. ;-)
No. It works with some of them, because, as the parent wrote, it’s just the automated equivalent of "let’s look at content of the file and guess what it is". It’s not perfect, and so doesn’t always work. If you write "echo 42" in a file, `file` will only tell you it’s "ASCII text".
We humans are used to identify things with their name. `.sh` is not necessary to execute a shell script; but it’s so convenient you must have a good reason not to use it.
Ending the filename of a shell script in '.sh', while a useful and common convention, is unnecessary (I appreciate you that you acknowledge that) so using that to identify shell scripts is a heuristic, just like what file does.
Look, I don't want to argue about this. cat199 was catching downvotes for pointing out, quite correctly, that the '.sh' extension was just a convention, and, well... https://www.xkcd.com/386/
Filename extensions have always been a crappy hack to get around the omission of useful metadata associated with a file on some early filesystems. Gnome file viewer thing doesn't even sort by them!
It's currently showing as "Not Supported" even though they link to Google Domains from get.app.
It's mind-boggling to think they couldn't come up with a "coming soon" blip if somebody tries to look up a Google-owned TLD on Google Domains.
Can somebody explain this claim? How does HTTPS protect against malware? Does no malware use HTTPS, so it all gets blocked?
Authy OneTouch pushes you towards some fairly strong platform and vendor lock-in, which I always try to avoid.
Check out this older thread from 2014: https://news.ycombinator.com/item?id=8254757
"We're rolling out Google Authenticator support sometime in the fall." What happened? :(
Lots of registrars are in there that aren't part of the Early Access Program.
This individual assured me for today our available .app domain can be registered and fully usable for $11999. Tomorrow the price goes down to $2999 or something like that.
How is this possible if Landrush is only a preregistration expression of interest?
#!/bin/bash
DOMAIN="${1:-google}"
RESPONSE=$(
curl -XGET -s \
-H "Accept-Language: en-us" \
-H "Accept: */*" \
-H "Connection: keep-alive" \
-H "Host: domain-registry.appspot.com" \
-H "Origin: https://get.app" \
-H "Referer: https://get.app/" \
-H "User-Agent: Mozilla/5.0 (KHTML, like Gecko) Safari/537.36" \
"https://domain-registry.appspot.com/check?domain=${DOMAIN}.app"
)
echo "$RESPONSE" | sed "s/{\"/{\"domain\":\"${DOMAIN}.app\",\"/g" $ curl -sL https://domain-registry.appspot.com/check?domain=$DOMAIN.app
{"status":"success","available":true,"tier":"standard"}Also, if I say “dingus dot app” it confuses people because that’s not a mobile app, it’s a site or web app.
I went through a few of the registrars and got error messages that the TLD wasn’t supported.
Godaddy of course has a solidly gouging pre-registration price.
Set an alarm to park park park.
Edit: Godaddy isn’t straight up gouging. Seems like dictionary words are much more expensive than made up words or non-dictionary brand names.
Name.com somehow has a “buy it now” option in the 10k+ range. Curious how that works.
Happy hunting.
It'll drop to the regular price on 5/8.
It may just be on my end, but attempting to access the page using www.blog.google does not work, but blog.google works. The link may need to be changed...
> nslookup www.blog.google
Non-authoritative answer:
Name: ghs-svc-https-sni.ghs-ssl.googlehosted.com
Addresses: 2607:f8b0:4009:80b::2013
172.217.8.179
Aliases: www.blog.google
> nslookup blog.google
Non-authoritative answer:
Name: blog.google
Addresses: 2001:4860:4802:38::15
2001:4860:4802:32::15
2001:4860:4802:36::15
2001:4860:4802:34::15
216.239.32.21
216.239.36.21
216.239.38.21
216.239.34.21[1] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
[2] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
[3] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
Adding a new scheme would support all existing https websites on the internet today with no need to pay anyone money or rush to reserve domains.
This .app thing is needlessly difficult, and just a way for Google to push its brand on technology concepts en-masse, like the .dev fiasco. Now everyone in the world has to register a new domain (and make it work for their site) to make sure their URL is always secure.
Additional fee:
hackernews.app is available! CA $25.72 per year (pre-registration) CA $16,082.01 (early access)
Helluva fee.
https://www.name.com/preorder/app?domain=hackernews.app&tld=...
EDIT: Found the FAQ -
Does pre-registering a domain guarantee I'll get it? No. Pre-registering reserves your place in our queue for that domain. The instant the registration phase opens, we'll submit our list of registrations electronically. If you don't get the domain you've pre-registered, we'll refund the cost of the registration. Any application fees are non-refundable however.
IANA's decision to expand and auction off to-level donations was a horrible idea.
From what I can tell, the only enforcement is this gentleman's agreement between the browsers.
General information about HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
But you are right that it is a browser thing.
Is this some built-in gender bias?
dating.app returns this "available: true, tier: premium"
On the one hand, I support creating new platforms with security built-in by default, but on the flip side, the Chrome team just axed HPKP without even so much as bothering to try to refine it to mitigate the footguns.
I don't understand how the web-facing security decisions at Google are made. :/
I'm still disappointed. I don't feel expect-ct effectively covers the same use cases.
Otherwise... eh. In theory this becomes a home for web sites specifically related to apps. Certainly that seems to be what Google are suggesting. But are web apps "apps"? Is this native only? Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? (spoiler: no).
So it's just another TLD, really.
Both Google and Microsoft are both strongly in the "Yes" category here and are heavily pushing PWAs as a future of many types of apps. If a lot of PWAs also want to use .app as their TLD, that serves Google's purposes just fine, I'd imagine.
> Are Google going to be actively monitoring these to make sure the content is related to the .app TLD?
Where's the creativity in that? The internet decided a long time ago that it would rather do interesting things with TLDs than strictly enforce them; use the origins and "purpose" of a TLD as a loose guideline.
What's the harm in a restaurant deciding that .app fits their brand because they have the best apps (appetizers) in town?
Is it any worse than all the startups that have been using Chagos' country TLD .io without having anything to do with the atoll of Chagos? (Which of course is made worse by the funds from .io going to British corporate colonialists rather than directly to benefit anyone in Chagos. How many startups even think of that when paying for their hip domain name?)
Chagos should get direct control of .io, but it is a weird political fight.
One awareness campaign: http://www.thedarksideof.io/
I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.
It's fine if people want to raise awareness to Brits behaving badly. But saying .io should go to those people is misleading.
That is much closer to the ccTLD original intent than any of the British territories have seen (.io, .vg, etc). It's not misleading to suggest that the territory control their own ccTLD's destiny, given that was the original presumption of the early IETF and many of the original NICs.
Of course it's not a "natural" resource as a digital artifact of the internet economy, but that doesn't mean the ccTLDs weren't intended to be a resource to a specific locality, and that that specific locality shouldn't most control or best benefit when that ccTLD is exploited by foreign interests find a different use/meaning/domain-hacks for that TLD.
Edit: It appears this pre-registration doesn't even guarantee you'll get the domain. It just increases your chances :( I'm gonna pass...
101domains wanted to charge me ~13,000 USD for a domain / year.
gandi, however, allowed me to purchase it (the same domain!) for ~650 GBP / year.
What is going on?
Maybe 13k gets you a fully registered domain, and the £650 is like buying an option or a chance to be in the running.
Indeed, Gandi did not actually obtain the domain. But merely offered to try to bid with the money once the price of the domain reached that point where it was available for that price.
In my case, that failed. The domain was purchased by someone else at a higher price.
I now have to fight to get my money back into my bank account. Gandi made their life extra hard by not being fully transparent.
I was confused because gandi and 101domains did not explicitly state the phase. And gandi took my money and deducted it from my account but apparently did not actually obtain the domain yet.
It'll cost you a cool $1,790.88/year. I wonder how much of that goes to Google.
Edit: any recommendations for what to do with my new domain, donaldtrump.app?
Can any company get a tld made? Who's even in charge of that sort of thing?
apple.app
facebook.app
instagram.app
twitter.app
ycombinator.app *
snapchat.app *
producthunt.app *
whatsapp.app
amazon.app
microsoft.app
google.app
hotmail.app *
dropbox.app
intercom.app *
pivotal.app *
tesla.app
dell.app
ibm.app *
* AVAILABLE
Google throws down a few hundred grand to get the .app domain, in concert with modifying their web browser to deliberately mark others' traffic as "Insecure" (it is not necessarily!), and reaps the fees now and in perpetuity ever year thereafter for maintaining a simple database of DNS glue entries which you literally could maintain using MS Access (by which I mean, the database schema and maintainence is bog-simple).
How is the coming Chrome modification not "tying"? Anyone familiar with anti-trust laws care to comment?
AFAIK Google does not have a monopoly on .app registrations:
Many registrars will sell .app names, but they pay a portion of every sale to Google.
How does that work? I thought they needed cooperation from browser makers.
Edit: explained here: https://news.ycombinator.com/item?id=16968262
However, they will get extra fees from any .app domain registrations.
HTTP traffic -is- necessarily insecure. It's trivial for anyone on your network to run Wireshark and see/modify all of your traffic. And a lack of HSTS leaves your site potentially vulnerable to SSLstrip.
> modifying their web browser to deliberately mark others' traffic as "Insecure"
I'm assuming the parent comment meant how Chrome marks HTTP connections as insecure; they're not marking TLD's that aren't .app as insecure.
What?
add a special extra greener bar for .app sites
That would be really weird, considering that most Google sites are not .app, and would be quite a pain to change. Suddenly every competitor to their services get a special greener bar for a few bucks?
The problem is either the “not necessarily” part is wrong (in regard to flagging HTTP) or the criticism is directed at a fantasy that isn't actually occurring (in regard to flagging things that aren't .app). Either way, the criticism is defective.
> Google throws down a few hundred grand to get the .app domain,
> in concert with modifying their web browser
> to deliberately mark others' traffic as "Insecure"
> (it is not necessarily!),
> and reaps the fees now
This is what patrickg_zill's comment said, just with some newlines and emphasis to make it more understandable. The not necessarily does not refer to HTTP, it refers to non-.app domains. And there is no "criticism is directed at a fantasy", there is a cynical prediction which is completely possible in all respects. You---or I---may think that that'll never be the reality, but regardless, that's what the comment said, and the other commenter misunderstood. I don't get why I get downvotes and criticism for this.
They -could- have meant .app, but we'd need the guys word to know for sure. It's not as straightforward of a comment as you think it is.
Sure, but labeling a site as “Possibly not secure” wouldn’t be a very effective way of communicating the risks to users.
That's just on GoDaddy.
"EAP is a one-time acquisition fee; you do not pay that on subsequent renewal."
We're not expecting to make our money back on this one. And these amounts are a drop in bucket compared to many other Google products anyway.
So a cynical profit motive is not why we're doing it. We're doing it for the stated reasons, to move security forward on the Web; see https://security.googleblog.com/2017/09/broadening-hsts-to-s... and https://security.googleblog.com/2018/02/a-secure-web-is-here...
Also, I could talk your ear off about the design of our infrastructure for hours. Suffice it to say, it's a lot harder than you're making it out to be, particularly as regards to scaling. Our registry platform is open source, so feel free to inspect the code at https://nomulus.foo . And that's not even getting into DNS hosting, which involves a very large number of instances distributed around the entire globe.
However, 10 years of 1 million domains, even if Google's cut is only $1 out of the registration price, is still $10 million per year * 10 years = $100 million.
If Google's own registry is used and you capture more of the ($17/year ?) domain fee, it goes up by multiples of that.
Correct me if I am wrong, but serving the DNS entries of .app will be almost the same as serving up a DNS entry for another domain like .com: the HSTS/https-only requirements will be set up in the browser, not the DNS server.
And serving DNS has been handled successfully and profitably by Namecheap/GoDaddy/Moniker et al for years.
[1] https://abc.xyz/investor/pdf/2018Q1_alphabet_earnings_releas...
Note that registrars ultimately set the pricing that you see, which is why it's different across different registrars, same as if you wanted to buy, e.g., a .com domain.
That's, if anything, less reassuring.
Google doing it to make money makes sense. THey are a for profit company, it's what they do.
Goodness of our hearts just makes me suspect it's more evil. Quit being evil google.
Ok, ok, I'll pay GOOGLE, the owner of the internet, for doing this now.