
Introducing .app, a more secure home for apps on the web - daniel-alex
https://www.blog.google/topics/developers/introducing-app-more-secure-home-apps-web/
======
segmondy
Yeah, the play store of websites. Where we need to get permissions and
approvals and can get banned. No thanks, Google is trying to bring their
walled garden idea for websites. Don't trust Google on this. They just turned
off their service rather than support signal, what if signal was signal.app
would they block em? Don't trust Google on this. It's a decent idea but no.

~~~
brlewis
Is there any precedent for a TLD owner doing what you describe? I think this
is HSTS preload and nothing more.

~~~
dingo_bat
Yes:

[http://www.cbsnews.com/news/daily-stormer-being-dumped-by-
go...](http://www.cbsnews.com/news/daily-stormer-being-dumped-by-godaddy-
apparently-seized-by-anonymous/)

[https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-
stor...](https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stormer-
because-of-what-it-wrote-about-charlottesville-victim.html)

~~~
CydeWeys
Both of those are articles are about registrars refusing to do business with
one specific hate group. They're not about registries.

~~~
dingo_bat
Aren't Google and Godaddy both TLD owners?

~~~
bastawhiz
Yes, technically. But GoDaddy's GTLD (.godaddy) isn't available for public
use, so your point is moot.

~~~
dingo_bat
My point is that google will ban your website off the internet in whatever way
possible for them, if they don't agree with what you're saying. They have
demonstrated this as I linked. Just because their role is now TLD owner,
doesn't mean they will not do what they think is necessary.

------
dmurray
> The big difference is that HTTPS is required to connect to all .app
> websites...Because .app will be the first TLD with enforced security made
> available for general registration, it’s helping move the web to an HTTPS-
> everywhere future in a big way.

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.

~~~
CydeWeys
Tech lead of Google Registry here. I can help answer some questions.

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...](https://security.googleblog.com/2017/09/broadening-hsts-to-secure-
more-of-web.html)

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.

~~~
carreau
Trying to register via google domain says "Google Domains does not support the
.APP ending". Is that on purpose (Google domain is listed on get.app as
compatible) ? A cache issue ?

~~~
CydeWeys
I can't speak specifically for Google Domains as that's a completely different
team that we have limited interactions with.

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.

~~~
dcosson
Wait, so you put out this launch announcement telling people they can early
register .app domains. It links to a bunch of partners including Google
Domains, but you have no idea whether I can actually register a domain there
or not? Why promise it in your launch announcement then?

~~~
bigiain
They put this announcement out so they can sell spots on the "Priority Pre
Registration" list for $16,000.

It's just another fucking cash grab.

~~~
nl
For end users it costs ~$20, right now from one of the EAP registrars.

Outrage is great, but it's a good idea to read before firing off like this.

~~~
foobarbazetc
That’s misleading. That won’t fire until May 9 (GA). If it’s left.

(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.)

------
makecheck
Sigh. As I’ve said before, we need stronger identity profiles and user agents
that verify _much_ more than legitimate-sounding names. A name _alone_ should
effectively be treated like it could be _completely and utterly fake_ ,
period.

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.

