 Good 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 McElwain. 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. 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 in the registry team. And they had an idea that they were going to be launching this TLD, top level domain, 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 like short, meaningful domain names because they tie into your brands 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 on 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, HTTPS 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 a 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 and $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 ratcheted that up a little bit. In mid 2017, we started labeling more pages as not secure if they were any HTTP page due to an incognito or any HTTP page with any kind of form field on it. And we 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. 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 unpacked, so we're going to explain that. So first, what's the 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 to buy domains. So a registrar will sell domains from a 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, who are 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, dot com, dot net, dot 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. These ones at least have been out for a very long time. So dot edu, dot gov, and dot mill. And for instance, if you want a dot mill 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 dot uk, dot de, and dot io. And you know it's a country code top level domain because it has two characters. So if you didn't know, dot io is not a 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 are restrictions, or 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 dot how, dot mina, and dot 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, the Google Registry. And one interesting thing to note here is dot mina 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 dot 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 AM this morning, there is a new top level domain on the web. And that top level domain is dot app. So yeah, today, we're, thank you. So yeah, so we're introducing dot app. Dot 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 endpoints, marketing pages, deep linking URLs that go directly into a specific piece of content, and pretty much anything else. And we've launched dot app as an open TLD, which means that you can register it without restrictions. So anyone can buy a dot app domain name and use it for any purpose. But obviously, because the string is dot app, it would probably make sense to use it for something associated with dot app. And you should all pay attention to the rest of this talk because everyone here is getting a free dot app domain name. I am. And not just everyone in this room, but every single attendee of IO. And you also got stickers too. But yeah, so check your email that went out a little bit ago. It has the full details on how to redeem the free dot 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. And then this is our launch site, git.app. 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 dot app domain names. So this is where you would get yours if you want another one or if you're on the live stream. And it also has a list of a bunch of sites that are already live on dot app domains. So dot app is exciting because it brings two things together. Dot 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 dot app needs to be all HTTPS. And we're going to talk about both of these properties. First, starting off with the fact that dot 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 namespace. There's still lots of good names available, including short domain names. 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. Yeah. My team actually snapped one up this morning. We need to figure out we're going to put on it. My team was very hectic this morning. So previously, if you're trying to work in a dot 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 dot app names memorable, they're also unique. And this is really important. So let's say that you're trying to get to call this call app. This is actually a pretty popular call app, particularly in emerging markets. And unfortunately, the thing about the name call app 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 call dot app. 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. All right, so let's look at some real live examples of websites that are already serving on dot 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 preexisting TLDs that they could have gotten if they hadn't had the dot app domains. And spoiler alert, the other alternatives would not have been as good as these are. So first up is cache.app, obviously 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 cache.app. Next up is the Outdoor Voices Trail Shop with OV.app, nice short two-letter domain. They are a sporting apparel retailer with an augmented reality shopping feature in their app. And then there's Albert.app. It's a financial advice app. And that equivalent domain on dot 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-life apps that are currently out there and running on dot app domain names. And you can find this list on git.app if you're interested. So we've talked about how the dot app string itself going into the dot app domain is useful, but what else is special about dot app besides the name? So Adrian mentioned earlier that security was a big win for dot app. Yeah, and security is personally why I'm really, really excited about it. But dot app is all HTTPS by default. What this means is that if you register and use a dot 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 the time, it seems 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's 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 three quarters of page loads now over HTTPS. I think most new 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 the fact that they're a government website. But when he was looking at it, all 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 mic 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 HTTP 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 that 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 Mark, 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 HTTPS, which meant that the ISP was able to force those connections down to HTTP and then modify them in transit. So using HTTPS will prevent that from happening. Plus, you can go one step further with something called preloading. So preloading is basically there's a long list of domains that want 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. 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 through a browser to any domain on any of these top level domains will have the 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 the 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 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's also hasn't been until fairly recently that really easy HTTPS configuration and like one quick 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 force 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 HTTPS headers on your web server or your cloud service provider. So you'll never need to go to Stack Overflow or Google, like how do I get HTTPS 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 HTTPS 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 HTTPS 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 HTTPS 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 we're going to the code now. Then it would hit the nightly. Then like a month and a half, it would hit the beta. And then a month and a half, it would hit the GA. And then eventually, people would get around to finally upgrading their browser, and then they'd get that benefit. So 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, like it's literally in there, it's in the downloaded 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 HTTPS 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 will 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 roundship 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 voting 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 ads 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 HTTPS colon slash slash www.nameofapp.com. No, nobody does that. So your friend is just going to type in nameofapp.com. 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, maybe a sticker? HTTPS colon slash slash get.app or just get.app? Obviously, get.app 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. 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 wild cards. 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 the top-level frame need to be HTTPS, but also all of the sub-resources 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, 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 sub-resources 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 sub-resources 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 DevTools and open up the security panel. This is showing a test website, mixed.badssl.com. And it shows any non-secure origins you have for sub-resource 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, mixed.badssl.com, it tells you about all of the insecure resources that it found on the page that you can fix them. It also highlights the one where you can very easily tell are already available over HTTPS. So for those, you'll just need to go add an extra S into the resource request in your golden. For others, you may need to use a different sub-domain. Sometimes things have a special, like, secure or S sub-domain that they use for the 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 HTTPS version of their site. All right, so number three is, use HTTPS in your development environment and then need 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 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. You can protocol relative specifiers or 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 now make it secure because a lot of things are going to start breaking right then, most likely, mix mode 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 subdomain that you own. Or equivalently, do not use a fake domain or subdomain that you don't own. And yes, this is 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 the 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 I run a new Docker container, I forgot to set up that DNS, it's going to a completely different location. Or if you 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 use 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 even worse because things break on you later. Like 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 misadressed traffic to what are supposedly fake domain names that are actually real. And to really drive it home, two 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. I see some guilty faces. Some guilty people in the audience here. So here's a simple example of the right way to do things. So use a real domain name. Falcon 11.app is a real domain name. And then get a wildcard certificate for all subdomains on Falcon 11.app. 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 Etsy host file. Or if you want network level resolution, you can use something like DNS mask. 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 use a service with automatic HTTPS. And there's so many of them these days. Some examples, Google App Engine, Firebase, Crowdflare, 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 checkbox and you get automatic security. And for some of them, it's even simpler than that because the checkbox is checked by default. So it's zero steps to the best security. So what you get is you combine a Cloud Platform provider, a 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. 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 Googlebot. 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's a excellent Search Console Help Center article that walks you through the best practices. And there's 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 on 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. All right. So just one last final reminder. The launch site is git.app. 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. So thank you very much. Here is some social information and some links to check out. The last one is nomulist.foo. That's actually that shirt that you may have been wondering why I'm wearing. Nomulist is the name of our open source domain name registry platform that we used 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 nomulist.foo. 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. Thanks, everyone. Yeah. Thank you.