Google wants to turn browser signals of Web encryption upside down

Chrome security engineers have proposed that all websites that don't encrypt traffic be marked as insecure by browsers.

The proposal, which was floated earlier this month, would dramatically change the visual signals in a browser's address bar, which now shows an indicator -- a "lock" icon in some cases -- when a website is encrypted with SSL (Secure Socket Layer) or TLS (Transport Security Layer), SSL's replacement. Those sites' domains are prefaced by https rather than the more common http.

Unencrypted sites do not display any special visual sign.

"We, the Chrome security team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure," the engineers said in messages spread across several discussion forums, including Google's own Chromimum project. "The goal of this proposal is to more clearly display to users that HTTP provides no data security."

Chrome's argument was that, without HTTPS and SSL/TLS encryption, traffic between a user's browser and a website is inherently unsafe. The visual display should explicitly call that out.

"We know that people do not generally perceive the absence of a warning sign," Chrome's engineers wrote. "Yet the only situation in which Web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP."

If the changes are made, it would reverse decades of leaving HTTP unmarked, and tagging only those sites that are encrypted or which exhibit some kind of problem, such as suspected malicious websites. Browser users have long been told to look at the address bar for signs of encryption, not for signs of the lack of it.

While Google did not spell out exactly how HTTP addresses would be marked as insecure, it suggested that browser makers take a measured, step-by-step approach in 2015, when HTTP addresses would somehow first be marked as "dubious" and only later be tagged as "non-secure" with in-browser flags. Those would most likely be coded using color or designated with an icon, the practices now used in browsers to peg HTTPS, but the specifics would be left up to each browser developer.

At some point down the line, the signs for HTTPS -- such as the lock icon -- would disappear as encrypted traffic would be assumed as the norm.

Google's idea got some support from Mozilla, whose developers cross-posted comments on their own discussion forum, although there were others who pointed out problems. "The really critical question for me here is the timeline," said Richard Barnes, a security engineer at Mozilla, in a follow-up message. "It's pretty much out of the question to deploy an indicator like this today, because it would appear so often."

Mozilla, Barnes also noted, has backed Let's Encrypt, a project to deliver free security certificates, making encryption possible for small websites.

Those certificates would be important. If browsers marked HTTP as not secure, website owners would want to avoid the warnings -- afraid they would scare off visitors -- and so need a certificate to encrypt their traffic. That's clearly Google's aim: The proposed HTTP signals would be the stick to make that happen.

Google has been aggressively promoting HTTPS, notably on its own properties, including its search engine and Gmail, but it's also wielding clubs other than the new proposal. In August, for instance, Google said it may lower the search ranking of websites that aren't encrypting connections with TLS.

Large swaths of the Internet would have to move to HTTPS to avoid the negative browser signals and public shaming under Google's concept, as most major players don't encrypt their primary domains. Neither microsoft.com nor apple.com use HTTPS, for example, although parts do, including their online stores and some of their services, like Microsoft's Outlook.com and Apple's iCloud.

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.