As the Web moves toward HTTPS by default, Chrome will remove “secure” indicator

Enlarge (credit: Indigo girl / Flickr)
Back in February, Google announced its plans to label all sites accessed over regular unencrypted HTTP as “not secure,” starting in July. Today, the company described the next change it will make to its browser…

Enlarge (credit: Indigo girl / Flickr)

Back in February, Google announced its plans to label all sites accessed over regular unencrypted HTTP as "not secure," starting in July. Today, the company described the next change it will make to its browser: in September, Google will stop marking HTTPS sites as secure.

Before and after representation of the removed "Secure" label.

Before and after representation of the removed "Secure" label. (credit: Google)

The background to this change is the Web's gradual migration to the use of HTTPS rather than HTTP. With an ever-growing fraction of the Web being served over secure HTTPS—something now easy to do at zero cost thanks to the Let's Encrypt initiative—Google is anticipating a world where HTTPS is the default. In this world, only the occasional unsafe site should have its URL highlighted, not the boring and humdrum secure site.

Type data into the form and the "Not secure" message goes from gray to red.

Type data into the form and the "Not secure" message goes from gray to red. (credit: Google)

Most HTTP sites will get a regular gray "Not secure" label in their address bar. If the page has user input, however, that grey label will become red, indicating the particular risk the page represents: Web forms served up over HTTP could send their contents anywhere, making them risky places to type passwords or credit card numbers.

Read on Ars Technica | Comments

As the Web moves toward HTTPS by default, Chrome will remove “secure” indicator

Enlarge (credit: Indigo girl / Flickr)
Back in February, Google announced its plans to label all sites accessed over regular unencrypted HTTP as “not secure,” starting in July. Today, the company described the next change it will make to its browser…

Enlarge (credit: Indigo girl / Flickr)

Back in February, Google announced its plans to label all sites accessed over regular unencrypted HTTP as “not secure,” starting in July. Today, the company described the next change it will make to its browser: in September, Google will stop marking HTTPS sites as secure.

Before and after representation of the removed "Secure" label.

Before and after representation of the removed “Secure” label. (credit: Google)

The background to this change is the Web’s gradual migration to the use of HTTPS rather than HTTP. With an ever-growing fraction of the Web being served over secure HTTPS—something now easy to do at zero cost thanks to the Let’s Encrypt initiative—Google is anticipating a world where HTTPS is the default. In this world, only the occasional unsafe site should have its URL highlighted, not the boring and humdrum secure site.

Type data into the form and the "Not secure" message goes from gray to red.

Type data into the form and the “Not secure” message goes from gray to red. (credit: Google)

Most HTTP sites will get a regular gray “Not secure” label in their address bar. If the page has user input, however, that gray label will become red, indicating the particular risk the page represents: Web forms served up over HTTP could send their contents anywhere, making them risky places to type passwords or credit card numbers.

Read on Ars Technica | Comments

From July on, Chrome will brand plain old HTTP as “Not secure”

Enlarge (credit: Indigo girl)
As more and more websites offer access over encrypted HTTPS, Chrome will soon brand any site served up over plain, unencrypted HTTP as “Not secure.” Chrome 68, due for release in July, will start sticking the “Not secur…

Enlarge (credit: Indigo girl)

As more and more websites offer access over encrypted HTTPS, Chrome will soon brand any site served up over plain, unencrypted HTTP as "Not secure." Chrome 68, due for release in July, will start sticking the "Not secure" label in the address bar, as a counterpart to the "Secure" label and padlock icon that HTTPS sites get.

This is a continuation of a change made in January of last year where Chrome would brand HTTP sites with password forms as being "Not secure."

Google says that 81 of the top 100 sites on the Web default to HTTPS and that 68 percent of Chrome traffic on Android and Windows uses HTTPS. As such, non-secure HTTP is becoming the exception, not the rule, justifying the explicit call-out. While HTTPS once required expensive certificates, projects such as Let's Encrypt have made it easy to add HTTPS to just about any site at zero cost.

Read on Ars Technica | Comments

New Firefox version says “might as well” to encrypting all Web traffic

Ready or not, “opportunistic encryption” goes live. (Some configuration required.)

Developers of the Firefox browser have moved one step closer to an Internet that encrypts all the world's traffic with a new feature that can cryptographically protect connections even when servers don't support the HTTPS protocol.

Opportunistic encryption, as the feature is known, acts as a bridge between plaintext HTTP connections and fully compliant HTTPS connections based on transport layer security or its predecessor, protocol secure sockets layer. These traditional Web-based encryption measures require site operators to obtain a digital credential issued by a browser-recognized certificate authority and to implement TLS protection through OpenSSL or a similar code library. Even then, many sites are unable to fully encrypt their pages because they embed ads and other third-party content that's still transmitted in plaintext. As a result, large numbers of sites (including this one) continue to publish some or all of their content in HTTP, which can be readily manipulated by people with the ability to monitor the connection.

OE, as opportunistic encryption is often abbreviated, was turned on by default in Firefox 37, which was released this week. The move comes 17 months after an Internet Engineering Task Force working group proposed OE become an official part of the HTTP 2.0 specification. The move garnered critics and supporters alike, with the former arguing it may delay some sites from using the more secure HTTPS protections and the latter saying, in effect, some protection is better than none. The chief shortcoming of OE is its lack of authentication for cryptographically validating that a connected server is operated by the organization claiming ownership.

Read 2 remaining paragraphs | Comments