For administrators who manage Chrome browser or ChromeOS devices for a business or school.
Select the required tab to see Chrome browser or ChromeOS updates.
- Chrome browser updates published on Chrome browser Early Stable Release.
- ChromeOS updates are published one week before ChromeOS Stable Release.
Chrome 133 release summary
The enterprise release notes are available in 9 languages. You can read about Chrome's updates in English, German, French, Dutch, Spanish, Portuguese, Korean, Indonesian, and Japanese. Allow 1 to 2 weeks for translation for some languages.
Chrome Enterprise and Education release notes are published in line with the Chrome release schedule, on the Early Stable date for Chrome browser.
Chrome browser changes
- Ad-hoc code signatures for PWA shims on macOS
Code signatures for the application shims that are created when installing a Progressive Web App (PWA) on macOS are changing to use ad-hoc code signatures that are created when the application is installed. The code signature is used by macOS as part of the application's identity. These ad-hoc signatures result in each PWA shim having a unique identity to macOS, where previously every PWA looked like the same application to macOS.
This update addresses problems when attempting to include multiple PWAs in the Open at Login preference pane on macOS, and permits future improvements to handling of user notifications within PWAs on macOS.
Admins should test for compatibility with any endpoint security or binary authorization tools they use (such as Santa). The feature can be enabled for this testing using
chrome://flags/#use-adhoc-signing-for-web-app-shims. They can then install a Progressive Web App and ensure that it launches as expected.If there is an incompatibility between the feature and their current security policies, the AdHocCodeSigningForPWAsEnabled policy can be used to disable the feature while they deploy an updated endpoint security policy. The enterprise policy is intended to be used to disable the feature only until endpoint security policies have been updated, at which point it should be unset.
- Chrome 129 on macOS
Feature disabled behind a flag (chrome://flags/#use-adhoc-signing-for-web-app-shims) so that enterprises can test for compatibility with their endpoint security tools, such as Santa. If it is not currently compatible they can disable the feature via the enterprise policy while they update their endpoint security configurations. The enterprise policy is intended to be used to disable the feature only until endpoint security policies have been updated.
- Chrome 133 on macOS
Feature will begin to roll out to stable 100%.
- Chrome 129 on macOS
- Chrome Sync stops support for Chrome versions more than four years old
Starting in February 2025, Chrome Sync (using and saving data in your Google Account) no longer supports Chrome versions that are more than four years old. To continue using Chrome Sync, you need to upgrade to a more recent version of Chrome. To read more, see this discussion: Chrome Sync will be sunset on versions of Chrome that are more than four years old.
- Chrome 133 on Android, iOS, ChromeOS, Linux, macOS, Windows
This change affects only the old versions of Chrome and will be rolled out server-side. Chrome 133 is specified only to reflect the timeline when the change will make an effect.
- Chrome 133 on Android, iOS, ChromeOS, Linux, macOS, Windows
- New option in HttpsOnlyMode policy
Ask Before HTTP (ABH), previously named HTTPS Only/First Modes, allows Chrome to ask for user consent before sending insecure HTTP content over the wire. The HttpsOnlyMode policy allows force-enabling, or force-disabling, ABH.
In Chrome 129, we added a new middle-ground variant of ABH called "balanced mode". This variant aims to reduce user inconvenience by working like (strict) ABH most of the time, but not asking when Chrome knows that an HTTPS connection isn't possible (such as when connecting to a single-label hostname like internal/).
We are adding a force_balanced_enabled policy option to allow force-enabling this new variant. Setting force_balanced_enabled on browsers before Chrome 129 will result in the default behavior, which places no enterprise restrictions on the ABH setting.
To avoid unexpected impact, if you have previously set force_enabled, we recommend not setting force_balanced_enabled until your entire fleet has upgraded to Chrome 129 or higher. If you are not migrating from force_enabled to force_balanced_enabled, you will be unaffected by this change.
- Chrome 129 on ChromeOS, Linux, macOS, Windows, Fuchsia
- Chrome 133 on Android
- Tab freezing on Energy saver
When Energy saver is active, Chrome freezes a tab that has been hidden and silent for >5 minutes and uses a lot of CPU, unless:
- The tab provides audio- or video- conferencing functionality (detected via microphone, camera or screen/window/tab capture, or an RTCPeerConnection with an open RTCDataChannel or a live MediaStreamTrack).
- The tab controls an external device (detected via usage of Web USB, Web Bluetooth, Web HID or Web Serial).
This will extend battery life and speed up Chrome through reduced CPU usage.
The feature can be tested using a flag, chrome://flags/#freezing-on-energy-saver. Alternatively, it can be tested with chrome://flags/#freezing-on-energy-saver-testing, which simulates Energy saver being active and all tabs using a lot of CPU; this allows you to verify whether tabs are eligible for freezing and would be frozen if using a lot of CPU.- Chrome 133 on ChromeOS, Linux, macOS, Windows
The feature will start rolling out to 1% of stable in Chrome 133.Energy saver availability can be controlled via the BatterySaverModeAvailability policy (this change has no effect when Energy saver is inactive).
- V8 security setting on Android
V8 is Chrome’s JavaScript and WebAssembly engine used to improve site performance. To reduce the attack surface of Chrome, Chrome 133 on Android now includes a new setting on
chrome://settings/securityto disable the V8 Just-in-Time (JIT) optimizers. This maintains compatibility with Web Assembly. Admins can continue to control this feature using the DefaultJavaScriptJitSetting enterprise policy, and the associated JavaScriptJitAllowedForSites and JavaScriptJitBlockedForSites policies.- Chrome 122 on ChromeOS, Linux, macOS, Windows, Fuchsia
The setting rolls out in Chrome 121. The enterprise policies have been available since Chrome 93. - Chrome 133 on Android
The setting is available on Android in Chrome 133, under Site Settings. The enterprise policies are no longer marked experimental.
- Chrome 122 on ChromeOS, Linux, macOS, Windows, Fuchsia
- Chrome Welcome page no longer triggered using initial_preferences
We have removed the Chrome Welcome page from
initial_preferencesbecause that page is redundant with the First Run Experience that triggers on desktop platforms. Includingchrome://welcomein thefirst_run_tabsproperty of theinitial_preferencesfile now has no effect.For more details about the context of the initial_preferences file, see Configuring Other Preferences.
- Chrome 133 on Windows, macOS, Linux
- Support for non-special scheme URLs
Since Chrome 130, Chrome browser supports non-special scheme URLs, for example,
git://example.com/path. Previously, the Chromium URL parser didn't support non-special URLs. The parser parses non-special URLs as if they had an opaque path, which is not aligned with the URL standard. In Chrome 133, the Chromium URL parser parses non-special URLs correctly, following the URL standard. For more details, see http://bit.ly/url-non-special.- Chrome 130 on Windows, macOS, Linux, Android
- Chrome 133 on Windows, macOS, Linux, Android
- Chrome 134 on Windows, macOS, Linux, Android: Feature flag being removed
- New policies in Chrome browser
Policy Description LiveTranslateEnabled Enable translation of live captions. Captions will be sent to Google for translation. WebRtcIPHandling This policy allows restricting which IP addresses and interfaces WebRTC uses when attempting to find the best available connection. DefaultJavaScriptOptimizerSetting Allows you to set whether Chrome browser will run the v8 JavaScript engine with more advanced JavaScript optimizations enabled. JavaScriptOptimizerBlockedForSites Allows you to set a list of site URL patterns that specify sites for which advanced JavaScript optimizations are disabled. JavaScriptOptimizerAllowedForSites Allows you to set a list of site URL patterns that specify sites for which advanced JavaScript optimizations are enabled. SafeBrowsingAllowlistDomains Setting the policy to Enabled means Safe Browsing will trust the domains you designate. FilePickerChooseFromDriveSettings Allow choosing files directly from Google Drive.
- Removed policies in Chrome browser
Policy Description CSSCustomStateDeprecatedSyntaxEnabled Controls whether the deprecated syntax for CSS custom state is enabled.
Chrome Enterprise Core changes
- DownloadRestrictions policy support on iOS
DownloadRestrictions is a universal policy available to Chrome Enterprise Core users on Desktop platforms and on Android. DownloadRestrictions policy is now supported on iOS. This will allow admins to block all downloads on mobile Chrome on iOS.
- Chrome 133 on iOS
Chrome Enterprise Premium changes
- There are no updates to Chrome Enterprise Premium in Chrome 133.
Coming soon
Note: The items listed below are experimental or planned updates. They might change, be delayed, or canceled before launching to the Stable channel.
Upcoming Chrome browser changes
- Privacy and security panel in Chrome DevTools
Starting in Chrome 134, developers will be able to use the new Privacy and security panel in Chrome DevTools to test how their site will behave when third-party cookies are limited. Developers will be able to temporarily limit third-party cookies, observe how their site behaves, and review the status of third-party cookies on their site.
This feature will not make any permanent changes to existing enterprise policies, but it will let third-party cookie related enterprise policies (that is, BlockThirdPartyCookies and CookiesAllowedForUrls) be temporarily overridden to be more restrictive. If your enterprise policy already blocks third-party cookies using BlockThirdPartyCookies, this feature will be disabled.
The new Privacy & security panel will replace the existing Security panel. TLS connection and certificate information will continue to be available on the Security tab in the Privacy & security panel.
- Chrome 134 on ChromeOS, Linux, macOS, Windows
- Read aloud in Reading mode in Chrome 134
Reading mode is a side-panel feature that provides a simplified view of text-dense web pages. Reading mode will include a Read aloud feature that will allow users to hear the text they are reading spoken out loud. You can choose different natural voices and speeds, and see visual highlights.
- Chrome 134 on Linux, macOS, Windows
- Highlight settings for AI features disabled by policy
In Chrome settings, we will list AI features that are disabled by enterprise policy. We will also show a Disabled by your organization notice similar to other settings when they are disabled by policy.
- Chrome 134 on ChromeOS, Linux, macOS, Windows
- Blob URL Partitioning: Fetching/Navigation
As a continuation of Storage Partitioning, Chromium will implement partitioning of Blob URL access by Storage Key (top-level site, frame origin, and the has-cross-site-ancestor boolean), with the exception of top-level navigations which will remain partitioned only by frame origin. This behavior is similar to what’s currently implemented by both Firefox and Safari, and aligns Blob URL usage with the partitioning scheme used by other storage APIs as part of Storage Partitioning. In addition, Chromium will enforce noopener on renderer-initiated top-level navigations to Blob URLs where the corresponding site is cross-site to the top-level site performing the navigation. This aligns Chromium with similar behavior in Safari, and the relevant specs have been updated to reflect these changes.
This change can be temporarily reverted by setting the PartitionedBlobURLUsage policy. The policy will be deprecated when the other storage partitioning related enterprise policies are deprecated.
- Chrome 134 on Windows, macOS, Linux
- Create service worker client and inherit service worker controller for srcdoc iframe
Srcdoc context documents are currently not service worker clients and are not covered by their parent page’s service worker. This results in some discrepancies (for example, Resource Timing reports the URLs that these documents load, but the service worker doesn’t intercept them). We aim to fix the discrepancies by creating service worker clients for srcdoc iframes and make them inherit the parent page's service worker controller.
- Chrome 134 on Windows, macOS, Linux, Android
- Fire error event instead of throwing exception for CSP blocked worker
When blocked by the Content Security Policy (CSP), Chromium currently throws a SecurityError exception from the "new Worker(url)" or "new SharedWorker(url)" constructors. According to the CSP specification,
the CSP check is performed as part of fetch and an error event should fire after the object is returned. This update aims to make Chromium spec-conformant, by not throwing an exception from the constructor but instead firing an error event asynchronously.
- Chrome 134 on Windows, macOS, Linux, Android
- Remove nonstandard getUserMedia audio constraints
Blink supports a number of nonstandard goog-prefixed constraints for getUserMedia from some time before constraints were properly standardized.
Usage has gone down significantly ~0.000001% to 0.0009% (depending on the constraint) and some of them do not even have an effect due to changes in the Chromium audio-capture stack. Soon none of them will have any effect due to other upcoming changes.
We do not expect any major regressions due to this change. Applications using these constraints will continue to work, but will get audio with default settings (as if no constraints were passed). They can easily migrate to standard constraints.
- Chrome 134 on Windows, macOS, Linux, Android
- Deprecate mutation events
Synchronous mutation events, including
DOMSubtreeModified,DOMNodeInserted,DOMNodeRemoved,DOMNodeRemovedFromDocument,DOMNodeInsertedIntoDocument, andDOMCharacterDataModified, negatively affect page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete mutation events must be removed or migrated to Mutation Observer.Since Chrome 124, a temporary enterprise policy, MutationEventsEnabled, is available to re-enable deprecated or removed mutation events. To read more, see this blog post. If you encounter any issues, file a bug here.
Mutation event support is disabled by default, since Chrome 127, or around July 30, 2024. Code should have been migrated before that date to avoid site breakage. If more time is needed, there are a few options:
- The Mutation Events Deprecation Trial can be used to re-enable the feature for a limited time on a given site. This can be used up until Chrome 134, ending March 25, 2025.
- A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 134.
- Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.
- Cross-device synchronization of Chrome settings and themes on Desktop at sign-in
Following the launch of the new identity model on Chrome Desktop, we plan to enable account settings, themes and site shortcuts to users at sign-in (rather than needing to sync).
To do this, we will introduce local and account storage for each of these data types.
This means:
- For Chrome users on Desktop who sign in to Chrome or who have Sync enabled, settings, site shortcuts and themes synced to their Google Account will be kept separate from the local ones, that is, settings from when they’re signed out or when Sync is turned off.
- This allows for strictly less data sharing than previously: local settings don’t get automatically uploaded when users sign in or turn on Sync, and no settings from their account storage are left behind on the device when Sync is turned-off.
-
Existing Chrome policies SyncDisabled and SyncTypesListDisabled will continue to apply so admins can restrict or disable the Sync feature if they want to.
- Chrome 135 on Linux, MacOS, Windows
- Disallow spaces in non-file:// URL host
As stated in the WhatWG.org spec, URL hosts cannot contain the space character, but currently URL parsing in Chromium allows spaces in the host.
This causes Chromium to fail several tests included in the Interop2024 'HTTPS URLs for WebSocket' and URL focus areas.
To bring Chromium into spec compliance, we would like to remove spaces from URL hosts altogether, but a difficulty with this is that they are used in the host part in Windows
file://URLs. To read more, see the discussion on Github.This feature will be part of the ongoing work to bring Chromium closer to spec compliance by forbidding spaces for non-file URLs only.
- Chrome 135 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
- Remove ThirdPartyBlockingEnabled policy
Due to unexpected issues, ThirdPartyBlockingEnabled will be removed in Chrome 135. If you have feedback about this removal, please file a bug here.
- Chrome 132 on Windows
Deprecation of ThirdPartyBlockingEnabled policy
- Chrome 135 on Windows
Removal of ThirdPartyBlockingEnabled policy
- Chrome 132 on Windows
- Deprecate getters of Intl Locale Info API
Intl Locale Info API is a Stage 3 ECMAScript TC39 proposal to enhance the Intl.Locale object by exposing locale information, such as week data (first day in a week, weekend start day, weekend end day, minimum day in the first week), and text direction hour cycle used in the locale.
We shipped our implementation in Chrome 99 but later on the proposal made some changes in Stage 3 and moved several getters to functions. We need to remove the deprecated getters and relaunch the renamed functions.
- Chrome 135 on Windows, macOS, Linux, Android
- Remove SwiftShader fallback
Allowing automatic fallback to WebGL backed by SwiftShader is deprecated and WebGL context creation will fail instead of falling back to SwiftShader. This was done for two primary reasons:
- SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process.
- Users have a poor experience when falling back from a high-performance GPU-backed WebGL to a CPU-backed implementation. Users have no control over this behavior and it is difficult to describe in bug reports.
- Chrome 135 on Windows, macOS, Linux, Android
SwiftShader is a useful tool for web developers to test their sites on systems that are headless or do not have a supported GPU. This use case will still be supported by opting in but is not intended for running untrusted content.
To opt-in to lower security guarantees and allow SwiftShader for WebGL, run the chrome executable with the --enable-unsafe-swiftshader command-line switch.
During the deprecation period, a warning will appear in the JavaScript console when a WebGL context is created and backed with SwiftShader. Passing --enable-unsafe-swiftshader will remove this warning message.
Chromium and other browsers do not guarantee WebGL availability. You can test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user.
- SafeBrowsing API v4 to v5 migration
Chrome calls into the SafeBrowsing v4 API will be migrated to call into the v5 API instead. The method names are also different between v4 and v5.
If admins have any v4-specific URL allowlisting to allow network requests to
https://safebrowsing.googleapis.com/v4*, these should be modified to allow network requests to the whole domain instead: safebrowsing.googleapis.com. Otherwise, rejected network requests to the v5 API will cause security regressions for users.- Chrome 135 on Android, iOS, ChromeOS, Linux, macOS, Windows
This will be a gradual roll-out.
- UI Automation accessibility framework provider on Windows
Starting in Chrome 126, Chrome started directly supporting accessibility client software that uses Microsoft Windows's UI Automation accessibility framework. Prior to this change, such software interoperated with Chrome by way of a compatibility shim in Microsoft Windows. This change is being made to improve the accessible user experience for many users. It provides complete support for Narrator, Magnifier, and Voice Access; and will improve third-party apps that use Windows's UI Automation accessibility framework. Users of Chrome will find reduced memory usage and processing overhead when used with accessibility tools. It will also ease development of software using assistive technologies.
Admins might use the UiAutomationProviderEnabled enterprise policy, available from Chrome 125, to either force-enable the new provider (so that all users receive the new functionality), or disable the new provider. This policy will be supported through Chrome 136, and will be removed in Chrome 137. This one-year period is intended to give enterprises sufficient time to work with third-party vendors so that they may fix any incompatibilities resulting from the switch from Microsoft's compatibility shim to Chrome's UI Automation provider.
- Chrome 125 on Windows:The UiAutomationProviderEnabled policy is introduced so that admins can enable Chrome's UI Automation accessibility framework provider and validate that third-party accessibility tools continue to work.
- Chrome 126 on Windows: The Chrome variations framework will be used to begin enabling Chrome's UI Automation accessibility framework provider for users. It will be progressively enabled to the full stable population, with pauses as needed to address compatibility issues that can be resolved in Chrome. Enterprise admins may continue to use the UiAutomationProviderEnabled policy to either opt-in early to the new behavior, or to temporarily opt-out through Chrome 136.
- Chrome 137 on Windows: The UiAutomationProviderEnabled policy will be removed from Chrome. All clients will use the browser's UI Automation accessibility framework provider.
Upcoming Chrome Enterprise Core changes
-
New Chrome Enterprise Companion App
Chrome Enterprise Companion App is a new administrative binary that will be automatically installed with Chrome browsers enrolled into Chrome Enterprise Core or Chrome Enterprise Premium. It is meant to support Enterprise use cases, policies, and reporting.
- Chrome 134 on Windows, macOS
Upcoming Chrome Enterprise Premium changes
- Refactor DLP rules UX
We aim to create a more user-friendly and efficient interface for Chrome-specific DLP rules. This involves redesigning the rule creation workflow in the Admin Console to better accommodate existing and upcoming security features for Chrome Enterprise Premium customers.
- Chrome 134 on Windows, macOS, Linux, ChromeOS
- Screenshot prevention
We plan to enhance the existing screenshot prevention feature by extending screen-sharing blocking to meeting apps like Google Meet, Zoom, Teams, and Slack. We will build upon the successful release of data protection controls by adding key features and addressing gaps and user feedback.
- Chrome 134 on Windows, macOS
- URL filtering on iOS and Android
We will extend the existing URL filtering capabilities from desktop to mobile platforms, providing organizations with the ability to audit, warn, or block certain URLs or categories of URLs from loading on managed Chrome browsers or managed user profiles on mobile devices. This includes ensuring the functionality works seamlessly with Context-Aware Access (CAA) which allows admins to set access policies based on user context (for example, user role, location) and device state (for example, managed device, security compliance).
- Chrome 135 on Android, iOS
- Reporting connector for mobile
We are working towards feature parity with the desktop version, enabling organizations to monitor and respond to security events on mobile devices, such as unsafe site visits and potential data exfiltration attempts. This helps ensure consistent security and policy enforcement across different platforms.
- Chrome 135 on Android, iOS
- Connectors API
We plan to simplify the setup process for third-party security connectors and enable providers to manage configurations directly from their own UI. This aims to make it easier for organizations to integrate their preferred security tools and services with Chrome, enhancing security and management across different platforms.
- Chrome 135 on Windows, macOS, Linux, ChromeOS
Sign up for emails about future releases
Previous release notes
|
Chrome version & targeted Stable channel release date |
|
|---|---|
| Chrome 132: January 8, 2024 | |
| Chrome 131: November 6, 2024 | |
| Chrome 130: October 9, 2024 | |
| Chrome 129: September 11, 2024 | |
| Previous release notes → |
Additional resources
- To try out new features before they're released, sign up for the trusted tester program.
- Connect with other Chrome Enterprise IT admins through the Chrome Enterprise Customer Forum.
- How Chrome releases work—Chrome Release Cycle.
- For specific dates, see the Chrome release schedule.
- 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.
- Developers: Learn about changes to the web platform.
Still need help?
- Google Workspace, Cloud Identity customers (authorized access only)—Contact support
- Chrome Browser Enterprise Support—Sign up to contact a specialist
- Chrome Administrators Forum
- Chrome Enterprise and Education Help Center