Security enhancements and more for enterprise Chrome browser customers

When it comes to Chrome, security is one of our most important considerations—and that’s especially true when it comes to our enterprise users. We’re always looking for ways to further protect enterprises from potential dangers like ransomware, malware, and other vulnerabilities. 

Chrome browser has been validated by third parties as a frontrunner in enterprise browser security, and we’re committed to constantly introducing more safeguards. That’s why the latest release of Chrome browser introduces a variety of new security enhancements for enterprises. From new ways to better isolate processes, to broader support for more advanced security standards, to the introduction of new policies, IT admins now have more options to protect their users and businesses from potential threats. Here’s a quick overview of the security updates this latest release of Chrome will offer, plus an update on a few upcoming changes in 2018.

Site Isolation: For enterprises with the highest security needs

Starting with today’s release, Site Isolation is now available. With Site Isolation enabled, Chrome renders content for each open website in a separate process, isolated from other websites. This can mean even stronger security boundaries between websites than Chrome’s existing sandboxing technology. Admins can read more to determine if this capability makes sense for their organization—and start implementing it immediately.

Making it easier to restrict extensions based on required permissions

Although admins have been able to whitelist and blacklist specific extensions in Chrome, we’ve heard feedback that it can be difficult to scale. Beginning today, IT admins can configure a new policy that restricts access to extensions based on the permissions required. For example, through policy, IT can now block all extensions that require the use of a webcam or microphone, or those that require access to reading or changing data on the websites visited. This policy is available now, and will help IT teams enforce necessary controls, without overly restricting users.  

Version 1.3 of Transport Layer Security (TLS) and policy

Secure communication on the Internet is made possible through a protocol called Transport Layer Security (TLS). To support the latest security standards, we're enabling TLS 1.3 for Gmail in today’s release of Chrome browser. The previous version, TLS 1.2, was standardized in 2008 and, although it can be secure when configured correctly, it’s in need of an overhaul. The improvements in TLS 1.3 make it faster and more secure, and we’ll be expanding TLS 1.3 support to the broader web in 2018.

Chrome browser users should not be impacted by this change. IT admins that are aware of any systems that are not interoperable with TLS 1.3 should post feedback in the admin forum. As admins prepare for the wider use of TLS 1.3, they can configure this policy for network software or hardware that will not transit TLS 1.3 connections. More details are available on this page.

Broader platform support for the NTLMv2 authentication protocol

Last week we shared on our admin forum that Chrome 64, coming in early 2018, will include support for the NTLMv2 authentication protocol, including Extended Protection for Authentication (EPA) on Mac, Android, Linux and Chrome OS. This allows all platforms to perform NTLM authentication with the same level of security that was previously available only in Chrome on Windows.

IT admins can enable this feature today by visiting chrome://flags/#enable-ntlm-v2. In Chrome 65, NTLMv2 will become the default NTLM protocol as it already is on Windows. More details are available on this page. With this update, Chrome will become the only browser to support NTLMv2 with EPA on non-Windows platforms.

Reducing Chrome crashes caused by third-party software

Last week we announced we’ll be implementing changes in Chrome to improve stability and reduce the number of browser crashes. Starting with the release of Chrome 68 in July 2018, we’ll begin blocking third-party software from injecting code into Chrome on Windows.

Code injection has historically been used by products such as anti-virus software. But it’s an outdated process, and we encourage vendors of such software to take advantage of the newer, more effective options available.

In the meantime, we understand sometimes businesses need to rely on such software, and we want to make sure they’re covered. We’ll be introducing a new policy in the coming months that will offer admins extended support for critical apps that require code injection to function.

Admins can visit chrome://conflicts to check if software currently installed on a computer is injecting into Chrome.