In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' (zdnet.com)

On Tuesday, Chrome started marking sites that don't use HTTPS as "not secure." From a report: First announced two years ago, Google said it would flag any site that still uses unencrypted HTTP to deliver its content in the latest version of Chrome, out Tuesday. It's part of the company's years-long effort effort to gradually nudge more webmasters and site owners into adopting HTTPS, a secure encryption standard for data in transit. Any site that doesn't load with green padlock or a "secure" message in the browser's address bar will be flagged -- and shamed -- as insecure.

[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.

Comments

MitM https proxies should be flagged too

[nyet]

All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.

celf signed certificates

[roman_mir]

For years I have been commenting on the way that browsers treat self signed certificates, it was always ridiculous and inconsistent. Sites with self signed certs were treated as if they were hacked by definition while HTTP traffic was not marked as insecure at all. At least at this point there will be some consistency to the way that HTTP and celf signed certificates are treated.

You shouldn’t have given Chrome market share

[xack]

Now Chrome can do web controlling actions like security extortion. the next step will be making only google approved certificates complete with extortionate prices will be marked as secure. Join the resistance, get one of the xul trio of browsers Waterfox Pale Moon or Basilisk.

Re:To be honest

[telek83]

Yes, I would like guarantees that google itself can't alter any content it sees fit to. This push is only so Google can control the ad space better, it gives them complete control over ads, as they can now see all of your HTTPS content, not just their own domain connections. HTTP is fine for non-input web pages, you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing. Assuming the NSA is involved, I imagine they keys or permissions to keys, decryption would now be possible on a global scale, at least with self-signed certs this isn't possible unless they can obtain the keys. I for one will not bend to Google demands, I will warn the users flat out that the Chrome browser is no longer supported on any of my pages that do not require input.

Software updates etc...

[Strider-]

Hopefully, though, software updates (such as Windows Update, Apple Update, etc...) will remain unencrypted. I run a network that services some remote communities via satellite, and those things are eminently cacheable (we have a WSUS server for our corporate computers).

Before you get your panties in a twist about that being insecure, the way I recall these things working is that the update client fetches SHA256 sums of the update files via HTTPS, and then downloads the files over HTTP. That way, the updates can be cached locally, but the end user can still be assured that they haven't been tampered with.

Crying Wolf

[nuckfuts]

The upshot of this is that users are going to become accustomed to ignore all such warnings and proceed to the site anyway. Rendering even legitimate warnings basically useless.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

HTTPS is centralizing the internet

[SkOink]

I'm all for encrypting web traffic, but this push for HTTPS-everything is kind of terrifying. It puts us in this dystopian future where we rely on CAs to decide whether or not we can visit a website.

If a couple of CAs decide (or are told) to revoke my cert, there's literally nothing I can do about it. And all of a sudden my website is inaccessible to 90% of browsers, and there's nothing I can do about it.

I would happily support some kind of peer-to-peer encryption scheme (HTTPS with no CA, maybe). But centralizing everything through CA gatekeepers is just asking for a government to butt in.