~~~
CydeWeys
HTTPS and SSL certificates are primarily used for encrypting the connection,
thus protecting your data from snooping and modification in transit. They are
not actually that useful for authenticating identity. Users tend to simply
ignore the padlock icon, which is why Chrome is moving away from an
affirmative security display model (which users don't pay much attention to)
to displaying prominent warnings for insecure or hijacked connections, which
users do pay more attention to. SSL certificates' inability to properly
authenticate identity is also why many of the largest tech companies in the
world do not even bother with EV certificates (e.g. Google, Amazon, and
Facebook for starters).

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...](https://events.google.com/io/schedule/?section=may-8&sid=7ac8be59-1ecc-4d90-aea5-e62deab5ee7f)

~~~
danShumway
> 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.

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.

~~~
cornholio
> Are we just going to keep creating new tlds over and over for eternity?

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.

~~~
Borealid
Wouldn't it be easier to just raise domain registration /renewal prices,
making squatting a poor return on investment?

~~~
cornholio
I think that would hurt small businesses more than it would dissuade squatters
of truly valuable domains. The trick is to move money from the squatters to
the public and domain owners, not to the registry itself, that is basically
just another big squatter.

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.

------
chatmasta
If it’s not clear from the article, HTTPS is required for all .app domains,
which Google accomplished by adding the .app TLD to the default chrome HSTS
preload list.

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.

~~~
snarfy
How does that work in say, Firefox?

~~~
detaro
Exactly the same, the preload list data is public and used by all the major
browsers.

~~~
chatmasta
What is the "single source of truth" for the HSTS preload list? It must be on
a server somewhere... who runs the server? Which browsers use this list by
default?

~~~
CydeWeys
See [https://hstspreload.org/](https://hstspreload.org/). And all major
browsers. Chrome, Firefox, Safari, Opera, IE, and Edge for starters.

~~~
chatmasta
Thanks for that. But that site doesn’t seem to mention the loading process
across browsers. Generally speaking , do the major browsers ship the HSTS list
compiled into the build? Or do they update it at runtime? If so, from where do
they fetch the updated list, and how often?

~~~
CydeWeys
Yes, the major browsers ship the HSTS preload list compiled directly into the
build. That's why it can take months for a domain to, once submitted, actually
be preloaded across a majority of users -- because the browser
nightly/beta/release build cycle alone is 2-3 months, plus the time that it
takes the average user to update their browser.

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.

------
scarface74
Supporting https is only an infinitesimal part of what makes downloading apps
on the internet like playing Russian Roulette. It still doesn't prevent
unsuspecting users from downloading malware, adware, ransomware, and apps that
siphon user data. It also doesn't prevent users of sites depending on third
party ad networks from being a victim of the same vulnerabilities they are
now.

~~~
benologist
Later google will launch .ampp for apps that are certified to only have Google
and their thousands of partners sharing your PII 'securely'.

~~~
therein
That honestly doesn't even sound like a joke. I'd believe it if you said
that's a quote from the article.

------
patrickg_zill
Is being cynical about this allowed?

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?

~~~
CydeWeys
.app was a tiny bit more expensive to acquire than that ...
[http://www.businessinsider.com/google-just-
paid-25-million-t...](http://www.businessinsider.com/google-just-
paid-25-million-to-buy-the-entire-app-web-domain-2015-2)

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...](https://security.googleblog.com/2017/09/broadening-hsts-to-secure-
more-of-web.html) and [https://security.googleblog.com/2018/02/a-secure-web-
is-here...](https://security.googleblog.com/2018/02/a-secure-web-is-here-to-
stay.html)

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](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.

~~~
patrickg_zill
Thanks for the correction about the price.

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.

~~~
venning
Alphabet made $31B in revenue last _quarter_. [1] CydeWeys already addressed
their costs, but $100M over 10 years doesn't exactly sound like something they
get out of bed for, especially considering they're already out $25M and they
really will have expenses to cover for this.

[1]
[https://abc.xyz/investor/pdf/2018Q1_alphabet_earnings_releas...](https://abc.xyz/investor/pdf/2018Q1_alphabet_earnings_release.pdf)

------
CydeWeys
I want to clarify some details on how the Early Access Program (EAP) works
because I'm seeing some confusion here in the comments.

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](https://get.app) and
[https://www.registry.google/about/register.html](https://www.registry.google/about/register.html)

~~~
paultopia
Both pricing mechanisms are great at:

(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.

~~~
sah2ed
Desirable domains are by definition scarce -- there is not enough of them to
go round to those who desire them.

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?

~~~
paultopia
"Efficiently" is a concept defined only by your target. If your target is
economic value, then, sure this kind of auction does a pretty good job at
allocating efficiently with respect to it. If your target is something like
desire-satisfaction, or promoting novelty/creative use, then it might be worth
trying to think about ways to preferentially allocate to people willing to put
in more effort too, or, e.g., introduce some kind of lottery system for some
domains for non-commercial uses.

~~~
cobbzilla
In what units do you measure "desire-satisfaction" and "promoting creative
use"? How do you know that an outcome was optimal?

------
panarky
Took me a while to figure out that Google Domains isn't participating in the
Early Access Program.

Apparently the "additional fee" for early access is extraordinarily high from
some registrars.

For example -> [https://imgur.com/a/E9WRqTI](https://imgur.com/a/E9WRqTI)

~~~
gadders
I just tried to buy one. Got an email saying I'd be invoiced on allocation of
that domain to the registrar. WTF does that mean? How can they take my money
if they don't even know they'll have the domain to sell?

~~~
CydeWeys
I believe that, as a general policy, registrars refund your money if they
don't actually manage to acquire the domain name on your behalf.

------
ocdtrekkie
I'd be pretty uncomfortable basing my online identity on a domain where the
registrar is already picking which web standards do and don't work.

------
ahmedfromtunis
Barely related question: does Google plan to deploy the .google gTLD for use
in its services, i.e. will mail.google.com become mail.google, and
drive.google.com change to drive.google just like they did for blog.google and
registry.com?

~~~
pducks32
I think they’d like to possibly but there are concerns. I have had trouble
with vanity tlds and I can imagine with google being so ubiquitous, there
could be so many issues.

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

------
simon_acca
Arbitrarily picking web standards seems like an abuse of power. If this is the
direction in which they want the internet to steer (a great one as far as I’m
concerned) Google should advocate for the deprecation of HTTP in the
appropriate bodies instead though.

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?

~~~
therealmarv
It's not arbitrarily. You can use the standard HSTS to be applied domain wide
[https://hstspreload.org/#tld](https://hstspreload.org/#tld)

~~~
simon_acca
That’s fair, given that HSTS is after all a standard itself and Google is
merely applying it.

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?

~~~
s2g
Arbitrarily across an entire TLD.

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.

~~~
underyx
RFC-6761 [1] reserves .example, .invalid, .localhost, and .test — the latter
two seem like nice alternatives.

[1]:
[https://tools.ietf.org/html/rfc6761](https://tools.ietf.org/html/rfc6761)

------
thisisit
In case someone is wondering about availability:

[https://www.registry.google/](https://www.registry.google/)

 _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")._

~~~
corobo
Anyone know of any registrars supporting the early access registration? My
usual haunts all say they don't support .app

~~~
_zie
Confirmed that gandi.net does support it

~~~
corobo
That must have been a just-missed thing - I checked Gandi just before my post

------
dmart
Excellent, this will surely cause no confusion with macOS executables.

~~~
sinatra
Just like .com didn’t cause confusion with DOS and Windows .com executables.

~~~
makomk
It helped a little that .com executables were pretty much obsolete by the time
the web became common, but that was still a pretty nice gift to early malware
authors.

~~~
bdcravens
I remember when I first started hearing about the web (around circa 95) and I
was playing alot with DOS thinking that the two were connected.

------
JasonSage
Why is Google launching a TLD and you cannot purchase it through Google
Domains?

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.

~~~
icebraining
From another post in this thread, ICANN rules prevent the two from
coordinating.

------
dumbmatter
Mandatory HTTPS? This discussion from 2 days ago seems relevant:
[https://news.ycombinator.com/item?id=16951831](https://news.ycombinator.com/item?id=16951831)

------
rebelde
> HTTPS is required to connect to all .app websites, helping protect against
> ad malware

Can somebody explain this claim? How does HTTPS protect against malware? Does
no malware use HTTPS, so it all gets blocked?

~~~
skywhopper
It doesn't. They are likely referring to some malware attack vectors that rely
on hijacking local DNS or routing between the web browser and the server (eg,
at your coffee shop wifi, or your ISP injecting junk into the HTTP stream),
and requiring HTTPS makes such attacks a little bit harder. But there are
plenty of other ways to send "ad malware" to browsers that work just fine over
HTTPS. And as for ISPs, they could easily (in some places, they likely do, and
someday most probably will) require you to install their own custom certs in
your trusted store and MITM all your web traffic. TLS 1.3 tried to work around
this threat as well, but enterprise security people who "need" to monitor all
traffic in and out of their network blew that up. But your browser will show a
green lock icon, so it's fine.

------
ihuman
Is google domains not taking preorders? It says the .app extension is not
supported.

~~~
warent
This was ironic to me too. I had to preorder app domains from a third party
called Marcaria. 101domain supports it as well.

------
ted0
Ted from Namecheap here - we've been excited about this TLD launch for a
couple of years now and we plan to sell .app domains! Stoked it's launching
very soon.

~~~
uptown
Ted, any reason why you don't permit pasting the 2-factor auth code into the
input box?

~~~
ted0
trust me, it's on the backlog to fix.

~~~
tokyodude
Is everything on the backlog? Still not supporting long DKIM keys. Still using
deprecated and discouraged SMS as 2factor. Are your margins really that thin?
It's been years :(

~~~
ted0
We introduced an alternative to 2FA SMS - Authy OneTouch. We're working on
adding TOTP as well.

~~~
et-al
Hey Ted, since you're here, may I please suggest that the future
implementation of 2FA _not_ require a separate app? Even though Namecheap is
using Authy OneTouch, it still requires a dedicate app, which is unnecessary.
Thanks.

~~~
ted0
We partnered with Authy/Twilio on this integration to try something new.
Totally get that we need additional options.

~~~
et-al
Thanks for the reply Ted. Looking forward to something more standardised!

------
guessmyname
Here is a small script for the Terminal lovers.

    
    
        #!/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"

~~~
hk__2
Simpler:

    
    
        $ curl -sL https://domain-registry.appspot.com/check?domain=$DOMAIN.app
        {"status":"success","available":true,"tier":"standard"}

------
magoon
This is confusing because Mac apps literally end in that extension, and if I
say Messages.app you would know what I mean.

Also, if I say “dingus dot app” it confuses people because that’s not a mobile
app, it’s a site or web app.

~~~
askvictor
Old DOS executables (actually, commands) (which still run on Windows) ended in
.com ; there was an overlap with the Internet when they were still quite
common (command.com was how you started a command prompt on windows 95), and
no-one seemed to get confused

~~~
magoon
This is a fair & fun point, however maybe a bit of a stretch to compare here;
DOS binaries were almost all .EXE well into DOS 3.x, which was many
generations before Windows 95. I would say the exception to that had been
command.com

------
odammit
Registration opens May 8th.

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.

~~~
runnr_az
.app is in the sunrise phase right now -- I think all the registrars pay the
same wholesale rate and it's possible that the actual price is set as well.

It'll drop to the regular price on 5/8.

------
enzanki_ars
[https://blog.google/topics/developers/introducing-app-
more-s...](https://blog.google/topics/developers/introducing-app-more-secure-
home-apps-web/)

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

------
limeblack
Not surprisingly Google has already prevented registration(pre pre
registration) of anything related to their services alphabet[1], chrome[2],
chromeos[3], etc... I guess you can do whatever you want when you own the
domain extension.

[1]
[https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...](https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=alphabet.app)

[2]
[https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...](https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app)

[3]
[https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...](https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app)

~~~
QasimK
> Mar 29 - May 1: Trademark holders can register .app domains (known as the
> "Sunrise" period).

------
ashwinpp
Note that most registrars participating in EAP or landrush charge a non-
refundable fee, which is major chunk of the price increase from day 7 to day
1. It doesn't seem that there is "no cost" to participating in this period if
one doesn't get the domain name.

------
peterwwillis
Why can't they add a new URL scheme "secure://" to Chrome that will only
support HTTPS?

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.

~~~
SahAssar
How would "secure://" differ from "[https://"](https://")?

~~~
peterwwillis
Most people don't know what [https://](https://) means, and is often confused
with [http://](http://). Plus, [https://](https://) has allowed people to do
things like click through certificate warnings, which secure:// should never
do. Finally, secure:// should require all standard best practices for the
security of web apps, first simply by refusing to render obviously insecure
sites, and then by requiring extra parameters.

------
jest3r1
_Starting today at 9:00am PDT and through May 7, .app domains are available to
register as part of our Early Access Program, where, for an additional fee,
you can secure your desired domains ahead of general availability._

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=...](https://www.name.com/preorder/app?domain=hackernews.app&tld=app)

------
dberg
Does GoDaddy refund if you dont get the domain ?

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._

~~~
scosman
Is the "Early Registration Fee" considered a "cost of registration" or
"application fee"? It's listed as "Early Registration Fee (non-refundable)" in
the cart.

------
dmitriid
So, Google paid big bucks to secure a juicy top-level domain name. Now it says
it's good because "hey, if you pay us money, we'll get you in our registry,
call you secure, prominently display you in search (not now, but logical next
step), and pretend it's all for great good and not to extend and protect our
dominance".

IANA's decision to expand and auction off to-level donations was a horrible
idea.

------
thedangler
So what registrars are taking part Early Access Program?

~~~
CydeWeys
See the list here:
[https://www.registry.google/about/register.html](https://www.registry.google/about/register.html)

------
fulafel
How does this work technically? What prevents use of plaintext http on these
domains? The preloading seems like a browser specific feature.

~~~
therealmarv
HSTS can be enabled for whole domain. See here:
[https://hstspreload.org/#tld](https://hstspreload.org/#tld)

General information about HSTS:
[https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

But you are right that it is a browser thing.

------
tenaciousDaniel
Still waiting for them to release the .dev domains

~~~
skunkworker
Everyone that has been using that for local development agrees. Though the
writing on the wall has been there for awhile - [https://iyware.com/dont-use-
dev-for-development/](https://iyware.com/dont-use-dev-for-development/)

------
koyao
Why does "his.app" cost $499.99 for pre-registration, but "her.app" only costs
$249.99? :)

Is this some built-in gender bias?

~~~
domainhunter
I am new to domain trading. I have one question - Would I be sued (i.e is it
legal?) if I buy some .app domains related to some popular apps of my country
and list their google play store and apple store link with some ads on those
domains?

~~~
icebraining
I don't know if it's _illegal_ , but unless you have a trademark on those
names, you're almost certain to lose them.

------
IloveHN84
Are already sex.app and dating.app registered?

~~~
guessmyname
sex.app returns this _" available: false, reason: in use"_.

dating.app returns this _" available: true, tier: premium"_

~~~
ThatHNGuy
why is it premium?

~~~
kowdermeister
Because it says dating :) Registrars can device on a set of names the wish to
withhold, they are usually dictionary names with great interest involved.

------
eganist
Moves like this intrigue me.

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.
:/

~~~
ovao
There are motivating reasons for that[0]. The Expect-CT header is its
replacement, and is getting picked up by recent versions of Chrome.

[0]: [https://scotthelme.co.uk/im-giving-up-on-
hpkp/](https://scotthelme.co.uk/im-giving-up-on-hpkp/)

~~~
eganist
Yep. I contributed rather substantially to one of those reasons with a talk on
abuse cases for hpkp at defcon two years back.

I'm still disappointed. I don't feel expect-ct effectively covers the same use
cases.

------
theandrewbailey
What if I put my app's REST backend on my .app domain? Are .app domains only
allowed to host brochureware?

~~~
CydeWeys
The only restriction with .app domains is that HTTPS is enforced when
connecting from a web browser. We definitely encourage you to use .app for
more than mere brochureware, and of course we also encourage you to encrypt
all APIs (REST or otherwise). This will be enforced by browsers if said APIs
are being hit from a webpage.

------
laktek
Finally! I've been waiting for this for the last 11 years
[http://www.laktek.com/2007/05/18/app-tld-for-web-
application...](http://www.laktek.com/2007/05/18/app-tld-for-web-
applications/)

------
superkuh
HSTS seems to require the website to conform to what google defines as 'Serve
a valid certificate.' Does this mean that self-signed certs will not be
acceptable for a .app domain and centralized certificate authorities will be
required?

~~~
CydeWeys
Validity of SSL certificates is enforced by web browsers. If you choose to
allow your self-signed certs in your browser then it will work for you, though
of course not for other people.

------
untog
The defining feature here seems to be HSTS - all .app domains will connect via
HTTPS by default, and never try HTTP. Which is nice.

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.

~~~
WorldMaker
> But are web apps "apps"?

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?)

~~~
MichaelGG
Would Chagos get .io if it wasn't British Indian Ocean Territory?

~~~
WorldMaker
Chagos is the preferred name for the atoll that the British named to be
"their" Indian Ocean Territory in the colonial empire era.

Chagos should get direct control of .io, but it is a weird political fight.

One awareness campaign:
[http://www.thedarksideof.io/](http://www.thedarksideof.io/)

~~~
MichaelGG
I mean why would Chagos, free of ever having the British, end up with IO as a
country code?

~~~
WorldMaker
Well, there aren't any obvious alternatives, for one thing: .ch is
Switzerland, .ca is Canada, etc.

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.

~~~
MichaelGG
Ok but that sort of takes away the entire argument that .io "belongs" to these
people somehow. It doesn't, it's purely a political issue. It's not some
natural resource or anything they'd have claim to otherwise. (And seems that
Mauritius might have claim, meaning no extra ccTLD.)

It's fine if people want to raise awareness to Brits behaving badly. But
saying .io should go to those people is misleading.

~~~
WorldMaker
.vi is controlled directly by residents of the US Virgin Islands. The primary
contact address is on St. Thomas, and the NIC follows some pretty restrictive
domain naming rules to favor the residents of the US Virgin Islands. It's run
by the local telecom and presumably all money generated from .vi revenue goes
to the island economies.

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.

------
z3t4
I think this domain will be very popular as app means app in almost every
language. I hope Google will do something about the domain snapping or all
good names will be taken (and not used).

------
stevoski
What's the pricing? I couldn't find this info on the site.

~~~
asaph
On GoDaddy at least, pricing seems to vary by domain name. beer.app is
$1,999.99 while hackernews.app is $16.99. You can check pricing on individual
.app domains here: [https://www.godaddy.com/tlds/app-
domain](https://www.godaddy.com/tlds/app-domain)

Edit: It appears this pre-registration doesn't even guarantee you'll get the
domain. It just increases your chances :( I'm gonna pass...

~~~
jmelloy
How would it? Godaddy can't buy the domain until General Availability, so they
can't guarantee that you'll get it. Someone else could buy it first.

------
sabertoothed
It is very strange.

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?

~~~
jameslk
I would assume one is for early phase registration (101domains - May 1-7), and
one is general registration (gandi - May 8). If the domain isn't registered in
the early phase, you'll be in line to have it registered on May 8.

~~~
sabertoothed
It looks like it, indeed.

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.

------
z3t4
Does this mean all request's will go via Google servers ? Like cloudflare ? Or
how else would they enforce httpS ?

~~~
timdavila
No. The TLD ".app" is on the HSTS preload list shipped with the browser, so
the browser will only accept connections over SSL. It's up to you as the
domain registrant to make sure your site supports it.

------
keyle
Seen on name.com...

[https://imgur.com/kYyNQQg](https://imgur.com/kYyNQQg) ?!

------
z3t4
I wish Google or someone else with a lot of money would go and register every
word in the English dictionary and then sell domains for reasonable prices.
And there should also be a rule against domain squatting, for example only
allow five domains per person/company.

~~~
solarkraft
What if we just sell TLDs directly to consumers?

~~~
z3t4
I think it's important that any TLD is open for registration of domains. For
example if Facebook bough .book they should need to allow others to register
under it.

------
koolba
If there's anyone with an x-rated business idea, f.app is available though
it's marked as a "premium" domain, likely due to the single letter.

It'll cost you a cool $1,790.88/year. I wonder how much of that goes to
Google.

~~~
ratsimihah
I mean, what kinda of app want's to be called Fapp for $1500+/yr?

~~~
always_good
An app that wants a memorable domain.

~~~
russh
Well I'm out, Cr is already taken.

~~~
ratsimihah
Well crap

------
komali2
Get.app said the domain I want is available, but none of the linked websites
said they supported that tld

Edit: any recommendations for what to do with my new domain, donaldtrump.app?

~~~
ohitsdom
Right beneath the domain available message should have been a note that these
domains aren't available for purchase until May 8th.

------
pknerd
so a web based product can be called an _app_ and get hosted for a certain
*.app domain?

------
kiddico
I was not aware .google was a tld.

Can any company get a tld made? Who's even in charge of that sort of thing?

~~~
notatoad
yes, any company willing to pay the application fee of $185k and able to pass
a review as "capable" of operating a TLD can register a TLD. ICANN is in
charge of it.

[https://newgtlds.icann.org/en/about/program](https://newgtlds.icann.org/en/about/program)

------
runnr_az
Any plans to support IDNs?

------
kahnpro
No, Google. Just no.

------
AngeloAnolin
Just for fun, I tried these domain names via the url get.app:

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

~~~
domainhunter
Would I be sued (i.e is it legal?) if I buy some .app domains related to
popular apps of my country and list their google play store and apple store
link with some ads on those domains?

~~~
therealmarv
If your intention is to make some money and they have trademarks and already
existing similar domains you are not acting legal! There were other people who
already had the same thought as you... they failed!

------
tomc1985
Three arbitrary letters in a list of TLDs and they call it "innovation"...

~~~
carussell
Did you fabricate a quote? (And if so, why?) Neither "innovation" nor any
derivatives of "innovate" appear in this post.

------
peterbe
I go to [https://domains.google.com](https://domains.google.com) and search
for my desired .app domain and it says "Google Domains does not support the
.APP ending" :(

------
fiatjaf
Why do we have TLDs at all? If ANY COMBINATION OF LETTERS is now a TLD, we
should be able to register myname.whatever if I want to, or in fact just
whatever as a domain.

Ok, ok, I'll pay GOOGLE, the owner of the internet, for doing this now.

------
dvfjsdhgfv
Why on earth should I do it? Give me one _good_ reason; enforcing HTTPS
doesn't count as one. And yet, it seems like HN crowd is queuing o buy
these... Are you planning to get them so that you can sell them at a higher
price later? What makes you think this product of Google does better than
Google+?

