Apparently, Google is automatically adding some of its TLDs to browser HSTS lists–i.e., it is impossible to access any registered domains on those TLDs without using SSL on modern browsers.
As someone who likes to see as much Internet traffic encrypted by default, I think that’s kind of cool. As someone who owns quite a few domains on those TLDs, it is annoying that this was never disclosed when I purchased those domains.
Yes, HSTS is very good, but this can create some unexpected problems. There are occasionally situations where you may need to do an http call in the process of configuring or testing a site, and registrars need to be more upfront that this is not going to be possible with these Google-administered TLDs.
So Google has built HTTPS protection directly into a handful of top-level domains—the suffixes at the end of a URL like “.com.” Google added its internal .google top-level domain to the preload list in 2015 as a sort of pilot, and in 2017 the company started using the idea more extensively with its privately run suffixes “.foo” and “.dev.” But in May 2018, Google launched public registrations of “.app,” opening up automatic, preloaded encryption to anyone that wanted it. In February of this year, it opened up .dev to the public as well.
Which means that today, when you register a site through Google that uses “.app,” “.dev,” or “.page,” that page and any others you build off it are automatically added to a list that all mainstream browsers, including Chrome, Safari, Edge, Firefox, and Opera, check when they’re setting up encrypted web connections. It’s called the HTTPS Strict Transport Security preload list, or HSTS, and browsers use it to know which sites should only load as encrypted HTTPS automatically, rather than falling back to unencrypted HTTP in some circumstances. In short, it fully automates what can otherwise be a tricky scheme to set up.
“Web security stuff is complicated, and not every end user or even every site creator understands all of the complexities,” says Ben Fried, Google’s chief information officer. “The thing that I like about using these new top-level domains in this way is it dramatically decreases the burden on each site creator to get to the best practices. Nothing has to be done, because every subdomain in that top-level domain is HTTPS only and the browser won’t even try to access it any other way.”
The breakthrough moment came from engineer Ben McIlwain’s realization that an entire top-level domain could go on the preload list. “Internally it took off from there,” Fried says. “We realized these are two things that had developed independently that all of a sudden were way more powerful when combined.”