Introducing .app domain names and how to secure them (Google I/O ’18)
Articles Blog

Introducing .app domain names and how to secure them (Google I/O ’18)

August 30, 2019

afternoon, everyone. Thanks for joining us out here. Today, we’re going to be
introducing .app domain names and how to secure them. I’m Ben McIlwain. I am the Lead Engineer of Google
Registry and the Co-Product Manager of the .app launch. And we’re going to be explaining
a little bit later what the Google Registry is exactly. ADRIENNE PORTER FELT: Hi. I’m Adrienne Porter
Felt. I’m an Engineering Manager and a longtime Engineer
on the Google Chrome team. Now, about a year ago, I think–
yeah, a year ago, Ben came to my team and I with an idea. And now, he works on
the Registry team. And they had an
idea that they were going to be launching this
TLD, Top Level Domain, so what we’re going to
be talking about today. And the idea was to use it to
make memorable and meaningful domain names. Now, I assume that
all of you here are like short,
meaningful domain names, because they tie into your
brand and help users get back to them. We also like them in terms
of usability of the web. We think that URLs are easier
to use if the domains are something that people can
actually remember, and ideally, differentiate between the real
brands, when they’re trying to actually get to that website,
versus other content that might be spam, phishing, or spoofing. But that wasn’t all. It wasn’t just about coming up
with meaningful and memorable domain names. Ben was also aware of the fact
that Google, for a long time, has been pushing
on HTTPS adoption. And he wanted to use
this feature launch as a way to tie into that
and help make the web safer. HTTPS is important,
because it keeps our users’ content private and secure. HTTPS provides encryption
between the client and the server such that
anyone in the middle, like the internet service
provider or someone else who’s on the same wireless
network, isn’t able to either eavesdrop
on the information while it’s in
transit or modify it. And pushing on HTTPS adoption
has been a big effort at Google, and in
fact, more or less across the security community
for the last several years. Back in early 2015, which is
when I started working on this, we saw that only about a
quarter to a third of pages loaded in Chrome were HTTPS. So at that point, HTTP
was still dominant, and HTTPS was the exception. Well, moving forward
to today, I’m really excited that we’re
at a point where about 75% of all page loads in
Chrome are now HTTPS. So we’ve seen a huge shift. And now, we’re focusing on,
how do we get everything to be all HTTPS? How do we get that
last little chunk? Looking back at 2014,
Google premiered an HTTPS ranking boost. So the idea at the time
was that websites would get a bump if they supported HTTPS. Let’s Encrypt, which
is an awesome service that you should check out
if you haven’t already, they provide free
HTTPS certificates, as well as tooling to make it
easy to manage certificates, launched in late 2015. And Let’s Encrypt
helped a lot of websites get online,
particularly websites where the developers were
not able to previously afford certificates. Even though $10 to
$15 sounds cheap, some people still
couldn’t afford it. Also in late 2015,
Google started indexing HTTPS
websites by default, meaning that if a
website was available both over HTTP and HTTPS, we
would index the HTTPS version. We also released a
transparency report showing that at the time,
only about a quarter of the top 100 sites
supported HTTPS by default. And now, it’s at 83. Also near and dear to my
heart, starting in 2017, Chrome started labeling
HTTP websites as not secure in the URL bar if
they had a password form field or a credit
card form field, because those are particularly
sensitive data types. We ratchet that up a little bit. In May 2017, we started
labeling more pages as not secure if they
were any HTTP page viewed in incognito or any HTTP page
with any kind of form field on it. And we have recently
announced that starting in Chrome 68, which is in July,
all HTTP pages will be labeled as not secure in the URL bar. All right, so Ben
was aware of this. And he was really excited
about HTTPS himself, as was the rest of his team. And so they wanted to bring
these two things together– a product that encourages
memorable domain names, as well as the security
features of HTTPS. So Ben, tell them
what the idea was. BEN MCILWAIN: Yeah, all right. So today, we are launching the
world’s first entirely secure, all HTTPS, open,
top-level domain. And I know that’s a
little bit to unpack, so we’re going to explain that. So first, what’s a
top-level domain? Let’s look at that. So a top level domain is the
last part of the domain name. It’s what’s right
of the final dot. Top-level domains are
run by registries, like Google Registry. That’s my team, for instance. And that’s in contrast to
a domain name registrar, which is where you would
go to buy a domain. So a registrar will sell
domains, some variety of different top-level
domains, whereas the registries run their own TLDs. And that TLD is only
run by that registry. So you don’t interact with
the registries too much. But we’re kind of the big
database behind the scenes, running the domains. So let’s go through some
examples of top-level domains– really obvious ones,
.com, .net, .org– these are the
original generic TLDs. And the important thing
about them is, they are open. So anyone can register
them without restrictions. And I’m sure many people
here have some of those. Next up, we have
the sponsored TLDs. These have restrictions
on registration. They’ve also been out–
these ones, at least, have been out for
a very long time– .edu, .gov, and .mil. And for instance, if
you want a .mil domain, you have to be associated
with the US government. So that’s the restriction. And then a third category
would be the country code top-level domains. So some examples would
be .uk, .de, and .io. And you know it’s a country
code top-level domain because it has two characters. So if you didn’t know, .io is
not the generic TLD for coding, even though that’s
how it’s used. It’s really for the British
Indian Ocean Territory. And whether or not you can
register a domain name on these depends on the country. Some are completely
open, and some have restrictions where you have
to be a citizen of that country to register. And then finally, we get
to the most recent ones, the new generic TLDs. So here, we have .how,
[INAUDIBLE] and .google. And these started
being launched in 2012 in the ICANN first expansion
round of top-level domains. And there might be
another one coming soon. And these three examples happen
to be ones run by my team at the Google Registry. And one interesting
thing to note here is, [INAUDIBLE] is
actually a Unicode TLD. So if you haven’t seen any
of these out in the wild yet, just know that they’re around. And these are a big mix of open,
restricted, closed, and brand TLDs– like, Google is a brand TLD,
so we’re the only people who register domain names on there. And in addition to all of these
existing ones and thousands of others that already
exist, today, specifically as of 9:00 AM this
morning, there is a new top-level
domain on the web. And that top-level
domain is .app. So yeah, today, we– [CHEERING] Thank you. So yeah, so we’re
introducing .app. .app is the new home on the
web for mobile apps, web apps, progressive web apps,
desktop apps, app developers, and pretty much anything
else you can imagine that has anything to do with apps. So we envision people using it
to host landing pages, server end points, marketing pages,
deep-linking URLs that go directly into a
specific piece of content, and pretty much anything else. And we’ve launched
.app as an open TLD, which means that you
can register it without restrictions. So anyone can buy a .app
domain name and use it for any purpose. But obviously, because
the string is .app, it would probably make sense to
use it for something associated with .app. And you should all pay attention
to the rest of this talk, because everyone here is
getting a free .app domain name. [CHEERING] And not just everyone in this
room, but every single attendee of I/O. And you also
got stickers, too. So check your email that
went out a little bit ago. It has the full details on how
to redeem the free .app domain. But please don’t
do that right now. Please pay attention to the
rest of the presentation. We’re going to give you some
useful tips on how to use them, and most importantly,
how to secure them. All right, and then this is
our launch site, There’s useful
information on there. Really, a lot of
this stuff, we’re going to be talking
about in website form. Very importantly, it has the
list of domain name registrars that are selling
.app domain names. So this is where you would get
yours if you want another one, or if you’re on the live stream. It also has a list of a bunch
of sites that are already live on .app domains. ADRIENNE PORTER FELT: So .app is
exciting because it brings two things together. .app provides domains
that are both memorable, because they’re short and there
are lots of names available, and also, they’re all HTTPS,
meaning that every website registered under .app
needs to be all HTTPS. And we’re going to talk about
both of these properties, first starting off with the
fact that .app domains are memorable. So the main reason why I expect
developers, and marketers, and all of you here in
the room to get excited is because you can get
short, memorable domains that tie with your brand. Since it’s a new TLD,
it’s a fresh name space. There are still lots of
good names available, including short domain names. BEN MCILWAIN: Although maybe
not for much longer, if you wait too long, because just
since launch this morning, there’s already been over
100,000 registrations, including 30,000 in just
the first three minutes. ADRIENNE PORTER FELT: Yeah. My team actually snapped
one up this morning. We need to figure out what
we’re going to put on it. BEN MCILWAIN: Yeah, my team
was very hectic this morning. [LAUGHTER] ADRIENNE PORTER
FELT: So previously, if you were trying to
work in a .com world, you may have ended up
with a long domain name. However, you can definitely
get much shorter ones. And we think, for many
reasons, that shorter ones are more appealing, both
to developers, but also to end users, who
have to remember how to get back to your website. But not only are .app names
memorable, they’re also unique. And this is really important. So let’s say that you’re
trying to get this CallApp. This is actually a
pretty popular call app, particularly in
emerging markets. And unfortunately, the
thing about the name CallApp is that if you search in
an app store for that, lots and lots of
different applications use the word “call.” So there’s a lot of ambiguity
around which one, maybe, the user is looking for. However, domain
names are unique. There’s only one So domain names are
just a more reliable way for people to be able
to find your app, your web app, your mobile
app, whatever, by name. BEN MCILWAIN: All right,
so let’s look at some real, live examples of websites that
are already serving on .app. And as we go through these,
let’s pay particular attention to the domain names that they’re
using and think about what alternatives might
have existed on, say, the pre-existing TLDs that
they could have gotten if they hadn’t had the .app domains. And spoiler alert,
the other alternatives would not have been
as good as these are. So first up is,
obviously a great domain name. This is an app by Square, and
it is for sending and receiving money. For what they’re doing, you
can’t imagine a better domain name than Next up is the
Outdoor Voices trail shop with, a nice,
short, two-letter domain. They are a sporting
apparel retailer with an augmented reality
shopping feature in their app. And then there’s It’s a financial advice app. And that equivalent domain on
.com was probably registered at least two decades ago. Who knows. But on the new namespace,
you get a nice, short domain name that’s exactly the
actual name of your app. And there’s many, many more. We won’t go through
these individually, but these are all
more examples of real, live apps that are currently
out there and running on .app domain names. And you can find this list on, if you’re interested. But so we’ve talked
about what’s special, or how the .app string itself
going into the .app domain is useful. But what else is special
about .app besides the name? So Adrienne mentioned earlier
that security was a big win for .app. ADRIENNE PORTER FELT: Yeah. And security is personally
why I’m really, really excited about it. But .app is all
HTTPS by default. What this means is that if you
register and use a .app domain, you’ll need to build an
HTTPS website from the start. I have to admit,
this idea actually first came up on the Chrome
Security Team a few years ago. And at that time, it
seemed a little crazy. Like, really? Could we get a whole
bunch of developers to set up websites on HTTPS? But it turns out, a lot
has changed since then. And we’re in the future. And the future is awesome
and very friendly to HTTPS. But don’t just take
my word for it. To quote Buzzfeed,
“Moving to HTTPS is clearly the way forward
for the industry overall.” And as I mentioned
earlier, at the beginning, we are seeing 3/4 of page
loads, now, over HTTPS. I think most news sites,
as they’re coming online, are all HTTPS. Now, I’m excited about
HTTPS for many reasons. But I want to tell
you about why you all should be excited about HTTPS. It gives a lot of positive
benefits to your website. The first is authenticity. What this example is showing
here on the screen is, someone I know
named Eric Mill was browsing on a wireless hotspot. He was looking at the
website for the Federal Trade Commission. Now, normally, the FTC website
does not have ads all over it, sort of by nature of the fact
that they’re a government website. But when he was
looking at it, all of this area that’s
covered in yellow was showing advertisements. They really took up a large
chunk of the viewport. And what was happening was that
the wireless hotspot provider was injecting advertisements for
one of their other businesses onto every HTTP website that
people loaded while using the hotspot service. And this isn’t a one-off. This is a thing that
internet service providers, wireless hotspots, et cetera,
do in order to monetize. There’s actually a pretty
good amount of HTTP traffic that has advertisements
modified, injected, et cetera. Now, I’m sure that all
of you here in the room put a lot of effort into
what your website looks like. You think really hard about when
and how you show advertisements and how it affects
your user experience. I assume you don’t
want someone else’s ads all over your beautiful website. And HTTPS prevents that. If you have an HTTPS
domain, this kind of thing can’t happen. Another thing that HTTPS gives
you is access to powerful APIs. New web features, ones
that have come out over the last few years,
are available only to HTTPS websites. This is particularly
important for people who are making PWAs, or
Progressive Web Apps. For example, service
workers, which are key for building
good offline experiences, doing things like
background syncing, sending push notifications,
is available only to HTTPS websites. Other APIs, like geolocation,
camera, and mike, are also HTTPS only. Also, if you have
an HTTPS website, you’ll get a better look
in the Chrome URL bar. In July 2018, which is
the Chrome 68 release, all HTTPS websites will
start being marked not secure, right next to the
domain name in the URL bar. So we’re trying
to tell users what you get with HTTP, which
is an unencrypted, insecure connection. And if any of you
here are running websites that are not HTTPS
yet, please move them to HTTPS before July. Also, as an added bonus, Android
security is important, too. Android P requires TLS for
connections between your app and back end by default
to prevent anyone from messing with or
looking at the traffic going between people’s Android
phones and your back ends. So you’ll need to have an
HTTPS endpoint set up anyway. We’re using a technique called
HSTS preloading in order to ensure that .app sites
are always all HTTPS. HSTS is kind of a mouthful. HSTS stands for HTTP
Strict Transport Security. Earlier– I know it has
another acronym in it. Earlier, he tried to get me
to say out the full thing, and it takes, like,
five minutes, OK? Trust me. So what HSTS does is,
it’s a way for your server to tell the browser that your
web content should be always over HTTPS. So you would send
a header that’s named strict-transport-security. And once the browser
sees that header, it’ll know to only connect
to that domain over HTTPS from then on, until the
max-age runs out without seeing an updated max-age. So you’ll get, even if the user
doesn’t specify the scheme when they type in the URL bar, or
even if the user types in HTTP or clicks on an
HTTP link, they’ll still end up on the HTTPS
version of your website. Now, HSTS also prevents
something called a downgrade attack on your website. What this means is that
if you have both an HTTP version and an
HTTPS version, it’s possible to force users
back to the HTTP version if you don’t have something like
HSTS to make sure that they’re always on the HTTPS version. So let me explain
with an example. Fairly recently, in
[INAUDIBLE],, The Citizen Lab claims that middle boxes
on Turk Telecoms Network were redirecting
Turkish and Syrian users to spyware when they were trying
to download legitimate Windows executables. The idea here was that these
download sites supported HTTPS, but weren’t HTTPS only. They weren’t using
HSTS, which meant that the ISP was able to force
those connections down to HTTP and then modify them in transit. So using HSTS will prevent
that from happening . Plus, you can go one step
further with something called preloading. So preloading is
basically, there there’s a long list of domains that
wants to be always HTTPS, even on that very
first connection, before the browser has had
a chance to see a header. If you’re on this
list, then the browser knows that the
connection should always be over HTTPS, even without
having seen that header. BEN MCILWAIN: All
right, so in addition to preloading individual domain
names in the HSTS preload list, it’s also possible to preload
entire top-level domains. So that’s exactly what we did. And that’s how we implemented
the security features of .app. So this screenshot
right here is just a screenshot from the
actual Git repository that’s hosting the HSTS preload list. And these eight TLDs are on it. And what that means is
that any web request to a browser to any domain on
any of these top-level domains will have the you URL upgraded
from HTTP to HTTPS before that network connection
is ever made. So it’s always, and
only ever, HTTPS to any domain on those TLDs. And we’ve highlighted here
with a red arrow .app, because that’s obviously the
one of important interest today. But you see that
there are some others. For instance, there’s a
company called FTLD Registry, and they run .bank
and .insurance. And those are both on
this list, as well. And you can pretty
obviously tell why having enforced
security would be important in the banking
and the insurance industry. So yeah, and these are– there’s
more coming soon to this list. And we would encourage
other registry operators to add even more. But out of these eight that are
currently on there right now, .app is the first
open TLD on the list. And what that means is, it’s
the first one on the list that grants security benefits
to everyone here present, because you can all,
and indeed you all do, now have a free
.app domain name. So it’s the first time
that this enhanced security benefit is being made
available to everyone. And you get it just by
registering a domain name. And so why is this the first? Like, why hasn’t this
happened before now? There’s a couple of reasons. One is that the
requisite browser support for handling
top-level preloading only came in fairly recently. And it also hasn’t been until
fairly recently that really easy HTTPS configuration,
and one-click SSL certificate provisioning, came out and made
it really simple to just get that HTTPS hosting working. And a lot of that, of course,
is thanks to Let’s Encrypt. And then also, another reason
that we’re doing this now is because privacy
and security is on everyone’s minds these days. It’s in the news constantly. And enforced HTTPS is something
that can really help mitigate some of these issues, because
you can’t have privacy and security at all
if you’re doing things over an insecure connection
or a connection that can be forced to be insecure. It’s just not even possible. And there’s a huge number
of different benefits of preloading at the TLD level
that I’d like to go over. So number one, it eliminates
the hassle of configuring HSTS headers on your web server or
your cloud service provider. So you’ll never need to go
Stack Overflow or Google, like, how do I get HSTS
headers on Apache, or Nginx, or whatever? You don’t even need
to worry about it. That slide we showed, showing
the headers, doesn’t matter. It’s already done on the
entire top-level domain. So you get that immediately,
zero configuration, just by using a
.app domain name. And there’s no need to submit
your domain to the HSTS preload list, which
would otherwise be another step you would have
to do to get that security benefit. And very importantly, by
having the entire TLD already on the HSTS preload list, and
we actually did this last year, it eliminates the lag
time to add domains to the preload list. So if you went out right this
second and bought a .com domain name, and you wanted to adhere
to the best possible web security practices, and you
submitted that to the HSTS preload list right now, it would
still take many months for most users to get the advantage of
that higher level of security. And the reason for that is
simply the browser release cycle. So it would go
into the code now, and then it would
hit the nightly, and then in, like, a month and
a half, it would hit the beta, and then in a month and a
half, it would hit that GA. And then eventually,
people would get around to finally upgrading
their browser. And then they’d
get that benefit. It’s already preloaded,
so you don’t have to wait for that long cycle. So you get the
security instantly. And very importantly, preloading
a TLD increases browser efficiency. Because the preload list
is built into every browser installation– it’s
literally in there. It’s in the download executable,
both on desktop and mobile– in every installation, even. So there’s over 2 billion
Chrome installations out there. And there’s many
billions of installations of other browsers. And the HSTS preload list is
in every single one of them. So keeping the preload
list small and efficient is actually very
important, because it’s saving a lot of disk
space and memory on all these different
computers and mobile devices. And especially important
for the mobile devices is, a smaller list is more
efficient to check against, because there’s fewer
entries to check when you’re making a web request. So it’s saving CPU cycles, too. And that’s obviously
very important on mobile, because you use more
CPU cycles, and you’re using up more battery. And preloading makes
your site faster. So if you’re not preloading,
and you want to have security, then what you typically do is,
you’ll have an HTTP to HTTPS redirect. And so what will
happen is, users will just type in
the domain name. And by default, an HTTP
request will be made. And then that will
return the redirect. And now you make another
request to the HTTPS site. So by not having
this redirect, which you can accomplish
by preloading, you’re saving an entire
round trip to the server. And that’s actually very
significant on mobile devices, especially on spotty
cell connections. You can easily save
at least a second on a bad connection by loading
the secure version of the site first, and immediately,
rather than hitting that whole redirect. And another benefit–
preloading makes URLs shorter without losing safety. So for marketing, you want
short URLs, obviously. Whether it’s print materials, or
web apps, or radio commercials, or even just telling your
friend the name of a domain name you’re not going to say,
hey, I found this cool app. It’s No, nobody does that. So your friend is just going
to type in But the problem
with that is, now you’re not getting the
security, unless that site is HSTS preloaded. If it’s preloaded,
then the request is, of course, upgraded to HTTPS
without having to include the protocol specifier. So this makes both marketing
people and security people happy. So a really simple example
is, which looks better? Which would you rather see
on, let’s say, a sticker?,
or just Obviously, is better. And because it’s on .app, with
the entire TLD being preloaded, it’s just as secure as
the one on the left. ADRIENNE PORTER FELT: All
right, so maybe you guys are already old hat at
setting up HTTPS websites. But just in case,
we’re going to walk through some tips on how
to set up an HTTPS website and some tools that are
available for you to use. Now, of course, the first thing
you need is a certificate. Sometimes, people
have a perception that certificates are going
to be expensive, particularly wildcards. You can get free certificates
from Let’s Encrypt. Also, there are cloud providers,
like Cloudflare or Google App Engine, that will also provision
a free certificate for you if you’re a customer. Also, very importantly, not only
does your top-level domain– the top-level frame
need be HTTPS, but also, all of the subresources within
that frame need to be HTTPS, meaning your scripts, your
images, your iframes– they all need to
be HTTPS, as well. It’s called a mixed content
error if you have a mix of HTTP and HTTPS resources on a page. And this is problematic
for your website. If you have active resources,
like a script or an iframe, browsers will– that are HTTP, browsers
will just block them on an HTTPS connection. They won’t show up. If you have passive content,
like an image, it will show up, but it’s still not ideal. You’ll usually get a
downgrade on the browser UI, depending on what
browser you’re using, to tell people that not
all of the subresources have been loaded correctly. So it’s really
important that you’re testing for this, looking
out for mixed content, so that you’re able to move
all of your subresources to HTTPS, too. One tool you can use is
actually built into Chrome. Hopefully, all of you
in the room use Chrome. Assuming you do, you
can look in Dev Tools and open up the Security Panel. This is showing a test web
site, And it shows any
nonsecure origins you have for
subresource requests so that you can get them fixed. Another tool you can make
use of is Lighthouse. Lighthouse provides audits. In this case, one of
them is a security audit that looks for mixed content. In this example, which is,
again,, it tells you about all
of the insecure resources that it found on that page
so that you can fix them. It also highlights
the one where you can very easily tell they’re
already available over HTTPS. So for those, you’ll
just need to go add an extra S into the resource
request, and you’re golden. For others you may need to
use a different subdomain. Sometimes, things have a
special, like, secure or S subdomain that they
use for HTTPS traffic. Or if it’s a company
that you are paying, you may need to specifically
specify in your contract that you want to use the
HTTPS version of their site. BEN MCILWAIN: OK. All right, so
number three is, use HTTPS in your
development environment, and indeed, all environments. So don’t just wait
until production. There’s many reasons for this. One is the powerful
web APIs that Adrienne was talking about. Some of them, you
can hit insecurely over a local context. But if you want to hit them
over your local network and show them to your fellow
developers, or anything, then it simply won’t work
without an SSL certificate. And there’s also a variety
of OAuth, or login flows, or third-party web APIs
that require HTTPS. And you can’t even test
or develop against them at all unless you’re
supporting it. So another problem is, if
you are doing a mix of HTTP in development and
then HTTPS later, you have two different canonical
locations for all resources. And you can easily
get those confused– protocol, relative
specifiers, are like ugly and don’t work amazingly well. It’s just, there’s a
whole class of problems you can cause for yourself
that are completely unnecessary by not
having that one canonical location for all resources
that always starts with HTTPS. And third, it’s maybe
sort of tautological, but you need to use HTTPS
in your dev environment so that you can test HTTPS. It doesn’t make sense to wait
until the very last minute, right before you want
to go to production, and change everything
and not make it secure, because a lot of
things are going to start breaking right
then, most likely [INAUDIBLE] content errors. So if you’re going to be running
it securely in production, which you obviously
should be, then you need to be testing it securely
from the very beginning so problems don’t
creep up on you. And number four, when
testing, use a real domain or a subdomain that you own. Or equivalently, do not use
a fake domain or subdomain that you don’t own. And yes, that’s the same
thing repeated twice. But it’s very important,
so I’m emphasizing it. And the reason is simple. Why use a real domain? The issue is that if
you use a fake domain, you are going to have problems– not maybe. It’s almost guaranteed
at some point. And the specific problem
is a name collision. And a name collision is
where traffic is unexpectedly going somewhere that you
didn’t want it to go. So if I use a fake domain,
and then I do local DNS, it’ll work fine on my computer. But in any other context– like, say, we run a
new Docker container, and I forgot to
set up that DNS– it’s going to a completely
different location. Or if I give the code base
to a friend, and they run it, it’s going to a completely
different location. So you’re not in charge
of your own destiny when you’re using a
fake domain name that could route differently
depending on where you’re hitting it from. And this is also a
huge problem if you’re interacting with any
third-party web services, and they are trying to make
requests to those URLs, and of course, it’s
not working for them. And huge numbers of
developers worldwide have had problems when they
used a fake domain, or a domain on a fake TLD, only for it to
turn out to be real, or later become real, which is
sort of even worse, because things
break on you later. When you use a fake
domain, you’re not in control of your own destiny. And at Google Registry,
we run 46 TLDs. And we know how big
of a problem this is, because we get an
unbelievable amount of misaddressed traffic to
what are supposedly fake domain names that are actually real. And to really drive that home,
2 of the 46 TLDs that we run are .dev and .prod. If you’ve been using any
domain names like that, stop immediately,
because those are real, and we’re getting
some of that traffic. So don’t do that. ADRIENNE PORTER FELT: I
see some guilty faces. BEN MCILWAIN: Some guilty
people in the audience here. All right, so here’s
a simple example of the right way to do things. So use a real domain
name. is a real domain name. And then get a wildcard
certificate for all subdomains on You can do that for
free with Let’s Encrypt. And then, depending– if you
want just local DNS resolution, you can use good,
old-fashioned etc/hosts file. Or if you want
network-level resolution, you can use something
like dnsmasq. And the reason you would
do this is, you obviously don’t want to route traffic
worldwide to your local dev setup when it’s not ready. You don’t want to
leak that information. So you only want it
to resolve locally. But the key thing is, it’s
still a real domain name. So you are in charge of
where that traffic will go from the world. And you know it’s never
going anywhere unexpectedly. So therefore, never
any name collisions. And the final tool for
doing secure hosting is just to use a service
with automatic HTTPS. And there’s so many
of them these days. Some examples– Google App
Engine, Firebase, Cloudflare, GitHub Pages, Netlify,
and many, many more. And this is the
simplest possible way to get a secure website running. For many of these,
it’s as simple as just hitting a single check box,
and you get automatic security. And for some of them,
it’s even simpler than that, because the check
box is checked by default. So it’s zero steps
to the best security. So what you get is, you combine
a cloud platform provider or hosting service that gives
you automated security with a .app domain, which gives
you automatic security from the domain levels. And when you have
those two combined, you get the best in
class, best possible, best practices security. ADRIENNE PORTER FELT: Now, some
of you may be moving existing websites over to .app. If that’s the case, a few
things to keep in mind. The first is that,
assuming you want to maintain your search ranking,
help out the Google bot. Google needs to know that you’re
moving the domain so that you maintain your search ranking
through the transition from one domain to another. There is an excellent
Search Console Help Center article that walks you
through the best practices. There is an FAQ that
covers what you need to do to prepare for a site move. So I strongly encourage
you take a look at that if you ever move a website. I’m going to pause, because
I see a whole bunch of people taking pictures of the slide. All right, also,
the Help Center also has a bunch of other
tips on practices for making your HTTPS setting– setup be ranking friendly. I also encourage you
to check this out, too. BEN MCILWAIN: All right, so
just one last, final reminder– the launch site is All the relevant
information is there. Or just look at what’s on
that sticker on the back of your laptop now, hopefully. And everyone here in attendance,
go and get your free domain. Follow the instructions
in the email. For anyone who’s not here,
like on the live stream, or just people here who want
more than one .app, hopefully, the same. And the last note, and
this is very important, is you should go out there
and use these domain names. Don’t just register
them and park them. The security comes
from using them. The security is getting
more and more people on HTTPS on the web,
and getting more of them on the best
possible practices domains that are HSTS preloaded. And do it on .app, because
security is easier on .app than it is anywhere else. All right, so thank
you very much. Here is some social information
and some links to check out. The last one is That’s actually that
shirt that you may have been wondering why I’m wearing. Nomulus is the name of our open
source domain name registry platform that we use to run all
46 of our top-level domains, including .app. So if you ever had any curiosity
about how top-level domains are actually run, from the
perspective of inside the code base, you can go to It goes right to our GitHub. And you can see the
entire source code. And we’re basically
running out of time. So there won’t be any questions. But we are going to be in
the Web Biodome G over there. So come talk to us afterwards. ADRIENNE PORTER FELT:
Thanks, everyone. BEN MCILWAIN: Yeah. So thank you. [APPLAUSE] [MUSIC PLAYING]

Only registered users can comment.

  1. Prealoading .app TLD looks great.
    Any news on releasing .meet TLD ? I heard they belong to Google ?

  2. Managed to grab a four-letter .app this morning, which is now connected to our Firebase project. Thank you!

  3. 30k in the first 3 minutes. More likely from awful registrar's like godaddy gobbling them up and pricing them way above standard pricing.

  4. You still should use the strict-transport-security header. The preload list only works for browsers that use it. What about requests for non-browser apps, like curl or wget?

  5. I dind't understand how in that moment there was avaible a lot of websites on .app if that already lunched to public on the same day

  6. Just purchased Google domain and proud to be a part of Google experience thank you so much for your time and consideration.

Leave a Reply

Your email address will not be published. Required fields are marked *