Fact: Chrome rules the world.
Now with 69.2% of the world’s browser user share – a measure of browser activity calculated by California-based analytics company Net Applications – Google’s Chrome has no equal, at least in popularity. Rivals like Microsoft’s Edge, Mozilla’s Firefox and Apple’s Safari eke out single digits, while niche browsers under them fight over the smallest scraps.
It’s no surprise, then, that when Chrome speaks, everyone listens, whether about each browser upgrade – something Computerworld tracks in the What’s in the latest Chrome update? series – or about Google’s plans for the future.
Every Chrome upgrade is accompanied by enterprise-centric release notes that highlight some of the planned additions, substitutions, enhancements and modifications. We’ve collected the most important for this what’s-coming round-up.
Just remember, nothing is guaranteed. As Google says: “They might be changed, delayed, or canceled before launching to the Stable channel.”
Chrome 84: Full-page TLS 1.0, 1.1 warnings
Last year, Google spelled out the stages of warnings it would put in front of Chrome users about obsolete TLS (Transport Layer Security) 1.0 or 1.1 encryption. A first step – a “Not Secure” alert in the address bar – was taken in January 2020.
With Chrome 81, the browser was to display a full-page interstitial alert that interrupted attempts to reach the destinations secured with TLS 1.0 or 1.1. That schedule, however, was abandoned in early April.
Now, it’s Chrome 84, slated for release July 14, that is to contain the page-sized warning.
IT administrators can disable both warnings with the SSLVersionMin policy. Setting that policy to “tls1” allows Chrome to connect to TLS 1.0- and 1.1-encrypted sites sans alerts. The SSLVersionMin policy will work until January 2021, when it will be deprecated.
Google
Chrome 84 should show this message when the user tries to steer toward a site encrypted with the obsolete TLS 1.0 or 1.1 standards.
Chrome 84: Risky downloads, rescheduled
Starting with Chrome 84, the browser will warn users when executable files begin their downloading from a secure page (one marked as HTTPS) but actually transfer their bits over an insecure HTTP connection. “These cases are especially concerning because Chrome currently gives no indication to the user that their privacy and security are at risk,” Joe DeBlasio, a software engineer on the Chrome security team, wrote in a Feb. 6 post announcing the scheme.
At the time, Chrome 81 was pegged to begin the warnings. But as with the TLS 1.0 and 1.1 alerts, these were rescheduled in early April, pushed back to later versions of the browser. Google did not say aloud what prompted the change, but it likely was related to the March decision to pause Chrome’s release cadence and when distribution was restored, abandon Chrome 82, skipping from 81 to May’s 83.
With Chrome 85, set to ship Aug.25, Google will drop the hammer, barring those executable files from downloading.
Over several more versions, Google will warn, then block, additional file types, including (in order) archives such as .zip; “all other non-safe types, like .pdf and .docx; then finally image files, such as .png. For example, Chrome 85 will institute warnings for archives (and Chrome 86 will block them).
By Chrome 88 (a Jan. 19, 2021, appearance), the browser will be blocking “all mixed-content downloads.”
Organizations managing Chrome can disable this future blocking on a per-site basis with the InsecureContentAllowedForUrls policy.
Google
Chrome’s timetable for warning, then blocking various types of downloads transmitted over insecure connections runs through the next five versions of the browser. By January 2021 — and Chrome 88 — the process should be finished.
Chrome 85: Cover me!
Chrome will know when one of its windows has been occluded by others, and will then suspend painting that window’s pixels in an effort to save CPU cycles and battery resources.
An earlier version of this feature, Google said, “had an incompatibility with some virtualization software,” and so it was reworked. (This had been on Chrome 81’s to-do list at one point, but was punted to Chrome 83 before being delayed yet again.) It’s now to appear in Chrome 85, currently scheduled to release Aug. 25.
Administrators will be able to disable this with the NativeWindowOcclusionEnabled policy.
Chrome 85: When IE’s inside
The Google-made Legacy Browser Support (LBS) add-on will be struck from the Chrome Web Store in late August, when Chrome 85 ships.
“Legacy Browser Support (LBS) is now built into Chrome, and the old extension is no longer needed,” Google said succinctly.
LBS, whether in extension or integrated form, was designed so IT admins could implant Chrome in their organizations but still call up Microsoft’s Internet Explorer (IE) when necessary, say to render intranet sites or older, written-for-IE web apps. LBS wasn’t an emulator but simply a URL director, sending any on a list to IE for that browser to open. The add-on debuted in 2013, when Chrome’s share of between 15% and 18% was far below IE’s still-dominant 55%-58%.
Google plans to automatically remove the LBS add-on from the browser when Chrome 86 releases. Currently, that’s slated Oct. 6.
To call on the baked-in LBS, administrators can use the policies listed here under the Legacy Browser Support heading.
