Google's Push to Close a Major Encrypted Web Loophole

Google's Push to Close a Major Encrypted Web Loophole

The internet-wide push to encrypt more web traffic has resulted in a wave of safer, snoop-proof connections. The next challenge, though, is completing that transition from using a mixture of unencrypted HTTP and protected HTTPS to requiring that baseline protection everywhere. And over the past year, Google has been publicly offering a simple and straightforward way for websites to eliminate these subtle weak spots.


When HTTPS encryption was still a novelty, web developers needed to create features that would allow HTTPS and HTTP pages to interoperate, because the majority of sites were still unencrypted. So HTTPS architects built mechanisms to upgrade or downgrade browsing sessions between HTTP and HTTPS when needed, so that people wouldn't be blocked from using certain sites completely. But as HTTPS has proliferated, it's finally time to bypass or otherwise eliminate those intermediary features. Otherwise, pages still served over HTTP, like those redirect pages, will continue to be at risk of interception or manipulation.

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
Support the originator by clicking the read the rest link below.