Chrome Browser for enterprise release notes
Applies to admins managing the Chrome Browser in their organization.
Every 6 weeks, Google releases an update to its Chrome Browser. Each release includes thousands of improvements and other changes.
In the following notes, the stable release or milestone date (M##) refers to the version in which a feature is scheduled launch. For example, M62 indicates a feature scheduled to launch with the stable version of Chrome 62.
Chrome version & targeted Stable channel release date
|Chrome 66: April 17, 2018|
|Chrome 65: March 6, 2018|
|Chrome 64: January 23, 2018|
|Chrome 63: December 5, 2017|
|Chrome 62: October 17, 2017|
|Chrome 61: September 5, 2017|
|Chrome 60: July 25, 2017|
|Chrome 59: May 30, 2017|
|Chrome 58: April 18, 2017|
|Chrome 57: March 7, 2017|
- How Chrome releases work—Chrome Release Cycle
- Chrome Browser downloads and Chrome Enterprise product overviews—Chrome Browser for Enterprise
- Chrome version status and timelines—Chrome Platform Status | Google Update Server Viewer
- Announcements: Chrome Releases Blog | Chromium Blog
Still need help?
- G Suite, Cloud Identity customers (authorized access, only)—Contact support
- Chrome Browser Enterprise support—Sign up to contact a specialist
- Chrome Administrators Forum
- Chrome Enterprise Help Center
Release notes for each version of ChromeExpand all Collapse all
- Continuation of distrust of Symantec Certificates
Following our announcement to gradually phase out trust in Symantec's PKI, Chrome continues to remove trust in Symantec-issued certificates issued before June 1, 2016.
The Google Security Blog published a guide for impacted site operators. The EnableSymantecLegacyInfrastructure enterprise policy allows administrators to temporarily remove Chrome's distrust of the Symantec PKI. The policy expires after Chrome 73 (targeted for release January 2019), giving enterprise admins 3 releases after Chrome's full distrust to migrate off of Symantec certificates.
For details, see Migrate from Symantec certificates.
Site Isolation Trial
Chrome 66 includes a trial of Site Isolation for a small percentage of users, to prepare for a broader upcoming launch. Site Isolation improves Chrome's security and helps mitigate the risks posed by the Spectre security vulnerability.
If you observe any issues with functionality or performance in the trial, it can be disabled by policy. To diagnose whether an issue is caused by Site Isolation, test by going to chrome://flags#site-isolation-trial-opt-out and follow these instructions to opt out. If any of your users experience issues, you can disable the trial for your whole organization by setting the SitePerProcess policy to false, instead of leaving it unspecified.
If you experience any issues during the Site Isolation trial, please report them here.
- Chrome relaunch policy: RelaunchNotification
If set to 1, or recommended, the user sees a prompt after days 2, 4, 7, and every 3 days after that. If set to 2, or required, the user sees a prompt at days 2, 4, and 7, with a forced relaunch 3 minutes after the final prompt. The RelaunchNotificationPeriod policy feature will make the period configurable.
- Chrome relaunch policy: RelaunchNotificationPeriod (M67)
This feature allows admins to set the time period over which Chrome relaunch notifications are shown to apply a pending update. Over the period based on the setting of the RelaunchNotification policy, the user is repeatedly notified of the need for an update. If RelaunchNotificationPeriod isn't set, the default period of one week applies.
- Click to open PDF
For downloading embedded PDF content with an embed or iframe when Chrome's default PDF viewer is disabled (via settings or Enterprise policy) or not present (as on mobile), an Open button appears on the PDF placeholder.
- Force sign-in policy: Support for Mac
The ForceBrowserSignin policy is supported on Mac.
Changes in this release:
|AutoplayAllowed||This policy allows you to control whether videos with audio content can autoplay (without user consent) in Chrome.|
|EnableCommonNameFallbackForLocalAnchors||This policy has been deprecated.|
|EnableSymantecLegacyInfrastructure||When this setting is enabled, Chrome allows certificates issued by Symantec Corporation's Legacy PKI operations to be trusted if they otherwise successfully validate and chain to a recognized CA certificate.|
|ForceBrowserSignin||Force users to sign in to the profile before using Chrome. Added support for Mac.|
|RelaunchNotification||Notify users to relaunch Chrome to apply a pending update.|
|SafeBrowsingExtendedReportingEnabled||This setting enables Chrome's Safe Browsing Extended Reporting and prevents users from changing it.|
|SSLVersionMin||If this policy isn't configured, Chrome uses the default minimum version of TLS 1.0.|
- Changes to autoplay
Chrome is changing the policy for when sites can autoplay media with sound. Admins will be able to use the AutoplayAllowed policy to control whether Chrome defaults to allowing media to autoplay. For details, see the Autoplay Policy Changes.
- Reducing Chrome crashes caused by third-party software
Chrome will begin showing a warning to users after a crash that displays third-party software injecting code into Chrome. It guides them to update or remove that software.
- Enable CommonName fallback for local anchors policy
The EnableCommonNameFallbackForLocalAnchors policy was offered to give admins more time to update their local certificates. It removes the ability to allow certificates on sites using a certificate issued by local trust anchors that are missing the subjectAlternativeName extension.
As of Chrome M66, we will be deprecating this policy. If a user running Chrome 66 tries to access a site where the certificate isn't allowed, they will see a warning indicating they can't trust the certificate.
- Adobe Flash Deprecation
- Previously listed as launching with Chrome 66, SafeBrowsingWhitelistDomains will now launch in Chrome 67. This policy allows you to configure the list of domains Safe Browsing trusts. Safe Browsing won't check for dangerous resources (for example, phishing, malware, or unwanted software) for URLs that match these domains.
- Support for TLS 1.3
This release comes with the latest version of the Transport Layer Security (TLS) protocol (TLS 1.3 draft 23) turned on. Users of Cisco Firepower devices configured to perform TLS man-in-the-middle interception in Decrypt-Resign/SSL Decryption Enabled mode should see Cisco's documentation.
Changes in this release:
|AlwaysAuthorizePlugins||This policy was deprecated.|
|AbusiveExperience InterventionEnforce||Prevent pages with abusive experiences from opening new windows or tabs.|
|AdsSettingForIntrusive AdsSites||Set whether ads should be blocked on sites with intrusive ads.|
|DeviceLoginScreenAutoSelect CertificateForUrls||Automatically select client certificates for these sites on the sign-in screen (available on Chrome OS).|
|DisablePluginFinder||This policy was deprecated.|
|RestrictAccountsToPatterns||Restrict accounts that are visible in Chrome (available on Android.)|
|SecondaryGoogleAccountSign inAllowed||Allow multiple sign-in access within the browser (available on Chrome OS).|
|SecurityKeyPermitAttestation||URLs/domains are automatically permitted direct Security Key attestation.|
|SpellcheckEnabled||If this policy is on, the user is allowed to use spellcheck.|
|SpellcheckLanguage||This policy force enables spellcheck languages.|
|ThirdPartyBlockingEnabled||This policy enables third-party software injection blocking (available on Windows).|
|UnsafelyTreatInsecureOriginA sSecure||This policy specifies a list of origins (URLs) to be treated as secure context. Learn more about secure contexts.|
|WebDriverOverrides IncompatiblePolicies||This policy allows users of the WebDriver feature to override policies that can interfere with its operation.|
<a download>for cross-origin URLs
To avoid user-mediated information leakage, Chrome starts to ignore the presence of the download attribute on anchor elements with cross-origin attributes. See more details on Chromium.org.
- Mac OS X 10.9 Support
Chrome won't support Mac OS X 10.9. Chrome on Mac OS X 10.9 does not autoupdate. If you have Mac OS X 10.9, upgrade to a newer Mac OS.
- Adobe Flash Deprecation
- Site isolation improvements
With M64, we fixed known issues and made improvements with site isolation.
- Forced sign-in
This feature allows admins to force a user to sign in with their Google account before using Chrome. It ensures Chrome can only be used when under management by cloud-based policies configured in the Admin console. See Force users to sign in to Chrome.
- Site muting
You can mute/unmute sites by interacting with the tab options or by clicking Lock to the left of the URL (desktop only). The Sound settings page (for the desktop, chrome://settings/content/sound) lets you add exceptions for individual sites, as well as turn on/off audio for all sites. If you mute a site through this feature, all open tabs for that site are muted.
- Stronger pop-up blocker
One out of every 5 user feedback reports submitted on Chrome for desktop mention some type of unwanted content. Examples include links to third-party websites disguised as play buttons or transparent overlays on websites that capture all clicks and open new tabs or windows. In this release, Chrome's pop-up blocker now prevents sites with these types of abusive experiences from opening new tabs or windows. Site owners can use the Abusive Experiences Report in Google Search Console to see if any of these abusive experiences have been found on their site and improve their user experience.
window.prompt()to improve user experience and better align with other modern browser's behaviors. Background tabs are no longer brought to the foreground when a dialog is triggered. Instead, the tab header shows a small visual indicator.
Sites can still show browser notifications if permitted by the user or admin. Users can allow browser notifications by interacting with the pop-up permission prompt or changing site permissions. Admins can use the NotificationsAllowedForUrls policy through GPO or the Admin console to list site URLs they want to allow to display notifications to users (for example, calendar.google.com).
- Resize Observer
Traditionally, responsive web applications have used CSS media queries or window.onresize to build responsive components that adapt content to different viewport sizes. However, both of these are global signals and require the overall viewport to change in order for the site to respond accordingly. Chrome now supports the Resize Observer API to give web applications finer control to observe changes to sizes of elements on a page.
This code snippet uses the Resize Observer API to observe changes to an element:
- SharedArrayBuffer (M63)
In line with other browsers, starting on January 5, 2018, Chrome disabled SharedArrayBuffer on Chrome 63. To help reduce the efficacy of speculative side-channel attacks, Chrome will modify the behavior of other APIs, such as performance.now. This is intended as a temporary measure until other mitigations are in place.
- Enable CommonName fallback for local anchors policy (M66)
Chrome offered the EnableCommonNameFallbackForLocalAnchors policy to give IT admins more time to update their local certificates. As of Chrome 66, targeted for Stable Channel on April 2018, we will start deprecating this policy, which removes the ability to allow certificates on sites using a certificate issued by local trust anchors that is missing the subjectAlternativeName extension. If an end-user running Chrome 66 attempts to access a site where the certificate isn't allowed, they will see a warning that the certificate cannot be trusted.
- Adobe Flash Deprecation
See the latest Chrome security improvements in the Chrome Releases Blog.
- Enabling TLS 1.3
TLS 1.3 is enabled starting in Chrome 63. At this time, the only Google service with TLS 1.3 enabled is Gmail, but this expands to the broader web in 2018. End users should not be impacted by this change. If you are aware of any systems that don't work with TLS 1.3, post your feedback in the admin forum. As you prepare for wider use of TLS 1.3, you can configure this policy for network software or hardware in your enterprise that will not transit TLS 1.3 connections. See more information on Chromium.org.
- Support for NTLMv2 authentication protocol
Chrome 63 also includes support for NTLMv2 authentication protocol on Mac, Android, Linux, and Chrome OS. We are expanding on a previous release that supported NTLMv2 for Windows. With versions prior to Chrome 63, this must be manually enabled via chrome://flags. In 2018, we set NTLMv2 as the default NTLM protocol. For enterprises that need to extend support for NTLMv1, a new policy is available to allow you to force the older NTLMv1 protocol as needed.
- Site isolation
Site isolation is available in Chrome 63. 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. Read more at Manage site isolation.
- Material design bookmarks
Chrome's Bookmarks Manager has now been refreshed with new Material Design UI. Take a look by visiting chrome://bookmarks.
- Adobe Flash Deprecation
- Warning for untrusted Symantec certificates
Chrome 62 introduces a console warning for sites using certificates from Symantec or Symantec brands that may not be trusted in future versions of Chrome. For more information, see this blog post.
- Change to update-check URL
We are changing our main update-check URL host on Chrome for desktop from tools.google.com to update.googleapis.com. You might need to update your enterprise's firewall whitelist to the our new update-check URL to ensure that Chrome continues to update. Learn more.
- Manage extensions by permission
The permission-based management of extensions is a new enterprise-focused set of controls implemented via Chrome policy and used to prevent extensions that request undesirable permissions from running. Example: Set or modify a proxy (proxy), Capture audio/video of the desktop (desktopCapture), etc. Learn more.
- Chrome Cleanup tool
On Chrome for Windows, the Chrome Cleanup feature alerts users when it detects unwanted software. It offers a quick way to remove the software and return Chrome to its default settings. We recently completed a full redesign of Chrome Cleanup. The new interface is simpler, has a native Chrome interface, and makes it easier to see what software will be removed.
- Edit username when saving passwords
You can now edit your username when prompted to store a password for a website you visit. When you see the pop-up to save a password (or click the key icon in the address bar after signing in to a page), simply click Edit and make any edits needed.
- Introducing Site settings page
Starting M62, you will see a new Site settings button. The Site settings page provides per-origin permissions, rather than per-permission exceptions.
- Adobe Flash Deprecation
To learn about the latest Chrome security changes, see the Chrome Releases Blog.
- Final removal of trust in WoSign and StartCom certificates
Chrome 61 or later won't trust website authentication certificates issued by WoSign or StartCom. This is the culmination of a multi-release distrust process.
- Side-by-side Chrome channels on Windows
Chrome supports multiple release channels with varying degrees of stability and support. Most users browse with the Stable channel of Chrome. In addition to Stable, Google also ships early-access Chrome channels (Dev, Beta) to get early feedback on features and changes, directly from users and developers. Early-access channels allow developers and admins to try cutting-edge features and validate that business critical applications continue to function as Chrome changes.
Currently, you can't install and run Dev or Beta Chrome on the same computer as the Stable version of Chrome. Starting M61, users can install and run Dev, Beta, and Stable versions concurrently on the same Windows computer. For more details, see the blog post.
- Material Design for New Tab Page (NTP)
We applied a modernized Material Design look to the Desktop NTP. The search bar has been updated to a lighter drop-shadow style that is consistent with Google Web Search. Most visited sites has also been updated to use the same lighter style and refined hover, focus, and active states.
- New messaging for installing extensions that modify New Tab Page (NTP)
Extensions can modify the main site shown on a new tab, called the new tab page (NTP). Users often install extensions that modify NTP but aren't fully aware of how their experience will change. Starting in M61, there is a new permission warning shown at extension install time, which will indicate that the extension can change the default NTP to a custom site. The goal of these changes is to improve user awareness about extensions that will change their Chrome defaults, once installed.
- Adobe Flash Deprecation
To see all of the changes that are in Chrome 61, visit the commit log.
Learn more about the latest Chrome security updates in the Chrome Releases Blog.
- Chrome Enterprise Bundle (May 23, 2017)
Google announced the release of the Chrome Enterprise Bundle, as well as Chrome Browser support for new platforms: Citrix Xenapp, Terminal Services, and Windows Server platforms. See the announcement.
- Adobe Flash Deprecation
To see all of the changes in Chrome 60, visit the commit log.
- Chrome Enterprise Bundle (May 23, 2017)
Google announced the release of the Chrome Enterprise Bundle as well as Chrome Browser support for new platforms: Citrix Xenapp, Terminal Services, Windows Server platforms. See the announcement.
- Material Design comes to Chrome settings
Chrome Settings has updated to Material Design with a new look with the same ease of use and functionality.
- Larger and more prominent search bar
- New menu icon to the top left of Settings that gives you an easy way to jump to specific sections, like People, Appearance, and Search Engine
- Combined and simplified Sign In and People sections
- Streamlined Content Settings section
- Search section renamed Search Engine
- Privacy section renamed Privacy and Security
- Proxy settings moved under the System section
- Font sizes and page zoom settings moved to the Appearance section
- HTTPS/SSL Manage Certificates settings moved under Privacy and Security section
To see all of the changes in Chrome 59, visit the commit log.
- Material Design coming soon to the Chrome settings page (59)
For those already on Chrome's Dev or Canary channels, the Chrome settings (chrome://settings) page has updated to Material Design. The updated design is planned to launch in Chrome 59.
- New desktop welcome page (Windows 10)
We redesigned Chrome's first-run experience in M58. On Windows 10 platforms, we display a welcome page, which explains how to set Chrome as the default browser or pin it to the Windows taskbar. For Windows 7 and Windows 8 platforms, we display a Material Design page that promotes the Sign in to Chrome feature. This page launched to Mac and Linux during the Chrome 57 release.
- Changes to website certificate handling
After many years of the practice being discouraged, Chrome 58 removes support for the commonName field in website certificates. Only the subjectAltName extension will be used when matching certificates to host names. The EnableCommonNameFallbackForLocalAnchors policy can be used to re-enable old behavior for locally installed roots. Organizations are strongly encouraged to migrate to modern certificate standards and not rely on the continued presence of this policy.
Chrome 56 stopped trusting certificates issued by WoSign and StartCom after October 21, 2016 in response to various incidents, and included a whitelist of certificates that would continue to work. Chrome 58 continues reducing the size of that whitelist.
As a reminder, since Chrome 56, the use of SHA-1 website certificates is no longer supported unless configured via policy: EnableSha1ForLocalAnchors. This policy can be used to re-enable old behavior for locally installed roots, which gives organizations more time to move away from SHA-1 certificates. Chrome strongly encourages organizations to migrate to modern certificate standards and not rely on the continued presence of this policy, because it will be removed in January 2019.
To see all of the changes that are in Chrome 58, visit the commit log.
- Form Not Secure warning UI (M56)
To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. As part of a long-term plan to mark all HTTP sites as non-secure, beginning in January 2017 (Chrome 56), we mark HTTP pages that collect passwords or credit cards as non-secure. Read about Moving toward a more secure web.
- Chrome chip and icon
Chrome security chip and icon for Chrome internal pages (Settings, History, Downloads...) indicate and verify that page is a secure internal Chrome page.
- Extension name chips
Chrome will begin showing the extension name if the page URL is a chrome-extension:// URL. The extension name is displayed in the same style as security indicator URL-bar strings, but without any animations.
- Windows roaming profiles support
We are launching initial support for roaming profiles on Windows. It enables users to have a Chrome Sync experience anywhere they sign in to Windows with their domain accounts if roaming profiles are enabled without the need to sign in to Chrome. For more information, see Using Chrome on roaming user profile.
- Legacy Browser Support: Update 4.7
Bug fixes and performance improvements from 4.6:
- Migrating capable 32-bit Chrome users to 64-bit Chrome
To improve stability, performance, and security, users who are currently on the 32-bit version of Chrome and 64-bit Windows with 4 GB or more memory will be automatically migrated to 64-bit Chrome during the Chrome 57 rollout. The 32-bit Chrome will still be available via the Chrome download page.
- Revamp first-run and onboarding experience
We redesigned Chrome's first-run experience in 57. On non-Windows 10 platforms, we display a Material Design page which promotes the Sign in to Chrome feature. For Windows 10, this feature will be launched in the Chrome 58 release.
- Requiring explicit user action to enable sideloaded extensions on Mac
In some instances, Chrome extensions can be bundled with Mac software and added during the software download and installation process.
Extensions that are bundled with Mac applications will be added to Chrome in a disabled state. The user will be prompted to either enable the extension or remove it from Chrome.
The Chrome plugins page was used to allow management of plugin settings within Chrome. But as the web has evolved, there have been fewer plugins to manage over time. In this update, the team moved the controls for the remaining components to a more standard and discoverable location: Chrome's content settings, which can be easily accessed at chrome://settings/content.
A list of where common settings went:
- Chrome PDF viewer options moved under Privacy Content settings PDF documents.
- Adobe Flash Player options moved under Privacy Content settings Flash.
- Widevine Content Decryption Module (which enables Widevine licenses for playback of HTML audio/video content) can be adjusted under Privacy Content settings Protected Content.
- Deprecating insecure certificate types
Since 56, Chrome has not trusted server certificates that use the insecure SHA-1 hash algorithm if they chain to publicly trusted roots. In Chrome 57, that is also true for enterprise or locally installed roots, unless the EnableSha1ForLocalAnchors policy has been set.
Note that a collision attack has now been demonstrated against SHA-1. This policy should only be enabled after consulting your security team. Read more about setting Chrome policies for devices and SHA-1 Certificates in Chrome.
Chrome 58 won't consider a certificate's common name when performing trust evaluation and will rely on subject alternative name only, unless the EnableCommonNameFallbackForLocalAnchors policy is set. Turn this policy on only after consulting your security team.
- Distrusting WoSign and StartCom certificates
Chrome 57 continues to reduce the number of whitelisted sites that can use WoSign or StartCom issued certificates, as Google discontinues trust for these certificates. Learn more in this blog post and on Chromium.org.
To see all of the changes in Chrome 57, visit the commit log.