Google has rowed back on a decision to block all third-party code by default in its Chrome Enterprise browser.
Enterprise customers need “more time” the company said, after announcing the decision for Chrome 69 in August.
The decision comes as the company announced a sweeping range of new changes in Chrome 70 for enterprise admins.
These include the ability to restrict which domains users can use to access Google products like Gmail or G Suite.
This could, for example, offer control over whether employees can sign into their personal Gmail accounts on a corporate-owned Chromebook.
(Chrome Enterprise, first released in August 2017, adds customisable security controls, 24/7 support, and integration with management tools, VMware Workspace ONE and Microsoft Active Directory to the Chrome browser – the world’s most widely used.)
Content from our partners
Why the Change of Heart?
Third-party software often injects libraries into running processes to do benevolent things like inspect network traffic.
Malicious software can also do the same to spy on users, steal passwords, and similar.
Google had found that such processes, as well as being potentially harmful, made its browser crash more often. (The company says it has extension and native messaging APIs to support such processes in a “safe” way).
Winthrop Chan, Technical Program Manager, Chrome Enterprise said: “We’ve been talking about the stability benefits of moving away from third-party software that injects code into Chrome processes since late last year.”
He added: “However, based on feedback from our enterprise customers, we will take a phased approach to support this transition. In Chrome 70, only non-enrolled devices will have third-party code blocked by default.”
“Domain-enrolled enterprise devices will not be blocked by default until in Chrome 71, giving enterprise customers more time to modify their workflows if they still use software that injects code into the browser processes.”
Chrome 70: What Else is New?
New functions proliferate in Chrome 70, released last week.
These include support for Public Key Credentials – allowing web applications to use cryptographically attested credentials; the ability to add biometrics for 2-factor authentification; the ability to name workers and more.
TLS 1.3, Anyone?
Secure communication on the Internet is made possible through a protocol called Transport Layer Security (TLS).
Chrome is also introducing the final revision of TLS 1.3, a protocol with a simpler, less error-prone design than TLS 1.2.
Chan said: “We previously experimented with earlier drafts of the standard and are excited to ship this final standard in Chrome.”
TLS 1.2 was published ten years ago to address weaknesses in TLS 1.0 and 1.1 and has enjoyed wide adoption since then. Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72, the company said, warning that sites using these versions will begin to see deprecation notices in the DevTools console in that release.
TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. (For those with a technical bent interested in TLS 1.3, the IETF has details here).
This will affect users on early release channels starting January 2020. Apple, Microsoft, and Mozilla have made similar announcements. The company warned: “Site administrators should immediately enable TLS 1.2 or later. Depending on server software (such as Apache or nginx), this may be a configuration change or a software update. Additionally, we encourage all sites to revisit their TLS configuration.”
