Previous release notes

Chrome 134 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Search your screen with Google Lens on Desktop and iOS		✓
Security & Privacy panel in Chrome DevTools	✓	✓
Better password form detection with ML	✓
Client’s LLM assistance in mitigating scams	✓
LLM-powered on-device detection of abusive notifications on Android			✓
Customizing managed profiles with custom logo and label		✓	✓
Device Bound Session Credentials google.com prototype	✓
Password change	✓
Read aloud in Reading mode in Chrome 134		✓
Restrict unpacked extensions to developer mode	✓
Show settings for AI features in policy level 2 in settings			✓
Customizable <select> element		✓
HTML parser relaxation for <select>	✓
Remove nonstandard getUserMedia audio constraints	✓
Updates to Chrome sign-in flows for managed users	✓
New tab page cards for Microsoft Outlook and Sharepoint		✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Chrome Enterprise Companion			✓
DownloadRestrictions policy support on iOS	✓
Recommended policies (User override)			✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Evidence Locker	✓
Screenshot prevention	✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Deprecate mutation events		✓
Extensions improvements on Chrome Desktop	✓	✓
Removal of Private Network Access enterprise policies	✓
Remove ThirdPartyBlockingEnabled policy			✓
Settings, site shortcuts, and themes improvements on Chrome Desktop	✓
Sunsetting the legacy Password Manager in Chrome on Android	✓
Third-party cookies always blocked in Incognito mode	✓
Blob URL Partitioning: Fetching/Navigation	✓
Create service worker client and inherit service worker controller for srcdoc iframe	✓
Deprecate getters of Intl Locale Info	✓
Partitioning :visited links history	✓
HSTS tracking prevention	✓
Remove deprecated navigator.xr.supportsSession method	✓
Strict same-origin policy for Storage Access API	✓
UI Automation accessibility framework provider on Windows		✓
Remove SwiftShader fallback	✓
Disallow spaces in non-file:// URL hosts	✓
SafeBrowsing API v4 → v5 migration	✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Extensible SSO support for Chrome on macOS		✓	✓
Isolated Web Apps	✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Refactor DLP rules user experience	✓
URL filtering on iOS and Android	✓
Reporting connector for mobile	✓
Connectors API	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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

 

   

• Search your screen with Google Lens on Desktop and iOS 

  Admins can control all elements of this feature through a policy called LensOverlaySettings. To perform the search, a screenshot of the screen is sent to Google servers but it is not linked to any IDs or accounts, it is not viewed by any human, and data about its contents is not logged. To contextualize the search to the document or website the user is viewing, the PDF bytes or website HTML is sent to Google servers but is not linked to any IDs or accounts, not viewable by any human, and the data or data generated about its contents is not logged.

   

  Desktop

  Since Chrome 126, users can search any images or text they see on their Desktop screen with Google Lens. To use this feature, go to a website and click the Google Lens chip on the on-focus omnibox or right-click an image and select Search with Google Lens. Users can select anywhere on the screen to search its contents, and refine their search by adding questions to the search box. Starting in Chrome 132, users can also ask questions about entire web pages or PDF documents and answers will reference their current document and the web. To use this feature, invoke Search with Google Lens as described above and enter queries into the search box on the top right corner of the Chrome window. A side panel will open on the right side of the browser window with search results. 

   

  iOS

  Since Chrome 131, users can search any images or text they see on their iOS Chrome screen with Google Lens. To use this feature, go to a website and click on the 3-dot menu > Search with Google Lens. Starting in Chrome 134, users can also invoke this feature by clicking the Google Lens icon on the left side of the omnibox. Users can click, highlight, or drag anywhere on the screen to search its contents, and refine their search by adding keywords or questions to the search box.

   

  Rollout details:

  • Chrome 126 on ChromeOS, Linux, macOS, Windows: Rollout of the feature to 1% Stable
  • Chrome 127 on ChromeOS, Linux, macOS, Windows: Rollout to 100% Stable
  • Chrome 131 on iOS: Rollout of the feature to 1% Stable
  • Chrome 132 on ChromeOS, Linux, macOS, Windows: Rollout of the expanded feature to 1% Stable
  • Chrome 133 on iOS: Rollout to 100% Stable
  • Chrome 134 on iOS: Rollout of the expanded feature to 100% Stable
   

   

• Security & Privacy panel in Chrome DevTools 

  Starting in Chrome 134, developers can use the new Security & Privacy panel in Chrome DevTools to test how their site behaves when third-party cookies are limited. Developers can temporarily limit third-party cookies, observe how their site behaves, and review the status of third-party cookies on their site.

   

  

   

  This feature does not make any permanent changes to existing enterprise policies, but it lets third-party cookie related enterprise policies (that is, BlockThirdPartyCookies and CookiesAllowedForUrls) be temporarily overridden, to test enhanced restrictions. If your enterprise policy already blocks third-party cookies using BlockThirdPartyCookies, this feature will be disabled.

   

  The new Security & Privacy panel replaces the existing Security panel. TLS connection and certificate information continue to be available on the Security menu on the left, within the Security & Privacy panel.

   
  • Chrome 134 on ChromeOS, Linux, macOS, Windows
   

   

• Better password form detection with ML 

  Chrome 134 introduces a new client-side Machine Learning (ML) model to better parse password forms on the web to increase detection and filling accuracy. You can control this feature using the PasswordManagerEnabled policy.

  • Chrome 134 on Android, iOS, ChromeOS, Linux, macOS, Windows
   

   

• Client’s LLM assistance in mitigating scams 

  Users on the webs are facing enormous amounts of several kinds of scams a day. To combat these scams, Chrome will leverage on-device Large Language Model (LLM) to identify scam websites for Enhanced Safe Browsing (ESB) users. Chrome will send the page content to an on-device LLM to infer security-related signals of the page and send these signals to Safe Browsing server side for a final verdict. When enabled, Chrome may consume more bandwidth to download the LLM. 

  An enterprise policy SafeBrowsingProtectionLevel is available to control safe browsing and the mode it operates in.

   
  • Chrome 134 on Linux, macOS, Windows

    Gather the brand name and intent summary of the page that requested keyboard lock API to identify scam websites.

   

   

• LLM-powered on-device detection of abusive notifications on Android 

  This launch aims to hide the contents of notifications that are suspected to be abusive. The user then has the options to dismiss, show the notification, or unsubscribe from the origin. This detection is to be done by an on-device model.

   
  • Chrome 134 on Android
   

   

• Customizing managed profiles with custom logo and label 

  New toolbar and profile menu customizations that help users easily identify if their Chrome profile is managed, whether they're on a work or personal device. This is especially useful for scenarios where employees use their own devices with managed accounts.

  To help tailor this experience, we're adding three new policies:

  • EnterpriseCustomLabel: Customize the text displayed on the toolbar element to match your organization's branding.
  • EnterpriseLogoUrl: Add your company logo to the profile menu.
  • EnterpriseProfileBadgeToolbarSettings: This policy can disable the default label for a managed profile in the Chrome toolbar. 

  In Chrome 134, these policies will be available to customize the logo and label shown on a managed profile. The policies will take effect on user’s managed profiles. 

   

  Starting Chrome 135, there will be updates to the default behavior of the profile label and icon overlaid on the account avatar. Managed profiles will show a work or school label in addition to the profile disk. In the profile menu, there will be a building icon overlaid on the account avatar. The expanded profile disk can be disabled via EnterpriseProfileBadgeToolbarSettings.

   
  • Chrome 134 on macOS, Windows, Linux

    Policies to customize the toolbar label and icon (in profile menu) are available in the Admin console. If policies have already been set, the user will see the customized logo and label.

  • Chrome 135: Starting rollout of defaults including: 
    • 1) work or school label shown in toolbar, next to user avatar 
    • 2) A building icon overlayed on the user's account photo in the profile menu. The label can be turned off via EnterpriseProfileBadgeToolbarSettings. Starting with 1% and gradual slow rollout thereafter.
   

  

   

   

• Device Bound Session Credentials google.com prototype 

  The Device Bound Session Credentials (DBSC) project is intended to move the web away from long-lived bearer credentials like cookies, which can be stolen and reused, to credentials which are either short-lived or cryptographically bound to a device. 

  The feature aims at protecting users against credential theft which is typically performed by malware running on the user's device. 

  The current launch is a proof-of-concept targeting the google.com website. In the future, we plan to standardize this approach for other websites and web browsers.

  Enterprise admins can control the feature state using the BoundSessionCredentialsEnabled boolean policy.

  • Chrome 124 on Windows

    Planned 1% rollout on Chrome stable for google.com cookie binding for the general population.

  • Chrome 134 on Windows

    Added binding support for OAuth2.0 refresh tokens that are used for Chrome sign-in.

   

   

• Password change 

  This feature gives users the option to change leaked credentials immediately. The feature can only be triggered from the Check your Password dialog. When users see a warning for an eligible website, they can change the password there and then. 

   
  • Chrome 134 on 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 now includes a Read aloud feature that allows users to hear the text they are reading spoken out loud. You can choose different natural voices and speeds, and see visual highlights as the text is spoken. 

   
  • Chrome 134 on Linux, macOS, Windows
   

   

• Restrict unpacked extensions to developer mode 

  Starting in Chrome 134, unpacked extensions loaded from the chrome://extensions page will only be enabled if the developer mode switch is turned on. This change is intended to improve security by mitigating the risks associated with harmful unpacked extensions and developer mode tampering exploitation. An enterprise policy, ExtensionDeveloperModeSettings, is available to gate the existing developer mode switch.

   
  • Chrome 134 on ChromeOS, Linux, macOS, Windows
    The feature will roll out to 100% of users on Chrome 134.
   

   

• Show enterprise settings for AI features 

  Previously, AI features were hidden from settings when they are disabled by enterprise policy. Now, we will keep showing the features and show a Disabled by your organization notice, similar to other settings when they are disabled by policy.

   
  • Chrome 134 on ChromeOS, Linux, macOS, Windows
   

   

• Customizable <select> element 

  Customizable <select> allows developers to take complete control of the rendering of <select> elements by adding the appearance:base-select CSS property.

  This feature relies on the SelectParserRelaxation flag, which changes the HTML parser to allow more tags within the <select> tag. Sites that include additional tags inside <select>, which were getting removed before, such as <span> tags, or sites that include an extremely large number of <option> tags in their <select>, might be affected by SelectParserRelaxation. This feature and SelectParserRelaxation can be controlled with the SelectParserRelaxation enterprise policy. Some issues that have come up in prior launches of SelectParserRelaxation include <select> elements taking a very long time to open or <option> tags not showing up anymore.

   
  • Chrome 134 on Windows, macOS, Linux, Android
   

   

• HTML parser relaxation for <select> 

  In Chrome 134, the HTML parser allows more tags in <select> in addition to <option>, <optgroup>, and <hr>.

  This supports the customizable <select> feature but is being shipped first because it can be done separately and has some compatibility risk.

  This feature is gated by the temporary policy SelectParserRelaxationEnabled. This is a temporary transition period, and the policy will stop working by Chrome 141.

  For more details, see the Customizable Select Element (Explainer).

   
  • Chrome 134 on Windows, macOS, Linux, Android
   

   

• Remove nonstandard getUserMedia audio constraints 

  Chrome 134 removes a number of nonstandard goog-prefixed constraints for getUserMedia, which existed before audio 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
   

   

• Updates to Chrome sign-in flows for managed users 

  Enterprise users signing into the web or Chrome now see refreshed sign-in flows and management disclosures. In addition, the user might be prompted to create a new profile or continue working in the existing profile. Admins can continue to use BrowserSignIn or ProfileSeparationSettings to enforce a managed profile.  

   
  • Chrome 134 on Linux, macOS, Windows Roll-out continues
     

  

   

   

• New tab page cards for Microsoft Outlook and Sharepoint 

  Enterprise users with Outlook or Sharepoint can now access their upcoming meetings or suggested files directly from the New tab page. This streamlined experience eliminates the need to switch tabs or waste time searching for your next meeting, allowing you to focus on what matters most. Admins who are interested in testing out this feature can Sign up to become a Trusted Tester.

   
  • Available to Trusted Testers Chrome 134 on Windows, macOS, Linux

   

• New policies in Chrome browser 

  Policy	Description
  ProfileSeparationDataMigrationSettings	Profile separation data migration settings
  NTPSharepointCardVisible	Show SharePoint and OneDrive File Card on the New Tab Page
  NTPOutlookCardVisible	Show Outlook Calendar card on the New Tab Page
  ServiceWorkerToControlSrcdocIframeEnabled	Allow ServiceWorker to control srcdoc iframes
  PasswordManagerPasskeysEnabled	Enable saving passkeys to the password manager

   

   

• Removed policies in Chrome browser 

  Policy	Description
  No policies removed in Chrome 134

   

   

Chrome Enterprise Core changes

   

• Chrome Enterprise Companion 

  Chrome Enterprise Companion 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
   

   

• DownloadRestrictions policy support on iOS 

  DownloadRestrictions is a universal policy available to Chrome Enterprise Core users on Desktop platforms and on Android. The DownloadRestrictions policy is now supported on iOS. This allows admins to block all downloads on mobile Chrome on iOS. 

   
  • Chrome 135 on iOS
   

   

• Recommended policies (User override) 

  Chrome has introduced the User override configuration in the Google Admin console for policies that can be set as recommended. This means that IT administrators can apply a policy value and allow users to override the policy value.

  
   
  • On Chrome 134: the following policies are supported: BookmarkBarEnabled, PasswordManagerEnabled, PinUnlockAutosubmitEnabled, SchedulerConfiguration, PrintHeaderFooter, TranslateEnabled, SpellCheckServiceEnabled, ShowFullUrlsInAddressBar

   

Chrome Enterprise Premium changes

 

   

• Evidence Locker 

  Evidence Locker allows Chrome Enterprise Premium administrators to store and inspect files that are flagged as malware or those that violate a Data Protection rule. A copy of the file is saved to the Google Cloud Storage bucket that is owned and specified by the organization. The security administrator can investigate the incidents using the security investigation tool and download the files that triggered the incident to analyze further. For more details, see Investigate and take action on suspicious files.

   
  • Chrome 134 on ChromeOS, Linux, macOS, Windows
   

  

  

   

• Screenshot prevention 

  Chrome 134 enhances the existing screenshot prevention feature by extending screen-sharing blocking to meeting apps like Google Meet, Zoom, Teams, and Slack. With this update, we build upon the successful release of data protection controls by adding key features and addressing gaps and user feedback.

   
  • Chrome 134 on Windows, macOS

 

Read more about the differences between Chrome Enterprise Core and Chrome Enterprise Premium.

Upcoming Chrome browser changes

 

    

• Deprecate mutation events 

  Synchronous mutation events, including DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, and DOMCharacterDataModified, 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 Chrome for Developers blog post. If you encounter any issues, you can file a Chromium bug.

  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.

    

• Extension improvements on Chrome Desktop 

  On Chrome 135 on Desktop, some users who sign in to Chrome when installing a new extension can now use and save extensions in their Google Account. 

  Relevant enterprise policies controlling extensions, as well as BrowserSignin, SyncDisabled or SyncTypesListDisabled, will continue to work as before, so admins can configure whether users can use and save items in their Google Account.

  For more information about how to use extensions on any computer, see  Install and manage extensions in the Chrome Web Store help center.

  Note: this change is a follow-up to the launch of the new identity model on Chrome Desktop. 

   
  • Chrome 135 on Linux, macOS, Windows

    

• Removal of Private Network Access enterprise policies 

  Private Network Access (PNA 1.0) is an unshipped security feature designed to limit website access to local networks. Due to deployability concerns, PNA 1.0 was never able to ship by default, as it was incompatible with too many existing devices.

  PNA 1.0 required changes to devices on local networks. Instead, Chrome is implementing an updated proposal, Private Network Access 2.0 (PNA 2.0). PNA 2.0 only requires changes to sites that need to access the local network, rather than requiring changes to devices on the local network. Sites are much easier to update than devices, and so this approach should be much more straightforward to roll out. 

  The only way to enforce PNA 1.0 is via enterprise policy. To avoid regressing security for enterprise customers opting-in to PNA 1.0 prior to shipping PNA 2.0, we will maintain the PrivateNetworkAccessRestrictionsEnabled policy, which causes Chrome to send special preflight messages, until such time that it becomes incompatible with PNA 2.0.

  The InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed policies, which loosen PNA 1.0 restrictions, will be removed in Chrome 135. These policies currently have no effect, since PNA 1.0 is not shipped, and they will have no meaning once PNA 1.0 is removed.

  PNA 2.0 is described in this explainer on GitHub.

  • Chrome 135 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia

    Removal of InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed policies.

  • Chrome 137 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia

    Removal of PrivateNetworkAccessRestrictionsEnabled.

    

• Remove ThirdPartyBlockingEnabled policy 

  Due to unexpected issues, ThirdPartyBlockingEnabled will be removed in Chrome 135. If you have feedback about this removal, you can file a Chromium bug.

  • Chrome 132 on Windows
    Deprecation of ThirdPartyBlockingEnabled policy
  • Chrome 135 on Windows
    Removal of ThirdPartyBlockingEnabled policy

    

• Settings, site shortcuts, and themes improvements on Chrome Desktop 

  On Chrome 135 on Desktop, for users who newly sign in to Chrome or who have Sync enabled, settings, site shortcuts and themes synced to their Google Account will now 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 signing in or turning on Sync, and no settings from the account are left behind on the device when Sync is turned off.

  Existing enterprise policies SyncDisabled and SyncTypesListDisabled will continue to apply so admins can restrict or disable the Sync feature if they want to.

  Note: This change is a follow-up to the launch of the new identity model on Chrome Desktop. For more details, see Chrome Platform Status.

   
  • Chrome 135 on Linux, macOS, Windows

    

• Sunsetting the legacy Password Manager in Chrome on Android 

  Users with old versions of Google Play Services will lose Password Manager functionality in Chrome. This is a step towards sunsetting the legacy Password Manager in Chrome on Android. These users can download a CSV file with their passwords from Chrome Settings and import it to their preferred Password Manager. The new Google Password Manager is available on devices with a recent version of Google Play Services.

   
  • Chrome 135 on Android

    

• Third-party cookies always blocked in Incognito mode 

  Starting in Chrome 135, users will start having third-party cookies blocked in Incognito mode with no way to globally re-enable them. Site-level controls for allowing third-party cookies will not be changed. 

  With this launch, the BlockThirdPartyCookies policy will only apply to regular mode when set to false, not Incognito mode. There will be no changes when the policy is true or unset. There will also be no changes to the CookieAllowedForUrls policy, which will continue to apply in both regular and Incognito modes, as it applies at the site level and not globally.

   
  • Chrome 135 on Android, 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 135 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 135 on Windows, macOS, Linux, Android

    

• 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

    

• Partitioning :visited links history 

  To eliminate user browsing history leaks, anchor elements are styled as :visited only if they have been clicked from this top-level site and frame origin before. On the browser-side, this means that the VisitedLinks hashtable is now partitioned by triple-keying, or by storing the following for each visited link: <link URL, top-level site, frame origin>. By only styling links that have been clicked on this site and frame before, the many side-channel attacks that have been developed to obtain :visited links styling information are now obsolete, as they no longer provide sites with new information about users. 

  There is an exception for self-links, where links to a site's own pages can be styled as :visited even if they have not been clicked on in this exact top-level site and frame origin before. This exemption is only enabled in top-level frames or subframes, which are same-origin with the top-level frame. The privacy benefits above are still achieved because sites already know which of its subpages a user has visited, so no new information is exposed. This was a community-requested exception that improves user experience as well.

  • Chrome 135 on Windows, macOS, Linux, Android

    

• HSTS tracking prevention 

  HTTP Strict Transport Security (HSTS) allows sites to declare themselves accessible through secure connections only. As early as Chrome 135, HSTS tracking prevention will mitigate user tracking by third-parties using the HSTS cache. It only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. This will prevent third-party sites using the HSTS cache to track users across the web. For more information, see this HSTS tracking prevention explainer on Github.

  • Chrome 135 on Windows, macOS, Linux, Android

    

• Remove deprecated navigator.xr.supportsSession method 

  navigator.xr.supportsSession was replaced in the WebXR spec by the navigator.xr.isSessionSupported method in September of 2019 after receiving feedback on the API shape from the TAG. It has been marked as deprecated in Chromium since then, producing a console warning redirecting developers to the updated API.

  Usage of the call is very low, as shown by Chrome Status usage metrics. Additionally, all major frameworks that are used to build WebXR content have been confirmed to have been updated to use the newer call.

  • Chrome 135 on Windows, macOS, Linux, Android

    

• Strict Same Origin policy for Storage Access API 

  Chrome 135 will adjust Storage Access API semantics to strictly follow the Same Origin policy, to enhance security. This means that using document.requestStorageAccess() in a frame will only attach cookies to requests to the iframe's origin (not site) by default.

  Note: the CookiesAllowedForUrls policy or Storage Access headers can still be used to unblock cross-site cookies.

  • Chrome 135 on Windows, macOS, Linux, Android

    

• 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.

 

    

• Remove SwiftShader fallback 

  As early as Chrome 137, we plan to deprecate automatic fallback to WebGL backed by SwiftShader. WebGL context creation will fail instead of falling back to SwiftShader. We plan to remove SwiftShader fallback  for two primary reasons:

  1. SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process.
  2. 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.

  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.

  • Chrome 137 on Windows, macOS, Linux, Android

 

    

• 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 in non-file URLs only.

  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia

    

• 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 145 on Android, iOS, ChromeOS, Linux,  macOS, Windows

    This will be a gradual roll-out.

 

 

Upcoming Chrome Enterprise Core changes

    

• Apple Extensible SSO support for Chrome on macOS 

  Chrome 135 on macOS will enable seamless authentication for identity providers that are enabled via an OS-configured Enterprise Single Sign On (SSO) extension. For this initial release, it will allow end users on managed browsers to sign in to any Microsoft Entra-authenticated resources without the need to enter any credentials. Extensible SSO needs to be pre-configured in your environment and deployed with its respective enterprise device management solution. Additional identity providers might be supported in the near future.

  • As early as Chrome 135 on macOS

 

    

• Isolated Web Apps 

  Isolated Web Apps (IWAs) are an extension of existing work on PWA installation and Web Packaging that provide stronger protections against server compromise and other tampering, which is necessary for developers of security-sensitive applications.

  Rather than being hosted on live web servers and fetched over HTTPS, these applications are packaged into Web Bundles, signed by their developer, and distributed to end-users through one or more of the potential methods described in Getting started with Isolated Web Apps.

  In the initial release, IWAs will only be installable through a policy on enterprise-managed ChromeOS devices.

  • Chrome 140 on Windows

    This rollout adds support for Isolated Web Apps in enterprise-managed browser configurations on Windows.

 

 

Upcoming Chrome Enterprise Premium changes

 

   

• Refactor DLP rules user experience  

  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 135 on Windows, macOS, Linux, ChromeOS
   

   

• 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 137 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 136 on Android
  • Chrome 137 on 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 137 on Windows, macOS, Linux, ChromeOS

Chrome 133 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Search with Google Lens on Desktop and iOS		✓
Ad-hoc code signatures for PWA shims on macOS		✓
Chrome Sync stops support for Chrome versions more than four years old		✓
New option in HttpsOnlyMode policy	✓		✓
Tab freezing on Energy saver		✓
V8 security setting on Android	✓
Chrome Welcome page no longer triggered using initial_preferences	✓
Support for non-special scheme URLs	✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
DownloadRestrictions policy support on iOS	✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
No updates in Chrome 133.
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Privacy and security panel in Chrome DevTools	✓	✓
Read aloud in Reading mode in Chrome 134		✓
Highlight  settings for AI features disabled by policy	✓
Blob URL Partitioning: Fetching/Navigation	✓
Create service worker client and inherit service worker controller for srcdoc iframe	✓
Fire error event instead of throwing exception for CSP blocked worker	✓
Remove nonstandard getUserMedia audio constraints	✓
Deprecate mutation events		✓
Cross-device synchronization of Chrome settings and themes on Desktop at sign-in	✓
Disallow spaces in non-file:// URL hosts	✓
Remove ThirdPartyBlockingEnabled policy			✓
Deprecate getters of Intl Locale Info API	✓
Remove SwiftShader fallback	✓
UI Automation accessibility framework provider on Windows		✓
SafeBrowsing API v4  to v5 migration	✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
New Chrome Enterprise Companion		✓	✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Refactor DLP rules user experience	✓
Screenshot prevention	✓
URL filtering on iOS/Android	✓
Reporting connector for mobile	✓
Connectors API	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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

 

   

• Search with Google Lens on Desktop and iOS 

  Admins can control all elements of this feature through a policy called LensOverlaySettings. To perform the search, a screenshot of the screen is sent to Google servers but it is not linked to any IDs or accounts, it is not viewed by any human, and data about its contents is not logged. To contextualize the search to the document or website the user is viewing, the PDF bytes or website HTML is sent to Google servers but is not linked to any IDs or accounts, not viewable by any human, and the data or data generated about its contents is not logged.

   

  Desktop

  Since Chrome 126, users can search any images or text they see on their Desktop screen with Google Lens. To use this feature, go to a website and click the Google Lens chip on the on-focus omnibox or by right-clicking on an image and selecting Search with Google Lens. Users can select anywhere on the screen to search its contents, and refine their search by adding questions to the search box. Starting in Chrome 132, users can also ask questions about entire web pages or PDF documents and answers will reference their current document and the web. To use this feature, invoke Search with Google Lens as described above and enter queries into the search box on the top right corner of the Chrome window. A side panel will open on the right side of the browser window with search results. 

   

  iOS

  Since Chrome 131, users can search any images or text they see on their iOS Chrome screen with Google Lens. To use this feature, go to a website and click on the 3-dot menu > Search with Google Lens. Users can click, highlight, or drag anywhere on the screen to search its contents, and refine their search by adding keywords or questions to the search box.

   

  Rollout details:

  • Chrome 126 on ChromeOS, Linux, mac, Windows: Rollout of the feature at 1% Stable
  • Chrome 127 on ChromeOS, Linux, mac, Windows: Rollout to 100% Stable
  • Chrome 131 on iOS: Rollout of the feature at 1% Stable
  • Chrome 132 on ChromeOS, Linux, mac, Windows: Rollout of the expanded feature at 1% Stable
  • Chrome 133 on iOS: Rollout to 100% Stable

 

   

• 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 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 take effect. 

   

   

• 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/security to 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 Welcome page no longer triggered using initial_preferences 

  We have removed the Chrome Welcome page from initial_preferences because that page is redundant with the First Run Experience that triggers on desktop platforms. Including chrome://welcome in the first_run_tabs property of the initial_preferences file 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.

Read more about the differences between Chrome Enterprise Core and Chrome Enterprise Premium.

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 a 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, and DOMCharacterDataModified, 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

    

• 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:

  1. SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process.
  2. 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.

  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.

   
  • Chrome 135 on Windows,  macOS, Linux, Android

    

• 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

ChromeOS 133 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Enhanced Office file handling for managed users		✓	✓
Make cloud storage the sole data storage option on ChromeOS devices	✓		✓
Bounce Keys on ChromeOS		✓
Enhanced Welcome Tour		✓
ChromeOS policy for keyboard languages		✓	✓
Screencast language update		✓
New toggle for Bluetooth mic super resolution		✓
ChromeOS LTS 132 release candidate			✓
Kiosk health monitoring			✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Kiosk Heartbeat change			✓
Isolated Web Apps in ChromeOS kiosk mode		✓
Migrate data for graduating students			✓
ChromeOS policy for battery longevity			✓
Slow Keys		✓	✓
GIFs with Quick Insert		✓
AI wallpapers and backgrounds		✓
Deprecating Chrome Apps support on ChromeOS		✓	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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.

ChromeOS updates

   

• Enhanced Office file handling for managed users 

  Starting from ChromeOS 133, managed users can now seamlessly open and edit their Microsoft Office files (Word, PowerPoint, Excel), regardless of whether they use Office for the web in Microsoft 365 or Google Workspace.

  Organizations using Office for the web benefit from OneDrive integration into the Files app, Microsoft 365 PWA system integrations for a desktop-like experience, SSO for all required applications, and advanced policy controls for preconfiguration.

  For Google Workspace customers, the transition of local files to Google Workspace is optimized.

  For more information, see Set up Office file handling for managed users in the Chrome Enterprise and Education Help Center.

  New policies for Microsoft Office file handling include:

  • MicrosoftOneDriveMount
  • MicrosoftOneDriveAccountRestrictions
  • MicrosoftOfficeCloudUpload
  • GoogleWorkspaceCloudUpload
  • QuickOfficeForceFileDownloadEnabled

   

• Make cloud storage the sole data storage option on ChromeOS devices 

  ChromeOS 133 introduces a true cloud-first experience, allowing admins to ensure that all files are stored on either Google Workspace or Microsoft OneDrive by blocking local storage. This feature prevents data loss, reduces security risks, supports legal hold requirements, and is particularly beneficial for shared devices.

  For more information, see Use cloud storage as sole storage option on ChromeOS devices in the Chrome Enterprise and Education Help Center.

  New policies for cloud storage include:

  • LocalUserFilesAllowed
  • LocalUserFilesMigrationDestination
  • DownloadDirectory (OneDrive support)
  • ScreenCaptureLocation

   

• Bounce Keys on ChromeOS 

  Bounce Keys is an accessibility feature designed to make computer use easier for individuals with limited dexterity or tremors. It works by ignoring repeated keystrokes within a short time interval, which you can customize to fit your needs. This prevents unintended characters being entered due to unintentional key presses.

   

  

  
   

   

• Enhanced Welcome Tour 

  New ChromeOS users are now greeted with a Welcome Tour immediately after device setup. Welcome Tour provides an interactive way for users to learn the basics and to get up and running on their new Chromebook quickly.

  

   

• New ChromeOS policy for keyboard languages  

  As early as ChromeOS 133, a new AllowedInputMethodsForceEnabled policy allows administrators to automatically install keyboard languages previously set by AllowedInputMethods. The user can not add new or remove selected keyboard languages when the policy is set.

   

• Screencast language update 

  Screencast now supports over 50 languages. To use Screencast, press the Launcher icon and search for Screencast. You can find the list of languages in the Help Center article: Use the Screencast app to record and share on your ChromeOS devices.

   

  

     

   

• New toggle for Bluetooth mic Super Resolution 

  ChromeOS 133 adds a toggle to control Bluetooth mic Super Resolution. The toggle is added in the audio setting page and is only visible when the feature is supported and the selected input device is a Bluetooth headset.

  

     

   

• ChromeOS LTS 132 

  ChromeOS LTS 132 release candidate is now available. For details, see ChromeOS Long-term Support (LTS) release notes. 

   

• Health monitoring for Kiosk devices 

  ChromeOS 133 improves status update latency for health monitoring for Kiosk devices. Under ideal conditions, status updates for Kiosk devices are now reported in about a minute. Offline status should now be sent or updated within 11 minutes. For more information, see Monitor kiosk health in the Chrome Enterprise and Education Help Center.

Upcoming ChromeOS changes

   

• Kiosk Heartbeat change  

  Last summer, we sent out an MSA to inform the customer about a migration of the Kiosk Heartbeat API that ultimately needs an update to ChromeOS 126.

  If your organization is running a version older than ChromeOS 126, you need to update your device fleet. This kiosk heartbeat change requires an update to ChromeOS 126 or ChromeOS LTS 126 or to update to the current stable ChromeOS release.

  • What do you need to do?

  Please ensure you have activated (value: 0) DeviceChromeVariation for your organization until all devices have been updated to LTS132.

  Once all devices are on LTS132,  DeviceChromeVariation is not needed anymore and can be changed to any value.  

  • What happens when DeviceChromeVariation is deactivated?

  Devices on LTS versions older than LTS132 will keep using the old Kiosk Heartbeat infrastructure until April 7th, 2025.

  Starting April 8th, 2025, all devices on LTS versions older than ChromeOS LTS 132 will stop sending device heartbeats.

   

• Isolated Web Apps in ChromeOS kiosk mode  

  In ChromeOS 134, ChromeOS kiosk mode will support Isolated Web Apps, a more secure and versatile app solution with access to deep system integrations and powerful capabilities. Administrators will be able to configure IWAs for kiosk and digital signage deployments on Chrome Enterprise⁠ managed devices through the Admin console⁠. 

   

• Migrate data for graduating students  

  As early as March 2025, the new content transfer tool will guide graduating students or other EDU-managed users who want to migrate their data through the updated Google Takeout transfer process. This will allow them to take their Docs, Sheets, Slides, and Gmail content to a Gmail account of their choice. 

  This new application allows school administrators to pin an icon to the shelf, notify students and faculty on their Chromebooks, and set dates to trigger these nudges to encourage them to use content transfer.

   

  

   

• New ChromeOS policy for battery longevity  

  In ChromeOS 134, we will introduce a new battery charge limit policy that will offer more optimization options, which will help extend the lifespan of Chromebooks. Administrators will still be able to set a maximum charge limit, with 100% as the default, to minimize battery degradation and improve long-term reliability. This new policy will benefit both administrators managing fleets of devices, such as in educational settings, and individual users seeking to maximize their Chromebook's longevity. This policy will automatically apply and will require no user interaction.

   

• Slow Keys  

  Slow Keys is an accessibility feature designed to assist individuals with limited dexterity in typing more accurately. This feature is particularly helpful for those who have conditions such as tremors, arthritis, or numbness in their fingertips, which can make it difficult to press keys with precision. Slow Keys will work by introducing a delay, requiring keys to be held down for a set amount of time before they are registered. This will prevent unintended keystrokes from being pressed. 

  

   

• GIFs with Quick Insert  

  Quick Insert will soon support direct GIF insertion! Quickly add GIFs to your messages and documents without leaving the Quick Insert menu. For more details, see Use Quick Insert to add & create content.

   

• AI wallpapers and backgrounds  

  As early as ChromeOS 135, we plan to introduce high-resolution, generative AI wallpapers and video call backgrounds on ChromeOS. With this feature, you can unleash your creativity and turn your Chromebook into a canvas of personal expression. Choose from a diverse collection of templates and, in just a few clicks, infuse your Chromebook with your unique personality, mood, or interest. 

  Two new policies will be available to control these features; GenAIVcBackgroundSettings and GenAIWallpaperSettings. This feature will be available on Chromebook Plus devices only.

   

• Deprecating Chrome Apps support on ChromeOS  

  In 2016, we announced the deprecation of Chrome Apps in favor of web apps, and in 2021, we announced on the Chromium Blog that support for Chrome Apps for ChromeOS Enterprise and Education customers and developers on ChromeOS would be extended until at least January 2025. With the majority of our customers having migrated off of Chrome Apps (including Legacy (v1) packaged apps and Hosted apps), we can confirm the following updates about Chrome Apps discontinuation dates.

   

  • July 2025: End of support for user-installed Chrome Apps (scheduled for ChromeOS M138).
    • Chrome Apps that are force-installed through the Admin console will continue to be supported.
  • July 2026: Last ChromeOS release with support for Chrome Apps in Kiosk Mode (scheduled for ChromeOS M150).
    • Devices on the LTS channel with Chrome Apps in Kiosk Mode will receive support until April 2027.
  • February 2028: Last ChromeOS release with support for Chrome Apps (scheduled for ChromeOS M168), marking the end of life for all Chrome Apps.
    • Devices on the LTS channel can continue to use Chrome Apps until October 2028.
    • No exceptions will be granted.

  These deprecation timelines also apply to self-hosted Chrome Apps.

  While no new Chrome Apps can be added to the Chrome Web Store, existing Chrome Apps can continue to be updated through October 2028 when they will reach end of life on ChromeOS. After this date, Chrome Apps will be removed from the Chrome Web Store.

  If your organization has developed in-house Chrome Apps and you need assistance, please refer to Transition from Chrome Apps guide. You can also join us in the ChromeOS developer community on Discord, or reach out to us through the form at https://chromeos.dev/work-with-us. Refer to the ChromeOS release schedule for release dates and updates.

  In the coming weeks, additional detailed information will be sent to all remaining Chrome App developers and all ChromeOS Administrators.

Chrome 132 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Search with Google Lens		✓
Network Service sandboxed on Windows	✓
Ad-hoc code signatures for Progressive Web App shims on macOS		✓
Batch upload		✓
Connectors Disclaimer workflow updates	✓
DownloadRestrictions is stricter on file type restrictions	✓
Updates to desktop identity model		✓
HTTPS-First Mode for Typically Secure Users	✓
Passkeys on iOS	✓	✓
Password Leak Toggle Move	✓
Removal of old Headless from the Chrome binary		✓
Remove ThirdPartyBlockingEnabled policy			✓
Remove enterprise policy used for legacy same site behavior			✓
Support non-special scheme URLs	✓
Translate for Search with Google Lens		✓
User Link capturing on PWAs		✓	✓
Keyboard-focusable scroll containers		✓
Remove prefixed HTMLVideoElement fullscreen APIs		✓
Throw exception for popovers or dialogs in non-active documents		✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Customized Chrome Web Store for enterprises		✓	✓
New Chrome user management capabilities in the Admin console			✓
Copy Source conditions in Chrome DLP Paste rule	✓
Generating insights for Chrome DevTools Console warnings and errors			✓
Professional Chrome Enterprise Administrator certification			✓
Server Root Certificates for Chrome Enterprise	✓		✓
Legacy Technology Report			✓
Recommended policies (user can override a policy value)		✓	✓
Updated Managed browser list: Most Recent Google Update Activity			✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
File Download Encryption for DLP Rules	✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Disallow spaces in non-file:// URL hosts	✓
Read aloud in Reading mode in Chrome 133		✓
Tab freezing on Energy saver		✓
Deprecate getters of Intl Locale Info	✓
Popover invoker and anchor positioning improvements		✓
Remove Chrome Welcome page triggering via initial prefs first run tabs	✓
Remove nonstandard getUserMedia audio constraints	✓
Remove SwiftShader fallback	✓
Privacy & security panel in Chrome DevTools	✓	✓
Chrome Sync will stop supporting Chrome versions that are more than four years old		✓
V8 security setting	✓
New option in HttpsOnlyMode policy	✓		✓
SafeBrowsing API v4 → SafeBrowsing API v5 migration	✓
Blob URL partitioning: Fetching or Navigation	✓
SharedWorker script inherit controller for blob script URL	✓
Deprecate mutation events		✓
UI Automation accessibility framework provider on Windows		✓
Customizing managed profiles with custom logo and label		✓	✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
New Chrome Enterprise Companion App		✓	✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Screenshot prevention V2	✓
URL filtering on iOS/Android	✓
Reporting connector for mobile	✓
Refactor DLP rules UX	✓
Connectors API	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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

 

   

• Search with Google Lens 

  In Chrome 132, we begin to roll out this enhanced feature across all platforms. Admins can control all elements of this feature through a policy called LensOverlaySettings. To perform the search, a screenshot of the screen is sent to Google servers but it is not linked to any IDs or accounts, it is not viewed by any human, and data about its contents is not logged. To contextualize the search to the document or website the user is viewing, the PDF bytes or website HTML is sent to Google servers but is not linked to any IDs or accounts, not viewable by any human, and the data or data generated about its contents is not logged.

   

  Desktop

  Since Chrome 126, users can search any images or text they see on their Desktop screen with Google Lens. To use this feature, go to a website and click the Google Lens chip on the on-focus omnibox or by right-clicking on an image and selecting Search with Google Lens. Users can select anywhere on the screen to search its contents, and refine their search by adding questions to the search box. Starting in Chrome 132, users can also ask questions about entire web pages or PDF documents and answers will reference their current document and the web. To use this feature, invoke Search with Google Lens as described above and enter queries into the search box on the top right corner of the Chrome window. A side panel will open on the right side of the browser window with search results. 

   

  iOS

  Since Chrome 131, users can search any images or text they see on their iOS Chrome screen with Google Lens. To use this feature, go to a website and click on the 3-dot menu > Search with Google Lens. Users can click, highlight, or drag anywhere on the screen to search its contents, and refine their search by adding keywords or questions to the search box.

   

  Rollout details:

  • Chrome 126 on ChromeOS, Linux, macOS, Windows: Rollout of the feature at 1% Stable
  • Chrome 127 on ChromeOS, Linux, macOS, Windows: Rollout to 100% Stable
  • Chrome 131 on iOS: Rollout of the feature at 1% Stable
  • Chrome 132 on ChromeOS, Linux, macOS, Windows: Rollout of the expanded feature at 1% Stable
     

   

• Network Service sandboxed on Windows   

  To improve security and reliability, the network service, already running in its own process, is now sandboxed on Windows. As part of this, third-party code that is currently able to tamper with the network service may be prevented from doing so. This might cause interoperability issues with software that injects code into Chrome's process space, such as Data Loss Prevention software. The NetworkServiceSandboxEnabled policy allows you to disable the sandbox if incompatibilities are discovered. You can test the sandbox in your environment using these instructions.

  You can report any issues you encounter.

   
  • Chrome 132 on Windows
    Network Service sandboxed on Windows
     

   

• Ad-hoc code signatures for Progressive Web App shims on macOS   

  Code signatures for the application shims that are created when installing a Progressive Web App 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 app 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 Progressive Web Applications in macOS's Open at Login preference pane, 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 132 on macOS
    This feature will begin to roll out to stable, starting at 1% rollout.
     

   

• Batch upload 

  Since Chrome 128, users have access to their passwords and addresses from their Google Account at the point of sign-in (in addition to their payment methods, which was an existing sign-in feature). These data-types have two distinct storages: local and account. With Chrome 132, we are providing users an opportunity to upload any local data they have to their Google Account. This will first be made available for passwords and addresses and will be expanded to include other data types in the future.

  The SyncTypesListDisabled policy applies equally to sync and data upload. Therefore, if either passwords or addresses are disabled, they are not made available for upload in the batch uploader.

   
  • Chrome 132 on Linux, macOS, Windows
   

  

     

   

• Connectors Disclaimer workflow updates 

  We have made updates to our Terms of Service for Chrome Enterprise Core that includes a section on 3rd party data-sharing. These updates improve the sign-up flow for Chrome browser Enterprise connectors.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows

   

• DownloadRestrictions is stricter on file type restrictions 

  You can control downloads within your organization using the DownloadRestrictions policy, with options to allow you select an appropriate level of file type restrictions:

  0 = No special restrictions. Default.
  1 = Block malicious downloads and dangerous file types.
  2 = Block malicious downloads, uncommon or unwanted downloads and dangerous file types.
  3 = Block all downloads.
  4 = Block malicious downloads. Recommended.

  Where option value = 1, this means:
  • Chrome browser blocks malicious files flagged by the Safe Browsing server AND blocks all dangerous file types. Only recommended for OUs, browsers, or users that have a high tolerance for false positives.

  Where option value = 2, this means:

  • Chrome browser blocks malicious files flagged by the Safe Browsing server AND blocks uncommon or unwanted files flagged by the Safe Browsing server AND blocks all dangerous file types. Only recommended for OUs, browsers, or users that have a high tolerance for false positives.

  Previously, the dangerous file types blocking was not being correctly applied by Chrome, and this has now been fixed. This means, however, that the policy is now much stricter on certain file types that could be dangerous to the user, like `.exe` or `.msi` files on Windows. If this induces too many false positives, you can leave the policy unset or set the policy value to 4.

  • Chrome 132 on Windows

   

• Updates to Chrome Identity model on desktop 

  Instead of having to set up Chrome sync on your device, you can now simply sign in to Chrome to access and save items to your Google Account. This new identity model on Desktop also includes an explicit sign-in to Chrome from a web sign-in.

  Signing into the web (using Gmail) prompts users to sign-in to Chrome. If they decline, they won’t be signed-in to Chrome, only to the web.

  • If they accept, profile management (user-based policies), payments (already available today), passwords, addresses, bookmarks*, extensions*, search engine prefs*, themes* and PWAs* will be enabled.
  • If they decline, Chrome can still use the sign-in credentials to facilitate a one-click sign-in to Chrome. 
  • Synchronizing history, Open tabs and tab groups still exist behind a separate opt-in for now.
  • Invalidated credentials (e.g. signing out of the web or remote sign-out) will put Chrome in a ‘pending’ state, previously ‘sync paused’. Autofill data will not be available from the user’s Google Account. Users in this state will be prompted to “Verify it’s you” in the Chrome toolbar.
   

  *These data types will be enabled behind sign-in (instead of sync opt in) in upcoming Chrome milestones.

  Web sign-in intercepts can be controlled using the SigninInterceptionEnabled policy. For more details, see Force users to create a separate profile.

   
  • Chrome 132 on Linux, macOS, Windows Roll-out starts
     
   

  

     

   

• HTTPS-First Mode for Typically Secure Users 

  HTTPS-First Mode (HFM) enables a default-HTTPS experience in Chrome by automatically upgrading sites to HTTPS. If a site doesn’t support HTTPS, HFM shows a warning before loading the HTTP version. HFM significantly improves the security guarantees of HTTPS by preventing loading of HTTP URLs without explicit user approval.

  HFM for typically secure users (this feature) is a heuristic that can automatically enable HFM for the user if the user has a typically secure browsing pattern. Typically secure browsing pattern is determined by keeping track of HTTPS-Upgrade fallbacks (failed HTTPS Upgrades, which would be HFM interstitials if the user manually enabled HFM) and a few other factors such as profile age and overall site engagement score.

  If these signals indicate that the user mostly visits secure sites, the heuristic will automatically enable HFM setting. HFM interstitials caused by this heuristic will display a custom message. The user can disable HFM by simply turning off the UI setting and the heuristic will never kick in again.

  This feature can be controlled using the existing enterprise policies HttpsOnlyMode and HttpAllowlist.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows, Fuchsia
     

   

• Passkeys on iOS 

  Passkeys are a more secure alternative to passwords. Unlike passwords, which can be phished or guessed, passkeys let users authenticate to sites and apps using public-key cryptography, as defined in the Webauthn standard.

  Google Password Manager passkeys are already available in Chrome on other platforms; this launch brings them to the iOS platform, through enhancements to Chrome's existing Credential Provider Extension ("Passwords in Other Apps"). Using the Extension, Google Password Manager passkeys can be used to sign in to pages in Chrome and other browsers, as well as to native apps.

  Passkeys are saved to a user's Google Account and available whenever the user is signed in to Chrome. Relevant enterprise policies such as BrowserSignin, SyncTypesListDisabled and PasswordManagerEnabled will continue to work as before and can be used to configure whether users can use and save passwords in their Google Account.

   
  • Chrome 132 on iOS
     

   

• Password Leak toggle move 

  The PasswordLeakDetectionEnabled toggle that was originally found on chrome://settings/security is moving from under the standard protection heading to further down on the page under the Advanced section. 

  This feature will also remove the PasswordLeakDetectionEnabled dependency on a user's safe browsing status. Previously, a user who had no protection or no safe browsing would not get the PasswordLeakDetectionEnabled functionality. Now, a user has free choice to select the PasswordLeakDetectionEnabled toggle regardless of their safe browsing protection level.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows, Fuchsia
     

   

• Removal of old Headless from the Chrome binary 

  Running Chrome with `--headless=old` no longer launches the old Headless mode, and instead prints the following log message:

  Old Headless mode has been removed from the Chrome binary. Please use the new Headless mode or the chrome-headless-shell which is a standalone implementation of the old Headless mode.

   
  • Chrome 132 on Linux, macOS, Windows
     

   

• 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
     

   

• Remove enterprise policy used for legacy same site behavior 

  In Chrome 79, we introduced the LegacySameSiteCookieBehaviorEnabledForDomainList policy to revert the SameSite behavior of cookies to legacy behavior on the specified domains. The LegacySameSiteCookieBehaviorEnabledForDomainList policy’s lifetime has been extended and will be removed in Chrome 132.

   
  • Chrome 132 on Android, ChromeOS, Linux, macOS, Windows
    Remove LegacySameSiteCookieBehaviorEnabledForDomainList policy
     

   

• Support non-special scheme URLs 

  Chrome 130 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. Now, 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 132 on Windows, macOS, Linux, Android
  • Chrome 134 on Windows, macOS, Linux, Android: Feature flag being removed
     

   

• Translate for Search with Google Lens 

  Augmented Reality-based (AR) Translation capabilities are being implemented to the Search with Google Lens feature. The LensOverlaySettings enterprise policy is in place allowing you to turn the feature on or off.

   
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
    In Chrome 131, the translate feature was introduced. In Chrome 132, the translate feature is being expanded with additional language support.
     

   

• User Link capturing on PWAs 

  Web links automatically direct users to installed web apps. To better align with users' expectations around installed web apps, Chrome makes it easier to move between the browser and installed web apps. When the user clicks a link that could be handled by an installed web app, Chrome adds a chip in the address bar to suggest switching over to the app. When the user clicks the chip, this either launches the app directly, or opens a grid of apps that can support that link. For some users, clicking a link always automatically opens the app.
  When some users click a link, it always opens in an installed PWA, while some users see the link open in a new tab with a chip in the address bar and clicking the chip launches the app. A flag is available to control this feature: chrome://flags/#enable-user-link-capturing-pwa.

   
  • Chrome 132 on Linux, macOS, Windows
    Launch to 100% of Stable with either a default on (always launch apps on link clicks) or a default off (always open in a tab, only launch if the user clicks on chip on address bar).
   

  

     

   

• Keyboard-focusable scroll containers 

  Improves accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more.

  By making scrollers focusable by default, users who can't (or don't want to) use a mouse will be able to focus clipped content using a keyboard's tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>.

   

  Note: The previous rollout of this feature (started first in Chrome 127 and again in Chrome 130) was stopped due to an accessibility regression, which should be fixed in the current implementation shipping in Chrome 132.

   
  • Chrome 132 on Windows, macOS, Linux, Android
     

   

• Remove Prefixed HTMLVideoElement Fullscreen APIs 

  The prefixed HTMLVideoElement-specific fullscreen APIs have been deprecated since Chrome 38. They were replaced by the Element.requestFullscreen() API, which first shipped un-prefixed in Chrome 71, in 2018. As of 2024, most browsers have had support for the un-prefixed APIs for a few years now.

  This feature tracks removing the following APIs from HTMLVideoElement:

  - readonly attribute boolean webkitSupportsFullscreen;

  - readonly attribute boolean webkitDisplayingFullscreen;

  - void webkitEnterFullscreen();

  - void webkitExitFullscreen();

  // Note the different capitalization of the "S" in FullScreen.

  - void webkitEnterFullScreen(); 

  - void webkitExitFullScreen();

   

  These methods are now only aliases for the modern API. Their use has declined steadily over the years.

   
  • Chrome 132 on Windows, macOS, Linux, Android
     

   

• Throw exception for popovers or dialogs in non-active documents 

  This is a corner case change that does not impact developers. Previously calling `showPopover()` or `showModal()` on a popover or dialog that resides within an inactive document would silently fail. This means that no exception would be thrown, but since the document is inactive, no popover or dialog would be shown. These situations now throw InvalidStateError. For more information, see the relevant spec pull request on Github.

  • Chrome 132 on Windows, macOS, Linux, Android
   

   

• New policies in Chrome browser 

  Policy	Description
  CACertificates	TLS certificates that should be trusted for server authentication
  CACertificateManagementAllowed	Allow users to manage all certificates
  CADistrustedCertificates	TLS certificates that should be distrusted for server authentication
  CAHintCertificates	TLS certificates that are not trusted or distrusted but can be used in path-building for server authentication
  CACertificatesWithConstraints	TLS certificates that should be trusted for server authentication with constraints
  PasswordManagerPasskeysEnabled	Enable saving passkeys to the password manager
  SharedWorkerBlobURLFixEnabled	Make SharedWorker blob URL behavior aligned with the specification
  TranslatorAPIAllowed	Allows the use of Translator API

   

   

• Removed policies in Chrome browser 

  Policy	Description
  LegacySameSiteCookieBehaviorEnabledForDomainList	Revert to legacy behavior for cookies on all sites
  NativeClientForceAllowed	Forces Native Client (NaCl) to be allowed to run
  PrefixedVideoFullscreenApiAvailability	Manage the deprecated prefixed video fullscreen API's availability

   

   

Chrome Enterprise Core changes

   

• Customized Chrome Web Store for enterprises 

  Admins can leverage new settings to customize the Chrome Web Store for their managed users, which includes the ability to:

  • Add company logos
  • Add hero banners and custom announcements
  • Curate extension collections
  • Hide extension categories

  These settings are configurable via the Admin console (learn more) and are available to all signed-in managed users (users signed-in to the Chrome Web Store with a managed Google Account). 

  Additionally, all managed users who sign in to the Chrome Web Store will see the following changes:

  • New tags for items “Blocked by their admin” when searching for an item
  • Private domain item search and advanced filtering capabilities
  • Private items and recommended items are relocated to the “Extensions” tab 

  Enrolled browsers (without the need to sign in) will be supported later in 2025.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
   

  

     

   

• New Chrome user management capabilities in the Admin console 

  Admins can now get more visibility into Chrome user profiles in their organization with a new profile list and reporting features for signed-in Google Accounts. This centralized view in the Google Admin console provides detailed reports about user profiles in your organization, including profile information, browser version, applied policies and installed extensions. For more details, see View Chrome browser profile details. 

  To get started, IT administrators can simply turn on the new Chrome Managed profile reporting policy to view the reporting information about managed profiles. 

   
  • Chrome 132 on Android, Linux, macOS, Windows
   

  

     

   

• Copy Source conditions in Chrome DLP paste rule 

  In this feature, we are adding copy source conditions, namely Source URL, Source URL category and Source Chrome context in Paste trigger rule for all customers. Admins can now create paste rules using the OnBulkDataEntryEnterpriseConnector policy, with conditions matching where the data or text being pasted is copied from. 

  For more details, see Use Chrome Enterprise Premium to integrate DLP with Chrome.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
    In this rollout, we are adding copy source conditions, namely Source URL category and Source Chrome context in Paste trigger rule for all customers.  Admins will be able to create Paste rules (policy) with conditions matching where the data/text being pasted is copied from.
   

  

     

   

• Generating insights for Chrome DevTools console warnings and errors 

  A new Generative AI (GenAI) feature is now available for unmanaged users, generating insights for Chrome DevTools Console warnings and errors.

  These insights provide a personalized description and suggested fixes for the selected errors and warnings. Initially, this feature is only available to users (18+) in English. Admins can control this feature by using the DevToolsGenAiSettings policy.

  • Chrome 125 on ChromeOS, Linux, macOS, Windows
    Feature becomes available to unmanaged users globally, except Europe, Russia, and China.
  • Chrome 127 on ChromeOS, Linux, macOS, Windows
    Feature becomes available to managed Chrome Enterprise & Education users in supported regions.
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
    In Chrome 131, a new Generative AI (GenAI) feature becomes available for managed users: a dedicated “AI assistance” panel in Chrome DevTools which assists the human operator investigating & fixing styling challenges and helps debugging the CSS.
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
    The AI assistance panel can now explain resources in the Performance panel, Sources panel, and Network panel, in addition to the previous support for style debugging.
     

   

• Professional Chrome Enterprise Administrator certification 

  For organizations using Chrome Enterprise Core, we offer a new certification opportunity – the Professional Chrome Enterprise Administrator certification. This certification is designed to validate your expertise in managing Chrome Enterprise browser environments, with a focus on using Chrome Enterprise Core to implement policies, establish controls, and analyze reports.

  Designed for Chrome Enterprise Administrators with at least one year of experience with application, policy, and endpoint management, the exam is a two-hour exam consisting of about 70 multiple choice questions. The exam assesses your familiarity with both local and cloud-based solutions to manage, maintain, troubleshoot, secure, and integrate with services related to Chrome.

  Google is waiving the exam fee of $125 until March 2025 and admins can now take the Professional Chrome Enterprise Administrator certification exam for free.

   
  • Chrome 132 on Android, iOS, ChromeOS
     

   

• Server Root Certificates for Chrome Enterprise 

  Chrome 132 adds the capability for enterprise customers or partners to deploy custom Server Root Certificates or Trust Anchors into Chrome’s Root Store on fully managed browsers via Chrome Browser Cloud Management or into managed Chrome profiles on managed or unmanaged devices.

   
  • Chrome 132 on Linux, macOS, Windows
     

   

• Legacy Technology Report 

  The Legacy Tech Report allows IT administrators to have visibility on websites (both internal and external) that are using deprecated or soon-to-be deprecated technologies (for example, CSS property changes or older security protocols like TLS 1.0 & 1.1). This launch is available in the Google Admin console to all Chrome Enterprise Core. For more details, see View legacy technology usage details.

  This gives an opportunity to IT administrators to have the ability to work with developers to proactively plan technical migrations before a deprecation goes into effect.

   
  • Chrome 132 on Linux, macOS, Windows
   

  

     

   

• Recommended policies (users can override a policy value) 

  Chrome is introducing the User override configuration in the Google Admin console for policies that can be set as recommended. This means that IT administrators can apply a policy value and allow users to override the policy value. 

   

  On Chrome 132: the following policies are supported: ShowHomeButton, HomepageIsNewTabPage, HomepageLocation, DownloadRestrictions, SafeBrowsingProtectionLevel, AlwaysOpenPdfExternally, BackgroundModeEnabled, MetricsReportingEnabled, WarnBeforeQuitting, PrintPreviewUseSystemDefaultPrinter, BatterySaverModeAvailability

   

  As early as Chrome 133: the following policies will be supported: ImportAutofillFormData, ImportBookmarks, ImportHistory, ImportSavedPasswords, ImportSearchEngine

   

  

  
  
     

   

• Updated managed browser list: Most recent Google Update activity 

  Chrome Enterprise Core is adding the Most recent Google Update activity column on the managed browser list. The Most recent Google Update activity represents the last recorded time when the GoogleUpdater service interacted with a managed browser.

   
  • Chrome 132 on Linux, macOS, Windows
     
   

Chrome Enterprise Premium changes

   

   

• File download encryption for DLP Rules 

  When a file downloaded Data Loss Prevention (DLP) rule is triggered, the file is now encrypted on the fly to ensure that end users cannot access that file when a verdict is being returned. This means that users can no longer bypass the rule by moving or renaming the file. 

  This feature is gated by the existing policy OnFileDownloadedEnterpriseConnector and is only available to Chrome Enterprise Premium users.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows

Upcoming Chrome browser changes

 

    

• Disallow spaces in non-file:// URL hosts 

  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 (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 133 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
     

    

• Read aloud in Reading mode in Chrome 133 

  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 which will allow users to hear the text they are reading spoken out loud. Users will be able to choose different natural voices and speeds, and see visual highlights.

   
  • Chrome 133 on Linux, macOS, Windows
     

    

• Tab freezing on Energy saver 

  When Energy saver is active, Chrome will freeze 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 in Chrome 131 via 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.

   
  • Energy saver availability can be controlled via the BatterySaverModeAvailability policy (this change has no effect when Energy saver is inactive).
  • Chrome 133 on ChromeOS, Linux, macOS, Windows
    The feature will start rolling out to 1% of stable in Chrome 133.
   

    

• Deprecate getters of Intl Locale Info 

  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 133 on Windows, macOS, Linux, Android
     

    

• Popover invoker and anchor positioning improvements 

  This update represents the following related set of changes, which were resolved  and landed 

  1. add an imperative way to set invoker relationships between popovers: 

      popover.showPopover({source})

  2. invoker relationships create implicit anchor element references.

   
  • Chrome 133 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
   

    

• Remove Chrome Welcome page triggering via initial prefs first run tabs 

  Including chrome://welcome in the first_run_tabs property of the initial_preferences file will now have no effect. This is removed because that page is redundant with the First Run Experience that triggers on desktop platforms.

  For more details about the context of the initial_preferences file, see Configuring Other Preferences.

   
  • Chrome 133 on Windows, macOS, Linux
   

    

• 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 133 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:

  1. SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process.
  2. 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.
   

  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.

   
  • Chrome 133 on Windows, macOS, Linux, Android
   

    

• Privacy & security panel in Chrome DevTools 

  Starting in Chrome 133, developers will be able to use the new Privacy & 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 133 on ChromeOS, Linux, macOS, Windows
   

    

• Chrome Sync to end support for Chrome versions more than four years old 

  Starting in February 2025, Chrome Sync (using and saving data in your Google Account) will no longer support Chrome versions that are more than four years old. You need to upgrade to a more recent version of Chrome if you want to continue using Chrome Sync.

   
  • 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.

   

    

• V8 Security Setting 

  Add a setting on chrome://settings/security to disable the V8 JIT optimizers, in order to reduce the attack surface of Chrome. This maintains compatibility with Web Assembly. This behavior continues to be controlled by 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.
   

    

• New option in HttpsOnlyMode policy 

  Ask Before HTTP (ABH, formerly HTTPS Only/First Modes) is a setting that tells Chrome to ask for user consent before sending insecure HTTP content over the wire. The HttpsOnlyMod policy allows force-enabling, or force-disabling, ABH.

  In Chrome 129, we are adding 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
   

    

• 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 134 on Android, iOS, ChromeOS, Linux, macOS, Windows: This will be a gradual rollout.
   

    

• Blob URL Partitioning: Fetching or 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 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 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 we will pursue spec updates to reflect both of these changes. 

  This change can be temporarily reverted by setting the PartitionedBlobURLUsage policy, which will be available in Chrome 134. The policy will be deprecated when the other storage partitioning related enterprise policies are deprecated.

   
  • Chrome 134 on Windows, macOS, Linux
   

    

• SharedWorker script inherit controller for blob script URL 

  Service Workers should inherit controllers for the blob URL. However, existing code allows only dedicated workers to inherit the controller, and shared workers do not inherit the controller.

  This is the fix to make Chromium behavior adjust to the specification.

  An enterprise policy SharedWorkerBlobURLFixEnabled is available to control this feature.

   
  • Chrome 134 on Windows, macOS, Linux
   

    

• Deprecate mutation events 

  Synchronous mutation events, including DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, and DOMCharacterDataModified, 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. Starting in Chrome 124, a temporary enterprise policy, MutationEventsEnabled, will be available to re-enable deprecated or removed mutation events. If you encounter any issues, file a bug here.

  Mutation event support will be disabled by default starting in Chrome 127, around July 30, 2024. Code should be 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 through Chrome 134, ending March 25, 2025.
  • A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 134.

  To read more, see this blog post. Report any issues here.

  • Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.
   

    

• 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.
   

    

• Customizing managed profiles with custom logo and label 

  New toolbar and profile menu customizations that help users easily identify if their Chrome profile is managed, whether they're on a work or personal device. This is especially useful for scenarios where employees use their own devices with managed accounts.

  To help tailor this experience, we're adding three new policies:

  • EnterpriseCustomLabel: Customize the text displayed on the toolbar element to match your organization's branding.
  • EnterpriseLogoUrl: Add your company logo to the profile menu.
  • EnterpriseProfileBadgeToolbarSettings: This policy can disable the default label for a managed profile in the Chrome toolbar. 

  In Chrome Chrome 133, these policies will be available to customize the logo and label shown on a managed profile. 

  Starting Chrome 134, there will be updates to the default behavior of the profile label and icon overlaid on the account avatar. Managed profiles will show a work or school label in addition to the profile disk. In the profile menu, there will be a building icon overlaid on the account avatar. The expanded profile disk can be disabled via EnterpriseProfileBadgeToolbarSettings.

   
  • Chrome 133 on macOS, Windows

    Policies to customize the toolbar label and icon (in profile menu) 

  • Chrome 134: Starting rollout of defaults including: 
    • 1) work or school label shown in toolbar, next to user avatar 
    • 2) A building icon overlayed on the user's account photo in the profile menu. The label can be turned off via EnterpriseProfileBadgeToolbarSettings. Starting with 1% and gradual slow rollout thereafter.

 

Upcoming Chrome Enterprise Core changes

    

• New Chrome Enterprise Companion App 

  Chrome Enterprise Companion App (CECA) 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 133 on Windows, macOS

 

Upcoming Chrome Enterprise Premium changes

 

   

• 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
   

   

• 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
   

   

• 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

ChromeOS 132 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Customized Chrome Web Store for enterprises		✓
Native Client (NaCl) support ending on ChromeOS		✓
Onboarding refresh		✓
Migrate data for graduating students		✓	✓
Rounded corners for Apps		✓
ChromeOS Passwordless Authentication	✓
Face control on ChromeOS	✓	✓
Turn off the touchpad		✓
Password Manager biometric authentication	✓
Apps discovery removed from Explore		✓
Remote management for idle devices			✓
ChromeOS device Bedtime Hours policy			✓
Improved management disclosure on locked device	✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
AI wallpapers and backgrounds		✓
Deprecating Chrome Apps support on ChromeOS		✓	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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.

ChromeOS updates

   

• Customized Chrome Web Store for enterprises 

  Admins can now use new settings to customize the Chrome Web Store for their managed users, which includes the ability to:

  • Add company logos
  • Add hero banners and custom announcements
  • Curate extension collections
  • Implement category-based controls

  These settings are configurable using the Admin console and are available to all signed-in managed users (users signed-in to the Chrome Web Store with a managed Google Account). For more details, see Customized Chrome Web Store for enterprises.

  Additionally, all managed users who sign in to the Chrome Web Store will see the following changes:

  • New tags for items Blocked by their admin when searching for an item
  • Private domain item search and advanced filtering capabilities
  • Private items and recommended items are relocated to the Extensions tab 

  Enrolled browsers (without the need to sign in) will be supported later in 2025.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
   

  

  
   

   

• Native Client (NaCl) support ending on ChromeOS 

  ChromeOS 132 is the last release with NaCl support for unmanaged or consumer devices, followed by ChromeOS 138 in July 2025 for managed devices. For more details, see About ChromeOS device management.

  In 2017, we announced the end of support of Native Client (NaCl) in favor of WebAssembly. With most developers and users having migrated away from NaCl, we confirm the following NaCl discontinuation dates: 

  • January 2025: Native Client (NaCl) will be disabled from ChromeOS 132 onwards.
    • For unmanaged and consumer users, ChromeOS 132 will be the last ChromeOS release with support for NaCl.
    • For managed environments (including Kiosk sessions), administrators who manage ChromeOS devices for a business or school will have the option of extending the ability to use NaCl with a DeviceNativeClientForceAllowed NaCl allow policy through the ChromeOS 138 release. To enable device policies, please refer to Set ChromeOS device policies in the Chrome Enterprise and Education Help Center.
  • July 2025: ChromeOS 138 will be the last version with NaCl support.
    • For managed environments, ChromeOS 138 is a Long-term Support (LTS) ChromeOS release available to administrators who manage ChromeOS devices for a business or school. 
    • For devices that have been switched to the LTS channel and have the NaCl allow policy enabled, NaCl will be available until LTS Last Refresh in April 2026.
    • No exceptions will be granted.
   

  For Chrome Apps that use NaCl, migrate to WebAssembly (WASM). To help you with the transition, we've published the WebAssembly Migration Guide.

  For more information about this change or if you need assistance, you can refer to any of the following:

  • WebAssembly Migration Guide.
  • ChromeOS developer community on Discord.
  • ChromeOS release schedule for release dates and updates.
   

  To find out more, see Manage policies for ChromeOS devices in the Chrome Enterprise and Education Help Center.

     

   

• Onboarding refresh 

  There are many different setup items that users might look to change once they've started using their devices, including setting up a printer, connecting Bluetooth devices, changing touchpad direction, and so on. This feature consolidates many of these common setup items into a simple task list, with deep linking to where a user can change a particular setting, to simplify the process of completing many of these steps.

   

  

     

   

• Migrate data for graduating students 

  As early as ChromeOS 132, a new Content transfer tool will guide graduating students or other EDU-managed users who want to migrate their data through the updated Google Takeout Transfer process. This allows them to take their Docs, Sheets, Slides, and Gmail content to a Gmail account of their choice. 

  This new application allows school administrators to pin an icon to the shelf, notify students and faculty on their Chromebooks, and set dates to trigger these nudges to encourage them to use Content transfer.

   

• Rounded corners for Apps 

  As part of a new UI design, ChromeOS now features rounded corners on all app windows on Chromebook Plus devices.

   

• ChromeOS passwordless authentication 

  The passwordless ChromeOS feature allows users to access their device with PIN or a local password as their primary authentication factor. This means that you will be able to log in to your ChromeOS device with a password you set explicitly for your device, as well as with a PIN no longer tying your gmail password with your device password. 

  It is not possible to enable the PIN feature on managed devices. 

   

• Face control on ChromeOS 

  ChromeOS now features AI-powered face control; you can now use face and gesture tracking to navigate your Chromebook, open apps, and even compose emails – all without a keyboard or mouse. This built-in technology, inspired by Project Gameface, provides greater accessibility for users with motor disabilities and offers a more efficient way for everyone to interact with their devices. To read more about this feature, see this Google blog post.

   

• Turn off the touchpad 

  Chromebook users can now disable their touchpads. This accessibility improvement helps those who rely on screen readers or may experience accidental clicks. To turn it off, go to Settings > Accessibility > Cursor and Touchpad.

   

• Password Manager biometric authentication 

  ChromeOS 132 enables biometrics in Password Manager and autofill on Chrome for ChromeOS devices.

   

  

  
   

   

• Apps discovery removed from Explore 

  ChromeOS 132 removes the Apps & Games module in the Explore app. To discover new apps for your ChromeOS device, navigate to https://discover.apps.chrome.

  .

     

   

• Remote management for idle devices 

  Chrome Remote Desktop (CRD) is a feature that allows for remote control of ChromeOS devices, primarily for troubleshooting purposes, where a device is idle and unused. Admins can now initiate a CRD connection to a ChromeOS device sitting on the login screen. This enables an admin to sign-in to a managed device with their own set of credentials for troubleshooting or testing. 

   

  

     

   

• ChromeOS device Bedtime Hours policy   

  The new DeviceRestrictionSchedule policy allows ChromeOS administrators to disallow users from logging in to specified Chromebooks during certain hours on specified days of the week. During these hours, kiosk apps are also unavailable. 

  

  
   

   

• Improved management disclosure on locked device 

  This feature improves the management disclosure on the device's lock screen. To enhance user understanding before using their device for personal tasks or work, we provide a clear explanation of what managed devices entail. This way, users can make informed decisions regarding their device usage. By providing necessary information, users gain the knowledge needed to make choices that align with their privacy and security concerns and preferences.

Upcoming ChromeOS changes

   

• AI wallpapers and backgrounds  

  As early as ChromeOS 134, we plan to introduce high-resolution, generative AI wallpapers and video call backgrounds on ChromeOS. With this feature, you can unleash your creativity and turn your Chromebook into a canvas of personal expression. Choose from a diverse collection of templates and, in just a few clicks, infuse your Chromebook with your unique personality, mood, or interest. 

  Two new policies will be available to control these features; GenAIVcBackgroundSettings and GenAIWallpaperSettings. This feature will be available on Chromebook Plus devices only.

   

• Deprecating Chrome Apps support on ChromeOS  

  In 2016, we announced the deprecation of Chrome Apps in favor of web apps, and in 2021, we announced on the Chromium Blog that support for Chrome Apps for ChromeOS Enterprise and Education customers and developers on ChromeOS would be extended until at least January 2025. With the majority of our customers having migrated off of Chrome Apps (including Legacy (v1) packaged apps and Hosted apps), we can confirm the following updates about Chrome Apps discontinuation dates.

   

  • July 2025: End of support for user-installed Chrome Apps (scheduled for ChromeOS M138).
    • Chrome Apps that are force-installed through the admin console will continue to be supported.
  • July 2026: Last ChromeOS release with support for Chrome Apps in Kiosk Mode (scheduled for ChromeOS M150).
    • Devices on the LTS channel with Chrome Apps in Kiosk Mode will receive support until April 2027.
  • February 2028: Last ChromeOS release with support for Chrome Apps (scheduled for ChromeOS M168), marking the end of life for all Chrome Apps.
    • Devices on the LTS channel can continue to use Chrome Apps until October 2028.
    • No exceptions will be granted.

  These deprecation timelines also apply to self-hosted Chrome Apps.

  While no new Chrome Apps can be added to the Chrome Web Store, existing Chrome Apps can continue to be updated through October 2028 when they will reach end of life on ChromeOS. After this date, Chrome Apps will be removed from the Chrome Web Store.

  If your organization has developed in-house Chrome Apps and you need assistance, please refer to Transition from Chrome Apps guide. You can also join us in the ChromeOS developer community on Discord, or reach out to us through the form at https://chromeos.dev/work-with-us. Refer to the ChromeOS release schedule for release dates and updates.

  In the coming weeks, additional detailed information will be sent to all remaining Chrome App developers and all ChromeOS Administrators.

Chrome 131 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Search with Google Lens on iOS		✓
Asynchronous real-time Safe Browsing check	✓
Ad-hoc code signatures for PWA shims on macOS		✓
Choose from Google Drive on iOS		✓
Chrome PDF Viewer OCR		✓
Chrome on iOS promo on Desktop NTP		✓
Cross profile password-reuse detection	✓
Chrome on Android now supports 3P autofill and password providers	✓	✓
Deprecate Safe Browsing Extended reporting	✓
Entrust certificate distrust	✓
Insecure form warnings on iOS	✓
PartitionAlloc with Advanced Checks (PA/AC)	✓
Simplified sign-in and sync experience	✓
Tab freezing on Energy saver		✓
Update Google Play Services to fix issues with on-device passwords		✓
X25519Kyber768 key encapsulation for TLS	✓
Deprecation of CSS Anchor Positioning property inset-area	✓
Improvements to styling structure of <details> and <summary> elements		✓
Keyboard Lock and Pointer Lock permissions	✓
Remove non-standard GPUAdapter requestAdapterInfo() method	✓
<select> parser relaxation	✓
Support external SVG resources for clip-path, fill, stroke, and marker-* properties	✓
Support non-special scheme URLs	✓
Translate for Search with Google Lens		✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
GenAI Defaults policy			✓
Chrome extension telemetry integration with SecOps	✓
Customized Chrome Web Store for Enterprises			✓
DownloadRestrictions policy support on Android	✓		✓
Enterprise Policy to force adaptive buffering for WebAudio Rendering			✓
Generating insights for Chrome DevTools Console warnings and errors			✓
Recommended policies in the Admin console			✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Chrome Enterprise Data Controls: Clipboard	✓
Screenshot protections	✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Read aloud in Reading mode in Chrome 132		✓
Removal of old Headless from the Chrome binary		✓
Capture all screens	✓
Remove prefixed HTMLVideoElement fullscreen APIs		✓
Remove ThirdPartyBlockingEnabled policy			✓
Keyboard-focusable scroll containers		✓
Throw exception for popovers or dialogs in non-active documents		✓
User Link capturing on PWAs		✓	✓
Network Service on Windows will be sandboxed	✓
Remove SwiftShader fallback	✓
Privacy & security panel in Chrome DevTools	✓
Chrome Sync to end support for Chrome versions more than four years old		✓
Disallow spaces in non-file:// URL hosts	✓
SafeBrowsing API v4 to v5 migration	✓
Blob URL partitioning: Fetching or Navigation	✓
Deprecate mutation events		✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Remove enterprise policy used for legacy same site behavior			✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
DLP file download access prevention	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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

 

   

• Search with Google Lens on iOS  

  Since Chrome 126, users can search any images or text they see on their screen with Google Lens. To use this feature, go to a website and click Search with Google Lens on the on-focus omnibox chip and on the right-click menus on desktop, or on the 3-dot menu on both desktop and mobile. Users can click, highlight, or drag anywhere on the screen to search its contents, and refine their search by adding keywords or questions to the search box. Admins can control the feature through a policy called LensOverlaySettings. To perform the search, a screenshot of the screen is sent to Google servers but it is not linked to any IDs or accounts, it is not viewed by any human, and data about its contents is not logged. We are starting the rollout of this feature gradually on iOS in Chrome 131 and we plan to launch fully in Chrome 132.

  • Chrome 126 on ChromeOS, Linux, macOS, Windows: Rollout of the feature at 1% Stable
  • Chrome 127 on ChromeOS, Linux, macOS, Windows: Rollout to 100% Stable
  • Chrome 131 on iOS: Rollout of the feature starts
  • Chrome 132 on iOS: Rollout to 100% Stable
   

   

• Asynchronous real-time Safe Browsing check on iOS  

  Today Safe Browsing checks are on the blocking path of page loads, meaning that the user cannot see the page until the checks are completed. To improve Chrome's loading speed, real-time Safe Browsing checks will no longer block page loads after Chrome 122, and after Chrome 131 on iOS. 

  We have evaluated the risk and put mitigations in place:

  1. For malware and 0-day attacks, local-blocklist checks will still be conducted in synchronous manner so that malicious payloads are still blocked by Safe Browsing. 
  2. For phishing attacks, we've looked at data and it is unlikely the user would have interacted with the page (for example, typed a password) by the time we show the warning.
   
  • Chrome 122 on Android, ChromeOS, Linux, macOS, Windows
  • Chrome 131 on iOS
   

   

• 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 app shim having a unique identity to macOS; currently every PWA looks like the same application to macOS.

  This addresses problems when attempting to include multiple PWAs in the macOS Open at Login preference pane, and permits future improvements to handling of user notifications within PWAs on macOS.

  Administrators should test for compatibility with any endpoint security or binary authorization tools they use (such as Santa). The feature can be switched on for testing using the chrome://flags/#use-adhoc-signing-for-web-app-shims flag. Admins can then install a PWA 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
    This feature is turned on with 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 control the feature using 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 131 on macOS: Feature begins to roll out to stable, starting at 1% rollout.
   

   

• Choose from Google Drive  

  From Chrome 131 onwards, Chrome on iOS users can upload a file from Google Drive directly to a web page, without the need to download it on the device first.

   
  • Chrome 131 on iOS: Includes core functionality for uploading a single file. 
   

   

• Chrome PDF Viewer OCR  

  Chrome Desktop now makes scanned PDFs more accessible. Using on-device Optical Character Recognition (OCR) to maintain privacy (no content is sent to Google), Chrome automatically converts scanned PDFs, allowing you to select text, Ctrl+F, copy, and paste. The feature does not bypass secure PDFs. It only uses OCR on PDFs the user has access to. The solution unlocks PDF accessibility to Chrome users without any extra steps, making PDFs as accessible as the rest of the web.

   
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
   

   

• Chrome on iOS promo on Desktop NTP  

  A Chrome on iOS promo on the Desktop new tab page. This promo aims to increase awareness of Chrome on iOS and present a simple way to install. 

  You can control this feature using the existing policies PromotionsEnabled and NTPMiddleSlotAnnouncementVisible.

   
  • Chrome 131 on Linux, macOS, Windows
   

   

• Cross profile password-reuse detection  

  Previously, password-reuse detection of corporate credentials was only detectable in the corporate profile. Now, password-reuse detection detects corporate credential reuse across all non-Incognito profiles on the managed browser. 

  We've updated the cross profile password-reuse detection criteria to more accurately reflect managed enterprise accounts. We’ve also updated the on-screen message to make it clearer to users that their organization is monitoring their corporate password reuse.

  • Chrome 123 on Android, iOS, ChromeOS, Linux, macOS, Windows, Fuchsia
  • Chrome 131 on Android, iOS, ChromeOS, Linux, macOS, Windows, Fuchsia
    We've updated the cross profile password-reuse detection criteria to more accurately reflect managed enterprise accounts, and updated the UX message to make it clearer to users that their organization is monitoring their corporate password reuse.

 

   

• Chrome on Android now supports 3P autofill and password providers 

  Until now, third-party autofill and password providers could be used in Chrome on Android via accessibility APIs.

  In Chrome M131, we're adding direct support for Android Autofill, which means these providers will work with Chrome on Android without the need for accessibility APIs. This should improve the performance of Chrome on Android and third-party autofill providers.

  To take advantage of this, users will need to configure their third-party provider in Android settings. Then, in Chrome, users select Settings > Autofill services and choose Autofill using another service.

  If users do not change both settings, they will continue to use Google to autofill their passwords, payment and address information. Whether users can use a third-party autofill service or not can be controlled by a new policy called ThirdPartyPasswordManagersAllowed.

  • Chrome 131 on Android 

    The new setting will be available from Chrome 131. If users use the new setting, it will take immediate effect. If the new setting is not used, users will continue to use either Google or a third party via accessibility (if installed).  

    The support for accessibility APIs will be deprecated in early 2025, at which point the new policy settings will apply to all users.

     
   

   

• Deprecate Safe Browsing Extended reporting  

  We are deprecating the Safe Browsing Extended reporting feature, which previously  enhanced the security of all users by collecting telemetry information from participating users that is used for Google Safe Browsing protections. The data collected includes URLs of visited web pages, limited system information, and some page content. 

  This feature is now superseded by Enhanced protection mode. We suggest users switch to Enhanced protection to continue providing security for all users in addition to enabling the strongest security available in Chrome. For more information, see Safe Browsing protection levels. 

   
  • Chrome 129 on Android, iOS, ChromeOS, Linux, macOS, Windows
    Deprecation of Safe Browsing Extended Reporting. Excluding real-time Client Safe Browsing Report Request
  • Chrome 131 on Android, iOS, ChromeOS, Linux, macOS, Windows
    Deprecating SafeBrowsingExtendedReportingEnabled for real-time Client Safe Browsing Report Request
   

  

   

   

• Entrust certificate distrust  

  In response to sustained compliance failures, Chrome is changing how publicly-trusted TLS server authentication (website) certificates issued by Entrust will be trusted by default in Chrome 131 and greater on Windows, macOS, ChromeOS, Android, and Linux. iOS policies do not allow use of the Chrome Root Store in Chrome for iOS.

  Specifically, TLS certificates validating to the Entrust root CA certificates included in the Chrome Root Store and issued:

  • after November 11, 2024, will no longer be trusted by default.
  • on or before November 11, 2024, will be unaffected by this change. 
   

  Should a Chrome user or enterprise explicitly trust any of the affected Entrust certificates on a platform and version of Chrome relying on the Chrome Root Store, for example, explicit trust is conveyed through a Windows Group Policy Object, the SCT-based constraints described above will be overridden and certificates will function as they do today.  

  Additional information and testing resources are the Google Security blog. 

  To learn more, see this FAQ about the Chrome Root Store.

   
  • Chrome 131 on Android, ChromeOS, Linux, macOS, Windows
    All versions of Chrome 131 and higher that rely on the Chrome Root Store will honor the blocking action, but the blocking action will only begin for certificates issued after November 11, 2024.
   

   

• Insecure form warnings on iOS  

  Since Chrome 125, Chrome browser blocks form submissions from secure pages to insecure pages on iOS. When Chrome detects an insecure form submission, it displays a warning asking the user to confirm the submission. The goal is to prevent leaking form data over plain text without the user's explicit approval. A policy InsecureFormsWarningsEnabled is available to control this feature. 

   
  • Chrome 125 on iOS: Feature rolls out
  • Chrome 131 on iOS: InsecureFormsWarningsEnabled policy will be removed
   

   

• PartitionAlloc with Advanced Checks (PA/AC)  

  PartitionAlloc (PA) and its associated memory security projects have an array of advanced safeguards that are deactivated by default (or exclusively in debug builds) due to their potential impact on performance. While enabling the feature for all users might not be immediately possible, there is still an opportunity to partially enable it under specific, limited conditions.

  This project seeks to achieve advanced safeguards for the enterprise customers. Enterprise administrators have the option to apply enhanced security measures through Enterprise Policies. Security tends to be prioritized over performance in Enterprise. There's a likelihood that they desire advanced checks, even if it comes at a cost to performance.

  PA with Advanced Checks is advanced memory security. The feature is OFF by default due to expected performance regression. Enterprise customers have an option to enable it to achieve advanced security via enterprise policy.

   
  • Chrome 131 on Android, iOS, ChromeOS, Linux, macOS, Windows, Fuchsia

   

• Simplified sign-in and sync experience  

  Starting in Chrome 131, existing users with Chrome sync turned on now experience a simplified and consolidated version of sign-in and sync in Chrome. Chrome sync is no longer shown as a separate feature in settings or elsewhere. Instead, users can sign in to Chrome to use and save information like passwords, bookmarks and more in their Google Account, subject to the relevant enterprise policies.

  As before, the functionality previously part of Chrome sync that saves and accesses Chrome data in the Google Account can be controlled by SyncTypesListDisabled. Sign-in to Chrome can be switched off via BrowserSignin as before.

  Note that the changes do not affect users’ ability to sign in to Google services on the web (like Gmail) without signing in to Chrome, their ability to stay signed out of Chrome, or their ability to control what information is synced with their Google Account.

   
  • Chrome 131 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, or 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 extends battery life and speeds up Chrome through reduced CPU usage.

  • Chrome 130 on ChromeOS, Linux, macOS, Windows
    The feature can be tested in Chrome 130 using the #freezing-on-energy-saver entry in about:flags. Alternatively, it can be tested with the #freezing-on-energy-saver-testing flag, which simulates that Energy saver is active and that all tabs use a lot of CPU; this allows verifying whether a tab is eligible for freezing and would be frozen if it used a lot of CPU. Energy saver availability can be controlled using the BatterySaverModeAvailability policy. This change has no effect when Energy save is inactive.
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
    The feature will start rolling out to 1% of stable in Chrome 131. It will gradually be ramped up to 100% of Stable. Energy saver availability can be controlled via the BatterySaverModeAvailability policy. This change has no effect when Energy saver is inactive.
   

   

• Update Google Play Services to fix issues with on-device passwords  

  Users with old versions of Google Play Services will experience reduced functionality with their on-device passwords, and Password Manager might soon stop working for them altogether. These users will need to update Google Play Services, or will be guided through other troubleshooting methods depending on their state. This is part of an ongoing migration that only affects Android users of Google Password Manager.

   
  • Chrome 131 on Android
   

   

• X25519Kyber768 key encapsulation for TLS  

  Starting in Chrome 124, Chrome enables by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism X25519Kyber768, based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both TLS 1.3 and QUIC connections.

  However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary PostQuantumKeyAgreementEnabled enterprise policy, which will be available through the end of 2024. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed. Post-quantum cryptography is required for CSNA 2.0.

  For more detail, see this Chromium blog post and this Google Security blog post.

   
  • Chrome 124 on Windows, macOS, Linux: new post-quantum secure TLS key encapsulation mechanism X25519Kyber768 is enabled
  • Chrome 131 on Linux, macOS, Windows: Chrome will switch the key encapsulation mechanism to the final standard version of ML-KEM
  • Chrome 141 on Windows, macOS, Linux: Remove enterprise policy
   

   

• Deprecation of CSS Anchor Positioning property inset-area  

  The CSS working group (CSSWG) resolved to rename the inset-area property to position-area. For more details, see the CSSWG discussion on github. The new property name, position-area, as a synonym for inset-area shipped via this feature update described on Chrome Platform Status, describing the deprecation and removal of the inset-area property.

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

   

• Improvements to styling structure of <details> and <summary> elements  

  Support more CSS styling for the structure of <details> and <summary> elements to allow these elements to be used in more cases where disclosure widgets or accordion widgets are built on the web. In particular, this change removes restrictions that prevented setting the display property on these elements, and adds a ::details-content pseudo-element to style the container for the part that expands and collapses.

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

   

• Keyboard Lock and Pointer Lock permissions  

  May show a permission prompt to the user when Keyboard Lock or Pointer Lock is requested by a website, and saves the user preferences as content settings. The settings can be queried for via the Permissions API. This helps mitigate the abusive use of the APIs.

   
  • Chrome 131 on Windows, macOS, Linux
   

   

• Remove non-standard GPUAdapter requestAdapterInfo() method  

  The WebGPU WG decided it was impractical for requestAdapterInfo() to trigger a permission prompt so they’ve removed that option and replaced it with the GPUAdapter info attribute so that web developers can get the same GPUAdapterInfo value synchronously this time. To read more, see the previous Intent to Ship: WebGPU: GPUAdapter info attribute . 

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

   

• <select> parser relaxation  

  This change makes the HTML parser allow additional tags in <select> besides <option>, <optgroup>, and <hr>.

  This change is in support of the customizable <select> feature but is being shipped first because it can be done separately and has some compact risks.

  This feature is gated by the temporary policy, SelectParserRelaxationEnabled. This is a temporary transition period, and the policy will stop working in milestone Chrome 136.

  For more details, see the Open UI Customizable <select> explainer and the What Working Group HTML parser changes for customizable <select> article. 

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

   

• Support external SVG resources for clip-path, fill, stroke and marker-* properties  

  Allow external references for clip paths, markers, and paint servers (for the fill and stroke properties). For example, clip-path: url("resources.svg#myPath").

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

   

• Support non-special scheme URLs  

  Chrome 130 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. Now, 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 131 on Windows, macOS, Linux, Android
  • Chrome 134 on Windows, macOS, Linux, Android: Feature flag being removed
   

   

• Translate for Search with Google Lens  

  Augmented reality (AR) translation capabilities are being implemented to the Search with Google Lens feature. An enterprise policy is already in place enabling enterprises to turn the feature on or off using LensOverlaySettings.

   
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
     

   

• New policies in Chrome browser  

  Policy	Description
  DownloadRestrictions	Allow download restrictions
  CAPlatformIntegrationEnabled	Use user-added TLS certificates from platform trust stores for server authentication
  SelectParserRelaxationEnabled	Controls whether the new HTML parser behavior for the <select> element is enabled
  EnterpriseProfileBadgeToolbarSettings	Controls visibility of enterprise profile badge in the toolbar
  WebAudioOutputBufferingEnabled	Enable adaptive buffering for Web Audio

   

   

• Removed policies in Chrome browser  

  Policy	Description
  ProfileLabel	This policy controls a label used to identify a signed in profile. This label will be shown in various locations to help users identify the profile such as next to the toolbar profile icon.
  ToolbarAvatarLabelSettings	Managed toolbar avatar label setting
  BeforeunloadEventCancelByPreventDefaultEnabled	Control new behavior for the cancel dialog produced by the beforeunload event.

   

   

Chrome Enterprise Core changes

    

• GenAI Defaults policy  

  Starting in 131, Chrome Enterprise Core  introduces a policy,  GenAiDefaultSettings, to control the default behavior of multiple GenAI policies as part of our Trusted Tester program. You can sign up for our Trusted Tester program here. This policy does not impact any manually-set policy values for generative AI features. This policy controls the default settings for the following policies:

  • CreateThemesSettings 
  • DevToolsGenAiSettings
  • HelpMeWriteSettings
  • HistorySearchSettings 
  • TabOrganizerSettings
  • TabCompareSettings
  • GenAIVcBackgroundSettings
  • GenAIWallpaperSettings
  • HelpMeReadSettings
   

  For more details about the default settings, see Chrome—Generative AI features and policies.

  • Only available to Trusted Testers. You can sign up for our Trusted Tester program here.

    

• Chrome extension telemetry integration with SecOps  

  We begin to collect relevant Chronicle extension telemetry data from within Chrome, for managed profiles and devices, and send it to Google SecOps. Google SecOps analyzes the data to provide instant analysis and context on risky activity; this data is further enriched to provide additional context and is searchable for a year.

  • Chrome 131 on ChromeOS, Linux, macOS, Windows
   

    

• Customized Chrome Web Store for Enterprises  

  IT admins will be able to customize the Chrome Web Store for their managed end-users using company-specific branding, custom messaging and tailored navigation. Admins can personalize the store with logos, banners, and recommended extensions, while also hiding irrelevant categories and improving extension discovery.

  This feature is configurable via the Admin console and this milestone 1 custom configurations will be available to all signed-in managed users (users signed-in to the Chrome Web Store with a managed Google Account). Milestone #2 will support this feature for CEC enrolled browsers (without the need to sign in) and will only be available later in 2025.

  Additionally, all managed users who sign in to the Chrome Web Store will see the following changes:

  • New tags for items blocked by their admin and filter by private items in the search results
  • Private items and recommended items will be relocated to the “Extensions” tab only.
• As early as Chrome 131 on Linux, macOS, Windows and ChromeOS: Milestone #1 rolls out

  

    

• DownloadRestrictions policy support on Android  

  DownloadRestrictions is a universal policy available to Chrome Enterprise Core users on Desktop. DownloadRestrictions policy is now supported on Android. This policy allows admins to block all downloads on mobile Chrome on Android. 

  • Chrome 131 on Android

    

• Enterprise policy to force adaptive buffering for WebAudio rendering  

  Chromium's WebAudio implementation includes an adaptive buffering mechanism, which was added to resolve numerous glitching issues especially on Android with the AAudio backend. While this mechanism reduced glitches significantly, it also increased audio latency. Chrome is running an experiment that will disable the adaptive buffering mechanism and run the rendering synchronously on all platforms besides Android. 

  Starting Chrome 131, an enterprise policy, WebAudioOutputBufferingEnabled, is available that will force Chrome to default to the previous behavior of using adaptive buffering for WebAudio rendering.

  • Chrome 131 on ChromeOS, Linux, macOS, Windows

    

• Generating insights for Chrome DevTools Console warnings and errors  

  A new Generative AI (GenAI) feature is now available for unmanaged users: Generating insights for Chrome DevTools Console warnings and errors.

  These insights provide a personalized description and suggested fixes for the selected errors and warnings. Initially, this feature is only available to users (18+) in English. Admins can control this feature by using the DevToolsGenAiSettings policy.

  • Chrome 125 on ChromeOS, Linux, macOS, Windows
    Feature becomes available to unmanaged users globally, except Europe, Russia, and China.
  • Chrome 127 on ChromeOS, Linux, macOS, Windows
    Feature becomes available to managed Chrome Enterprise & Education users in supported regions.
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
    In Chrome 131, a new Generative AI (GenAI) feature becomes available for managed users: a dedicated AI assistance panel in Chrome DevTools which assists the human operator investigating and fixing styling challenges and helps debugging the CSS.
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
    The AI assistance panel can now explain resources in the Performance panel, Sources panel, and Network panel, in addition to the previous support for style debugging

    

• Recommended policies in the Admin console  

  As early as November 1st, admins will be able to choose whether some settings are recommended or mandatory using the User override control. This control will gradually roll out for policies that can be recommended, starting with the following policies:

  - Warn before quitting
  - System Default Printer
  - Battery Saver Mode
  - Homepage
  - Safe Browsing protection
  - Download Restrictions

   

  

  • Chrome 131 on Android, iOS, ChromeOS, Linux, macOS, Windows
  
   

Chrome Enterprise Premium changes

   

   

• Chrome Enterprise Data Controls: Clipboard 

  Admins can set data control rules in the Google Admin console to protect end users from data leakage on Chrome browser. Data Controls are lightweight rules set in the Google Admin console that allow admins to set a Chrome policy to control sensitive user actions, such as, copying and pasting sensitive data and taking screenshots or screen sharing.

  This feature can be controlled using the DataControlsRules policy.

  This feature is available to test for the members of the Chrome Enterprise Trusted Tester program. You can sign up for our Trusted Tester program here.

  • Chrome 128 on ChromeOS, Linux, macOS, Windows: Trusted Tester program
  • Chrome 131 on ChromeOS, Linux, macOS, Windows: Feature rolls out

   

  

   

   

• Screenshot protections 

  Admins can prevent users from taking screenshots or screen sharing specific web pages considered to contain sensitive data. Admins create a DLP URL filtering rule to block users taking screenshots or screen sharing specific URLs or categories of URLs. This feature can be controlled using the same EnterpriseRealTimeUrlCheckMode policy that enables all real-time URL lookups.

  This feature is available to test for the members of the Chrome Enterprise Trusted Tester program. You can sign up for our Trusted Tester program here.

  • Chrome 129 on ChromeOS, Linux, macOS, Windows: Trusted Tester program
  • Chrome 131 on ChromeOS, Linux, macOS, Windows: Feature rolls out

Upcoming Chrome browser changes

 

    

• Read aloud in Reading mode in Chrome 132 

  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 which allows users to hear the text they are reading spoken out loud. Users can choose different natural voices and speeds, and see visual highlights.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
   

    

• Removal of old Headless from the Chrome binary 

  Running Chrome with `--headless=old` no longer launches the old Headless mode, and instead prints the following log message:

  The old Headless mode has been removed from the Chrome binary. You can use the new Headless mode  or the chrome-headless-shell, which is a standalone implementation of the old Headless mode.

   
  • Chrome 132 on Linux, macOS, Windows

     

• Capture all screens 

  This feature captures all the screens currently connected to the device using getAllScreensMedia(). Calling getDisplayMedia() multiple times requires multiple user gestures, burdens the user with choosing the next screen each time, and does not guarantee to the app that all the screens were selected. getAllScreensMedia() improves on all of these fronts.

  This feature is only exposed behind the MultiScreenCaptureAllowedForUrls enterprise policy, and users are warned before recording even starts, that recording could start at some point. The API will only work for origins that are specified in the MultiScreenCaptureAllowedForUrls allowlist. Any origin not specified there, will not have access to it.

  • Chrome 132 on Windows, macOS, Linux

    

• Remove prefixed HTMLVideoElement fullscreen APIs 

  The prefixed HTMLVideoElement-specific fullscreen APIs have been deprecated since approximately M38. They were replaced by the Element.requestFullscreen() API, which first shipped un-prefixed in M71, in 2018. As of 2024, most browsers have had support for the un-prefixed APIs for a few years now.

  This feature tracks removing the following APIs from HTMLVideoElement:

  - readonly attribute boolean webkitSupportsFullscreen;

  - readonly attribute boolean webkitDisplayingFullscreen;

  - void webkitEnterFullscreen();

  - void webkitExitFullscreen();

  // Note the different capitalization of the "S" in FullScreen.

  - void webkitEnterFullScreen(); 

  - void webkitExitFullScreen();

   

  These methods are now only aliases for the modern API. Their use has declined steadily over the years.

   
  • Chrome 132 on Windows, macOS, Linux, Android

    

• 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

    

• Keyboard-focusable scroll containers 

  We plan to improve accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more.

  By making scrollers focusable by default, users who can't (or don't want to) use a mouse will be able to focus clipped content using their tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>.

  Note: The previous rollout of this feature (started in Chrome 127)  was stopped due to web compatibility issues, which should be fixed in the current implementation shipping in 130.

  Note: The previous rollout of this feature (started in 130) was stopped due to an accessibility regression, which should be fixed in the implementation shipping in 132.

   
  • Chrome 132 on Windows, macOS, Linux, Android

    

• Throw exception for popovers or dialogs in non-active documents 

  This is a corner case change that hopefully does not impact developers. A corner case is where multiple unique conditions occur simultaneously. Previously, calling `showPopover()` or `showModal()` on a popover or dialog that resides within an inactive document would silently fail, that is, no exception would be thrown. Since the document is inactive, however, no popover or dialog would be shown. As of the https://github.com/whatwg/html/pull/10705 spec pull request (PR), these situations now throw the InvalidStateError exception.

   
  • Chrome 132 on Windows, macOS, Linux, Android

 

    

• User Link capturing on PWAs 

  Web links automatically direct users to installed web apps. To better align with users' expectations around installed web apps, Chrome makes it easier to move between the browser and installed web apps. When the user clicks a link that could be handled by an installed web app, Chrome adds a chip in the address bar to suggest switching over to the app. When the user clicks the chip, this either launches the app directly, or opens a grid of apps that can support that link. For some users, clicking a link always automatically opens the app.

   
  • Chrome 121 on Linux, macOS, Windows
    When some users click a link, it always opens in an installed PWA, while some users see the link open in a new tab with a chip in the address bar, clicking on which will launch the app. A flag is available to control this feature: chrome://flags/#enable-user-link-capturing-pwa.
   
  • Chrome 132 on Linux, macOS, Windows
    Launch to 100% of Stable with either a default on (always launch apps on link clicks) or a default off (always open in a tab, only launch if the user clicks on chip on address bar).
   

  

    

• Network Service on Windows will be sandboxed 

  To improve security and reliability, the network service, already running in its own process, will be sandboxed on Windows. As part of this, third-party code that is currently able to tamper with the network service may be prevented from doing so. This might cause interoperability issues with software that injects code into Chrome's process space, such as Data Loss Prevention software. The NetworkServiceSandboxEnabled policy allows you to disable the sandbox if incompatibilities are discovered. You can test the sandbox in your environment using these instructions.

  You can report any issues you encounter. 

   
  • Chrome 132 on Windows
    Network Service sandboxed on Windows

   

• 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:

  1. SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process.
  2. 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.
   

  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.

   
  • Chrome 133 on Windows, macOS, Linux, Android

   

• Privacy & security panel in Chrome DevTools  

  Starting in Chrome 133, developers will be able to use the new Privacy & 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 133 on ChromeOS, Linux, macOS, Windows

   

• Chrome Sync to end support for Chrome versions more than four years old 

  Starting in February 2025, Chrome Sync (using and saving data in your Google Account) will no longer support Chrome versions that are more than four years old. You need to upgrade to a more recent version of Chrome if you want to continue using Chrome Sync.

   
  • 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.

    

• Disallow spaces in non-file:// URL hosts 

  Per spec  URL hosts [1] 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' [2] and 'URL' focus areas [3].

  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 (Github)[4].

  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 133 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia

    

• 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 133 on Android, iOS, ChromeOS, Linux, macOS, Windows: This will be a gradual roll-out.

    

• Blob URL partitioning: Fetching or 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 navigations that 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 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 we will pursue spec updates to reflect both of 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

    

• Deprecate mutation events 

  Synchronous mutation events, including DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, and DOMCharacterDataModified, 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. Starting in Chrome 124, a temporary enterprise policy, MutationEventsEnabled, will be available to re-enable deprecated or removed mutation events. If you encounter any issues, file a bug here.

  Mutation event support will be disabled by default starting in Chrome 127, around July 30, 2024. Code should be 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 through Chrome 134, ending March 25, 2025.
  • A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 134.

  To read more, see this blog post. Report any issues here.

  • Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.

    

• 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.

  Administrators 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 administrators 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 administrators 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

    

• Remove enterprise policy used for legacy same site behavior 

  In Chrome 79, we introduced the LegacySameSiteCookieBehaviorEnabledForDomainList policy to revert the SameSite behavior of cookies to legacy behavior on the specified domains. The LegacySameSiteCookieBehaviorEnabledForDomainList policy’s lifetime has been extended and will be removed on the milestone listed below.

   
  • Chrome 132 on Android, ChromeOS, Linux, macOS, Windows: Remove LegacySameSiteCookieBehaviorEnabledForDomainList policy.

 

Upcoming Chrome Enterprise Premium changes

 

   

• DLP file download access prevention 

  When a file download DLP rule is set by the admin, a scan is triggered after the download is completed, this feature prevents Chrome Enterprise enrolled users from accessing the contents of a downloaded file before a deep scan verdict is returned.

  This feature is gated by the existing policy, OnFileDownloadedEnterpriseConnector, and is only available to Chrome Enterprise Premium users.

  • Chrome 132 on ChromeOS, Linux, macOS, Windows

   

ChromeOS 131 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
ChromeOS Flex auto-enrollment			✓
ChromeOS Flex forced re-enrollment			✓
Quick Answers styling refresh		✓
Split DNS for ChromeOS	✓
ChromeOS Back To Safety	✓	✓
Flash notifications		✓
Microsoft SCEP SID update reminder	✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
AI wallpapers and backgrounds		✓
Graduate data migration		✓	✓
Native Client (NaCl) support ending on ChromeOS	✓		✓
Chrome App support ending on ChromeOS		✓	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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.

ChromeOS updates

   

• ChromeOS Flex auto-enrollment 

  In ChromeOS 131, ChromeOS Flex auto-enrollment now allows you to deploy ChromeOS Flex devices at scale. Similar to ChromeOS zero-touch enrollment, automatic enrollment embeds an enrollment token created by an organization's administrator into a ChromeOS Flex image. This will determine which customer organization and organizational unit a device will enroll into during initial device setup. For more information, see Enroll ChromeOS devices and the ChromeOS Flex help center.

   

• ChromeOS Flex forced re-enrollment 

  In ChromeOS 131, enrolled ChromeOS Flex devices support manual forced re-enrollment. If the policy is set to enforce either automatic or manual re-enrollment, ChromeOS Flex devices will prompt users to manually re-enroll after a factory reset. For more information, see Force wiped ChromeOS devices to re-enroll and the Forced re-enrollment device setting. 

   

• Quick Answers styling refresh 

  Quick Answers is a GenAI-powered reading assistant for ChromeOS, giving users quick insights into web pages and PDF documents. This includes summaries, interactive outlines, and document Q&A. In ChromeOS 131, we introduce an updated styling for Quick Answers. For more information, see Quick Answers—definition. This feature can be controlled using Quick Answers policies.

   

• Split DNS for ChromeOS 

  You can now configure Secure DNS to be used on specified domains only. Admins can configure a list of domains to be included or excluded from using Secure DNS. You can configure this feature using these policies: DnsOverHttpsIncludedDomains and DnsOverHttpsExcludedDomains.

   

• ChromeOS Back To Safety 

  This feature gives users a way to get back to a good known state by disabling extensions and resetting settings that could hurt their experience. In past releases, in order to get your ChromeOS device to a known good state, you would have to powerwash. Thanks to this feature, there are now ways to non-destructively get your device to a state you feel comfortable with again! 

  When a user selects Safety reset, this action will:

  • Reset Chrome settings and Chrome shortcuts 
  • Disable extensions
  • Delete cookies and other temporary site data

  
  Bookmarks, history, and saved passwords won't be affected. For more details, see Wipe ChromeOS device data.

  

   

• Flash notifications 

  Customers who frequently miss notifications that appear in the corner of the screen can now enable a setting that will flash the screen whenever a new notification arrives. This feature is particularly beneficial for customers who are hard of hearing or who use screen magnification and are often zoomed in, making it difficult to see corner notifications. This new setting can be found under Settings > Accessibility > Audio and captions > Flash notifications.
  
  

   

• Microsoft SCEP SID update reminder 

  Only for SCEP deployments using Microsoft NPS for RADIUS. If you are not using SCEP certificates in combination with Microsoft NPS for Radius for Chromebook network connectivity, you may disregard the remainder of these instructions. We expect this to be a setup more common in enterprise rather than in education.

  Microsoft has announced a security update that will add a new required field, a Security Identifier (SID), to SCEP certificates in environments utilizing NPS for Radius for network authentication. This addition is due to a security vulnerability on Windows devices where usable certificates with private keys can be exported from one Windows device to be used on any other device. Addition of the SID means that the certificate becomes linked to a device or user in your Active Directory environment so that an unknown device/user cannot use it. This is not a security issue for Chromebooks, as they do not allow the exporting of certificates with private keys in them and they are protected by the TPM. However, any certificate lacking this new field will fail to authenticate against a NPS for Radius server after the hard enforcement deadline of February 11th, 2025.

  What do you need to do?

  As soon as possible, verify if your deployment relies on both SCEP certificates and NPS for Radius for network authentication. This can be done by going into event viewer on your Domain Controller > System, and searching for event ID #39. If you see this event ID:

  

   

  Actions to take if you see the event ID #39:

  1. Create a new object, or reuse an existing one, in your Active Directory environment for SCEP use
  2. Extract the SID for the AD object, for example, PS> (Get-ADUser username).SID.value
  3. Create a new SCEP profile with all settings duplicated from your current setup and add in the SID of the newly created, or existing, AD object from step 1.
  4. Under the Subject Alternative name section select the Custom radio button. Add a new Subject Alternative name using the + button with the type Uniform Resource Identifier from the dropdown. Under string, the value should be similar to: 

  tag:microsoft.com,2022-09-14:sid:S-1-2-3-4-5-6-8
  
  where S-1-2-3-4-5-6-8 is the SID of the AD object

  
  
  5. Deploy this new certificate to all potentially affected Chromebooks in your fleet
     1. Wait, AT LEAST ONE MONTH, to reasonably guarantee that all devices have picked up the new certificate.
  6. Re-link any and all policies from the old certificate to the new one from Step 2.
  7. Verify functionality using the new certificate.
  8. Delete the old profile.

Upcoming ChromeOS changes

   

• AI wallpapers and backgrounds  

  As early as ChromeOS 132, we plan to introduce high-resolution, generative AI wallpapers and video call backgrounds on ChromeOS. With this feature, you can unleash your creativity and turn your Chromebook into a canvas of personal expression. Choose from a diverse collection of templates and, in just a few clicks, infuse your Chromebook with your unique personality, mood, or interest. 

  Two new policies will be available to control these features; GenAIVcBackgroundSettings and GenAIWallpaperSettings. This feature will be available on Chromebook Plus devices only.

   

• Graduate data migration  

  As early as ChromeOS 132, a new Content Transfer tool will guide graduate students or other EDU-managed users who want to migrate their data through the updated Google Takeout Transfer process. This allows them to take their Docs, Sheets, Slides, and Gmail content to a Gmail account of their choice. 

  This new application allows school administrators to pin an icon to the shelf, notify students and faculty on their Chromebooks, and set dates to trigger these nudges to encourage them to use the existing Takeout Transfer process.

   

• Native Client (NaCl) support ending on ChromeOS  

  ChromeOS 132, scheduled for release in January 2025, will be the last release with NaCl support for unmanaged or consumer devices, followed by ChromeOS 138 in July 2025 for managed devices.

  In 2017, we announced the end of support of Native Client (NaCl) in favor of WebAssembly. With most developers and users having migrated away from NaCl, we confirm the following NaCl discontinuation dates: 

  • January 2025: Native Client (NaCl) will be disabled from ChromeOS 132 onwards.
    • For unmanaged and consumer users, ChromeOS 132 will be the last ChromeOS release with support for NaCl.
    • For managed environments (including Kiosk sessions), administrators who manage ChromeOS devices for a business or school, will have the option of extending the ability to use NaCl with a NaCl allow policy (DeviceNativeClientForceAllowed) through the ChromeOS 138 release. This policy will be available in the admin console from late December 2024 to early January 2025 before the release of ChromeOS 132.
  • July 2025: ChromeOS 138 will be the last version with NaCl support.
    • For managed environments, ChromeOS 138 is a Long-term Support (LTS) ChromeOS release available to administrators who manage ChromeOS devices for a business or school. 
    • For devices that have been switched to the LTS channel and have the NaCl allow policy enabled, NaCl will be available until LTS Last Refresh in April 2026.
    • No exceptions will be granted.

   

  For Chrome Apps that use NaCl, migrate to WebAssembly (WASM). To help you with the transition, we've published the WebAssembly Migration Guide.

  For more information about this change or if you need assistance, you can refer to any of the following:

  • WebAssembly Migration Guide.

  • Please refer to the Chrome Enterprise and Education Help Center to learn more about managing policies for ChromeOS devices.

  • ChromeOS developer community on Discord.
  • ChromeOS release schedule for release dates and updates.

   

• Chrome App support ending on ChromeOS  

  In 2016, we announced the deprecation of Chrome Apps in favor of web apps, and in 2021, we announced on the Chromium Blog that Chrome App support for ChromeOS Enterprise and Education customers and developers on ChromeOS would be extended until at least January 2025. With the majority of our customers having migrated off of Chrome Apps (including Legacy (v1) packaged apps and Hosted apps), we can confirm the following updates about Chrome App discontinuation dates.

  July 2025: End of support for user-installed Chrome Apps (scheduled for ChromeOS M138).
  • Chrome Apps that are force-installed through the Admin console will continue to be supported.
  July 2026: Last ChromeOS release with support for Chrome Apps in Kiosk Mode (scheduled for ChromeOS M150).
  • Devices on the LTS channel with Chrome Apps in Kiosk Mode will receive support until April 2027.
  February 2028: Last ChromeOS release with support for Chrome Apps (scheduled for ChromeOS M168), marking the end of life for all Chrome Apps.
  • Devices on the LTS channel can continue to use Chrome Apps until October 2028.
  • No exceptions will be granted.
   

  These deprecation timelines also apply to self-hosted Chrome Apps.

  While no new Chrome Apps can be added to the Chrome Web Store, existing Chrome Apps can continue to be updated through October 2028 when they will reach end of life on ChromeOS. After this date, Chrome Apps will be removed from the Chrome Web Store.

  If your organization has developed in-house Chrome Apps and you need assistance, please refer to Transition from Chrome Apps guide. You can also join us in the ChromeOS developer community on Discord, or reach out to us through the form at https://chromeos.dev/work-with-us. Refer to the ChromeOS release schedule for release dates and updates.

  In the coming weeks, additional detailed information will be sent to all remaining Chrome App developers and all ChromeOS Administrators.

Chrome 130 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Desktop toasts		✓
Platform picker for screen sharing on macOS		✓
New Account menu		✓
PDF Viewer on Android		✓
Tab freezing on Energy saver		✓
Compression dictionary transport with Shared Brotli and Shared Zstandard	✓
Keyboard-focusable scroll containers		✓
Support non-special scheme URLs	✓
Chrome on Android now supports third-party autofill and password providers		✓	✓
<meter> element fallback styles	✓
New and updated policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Default change for GenAI policies			✓
Support for user-level settings on Custom configurations			✓
Audit-only URL navigation rules			✓
Chrome Security Insights	✓		✓
Extension risk score Phase 2	✓		✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
No updates in Chrome 130.
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Search and receive answers in your Chrome history with AI		✓
Ad-hoc code signatures for PWA shims on macOS		✓
Asynchronous real-time Safe Browsing check	✓
Remove non-standard GPUAdapter requestAdapterInfo() method	✓
Deprecate Safe Browsing Extended reporting	✓
Update Google Play Services to fix issues with on-device passwords			✓
Entrust certificate distrust	✓
Simplified sign-in and sync experience		✓	✓
User Link capturing on PWAs		✓	✓
Deprecation of CSS Anchor Positioning property inset-area	✓
X25519Kyber768 key encapsulation for TLS	✓
Chrome PDF Viewer OCR		✓
Insecure form warnings on iOS	✓
Network Service on Windows will be sandboxed			✓
Read aloud in Reading mode		✓
Capture all screens			✓
SafeBrowsing API v4 to v5 migration	✓
Private network access checks for navigation requests: warning-only mode			✓
Deprecate mutation events	✓		✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
GenAI Defaults policy			✓
Chrome extension telemetry integration with Google SecOps	✓		✓
New managed profile list and reporting for signed-in users
Remove enterprise policy used for legacy same site behavior			✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Chrome Enterprise Data Controls: Clipboard	✓
Screenshot protections	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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

   

• Desktop toasts 

  Chrome 130 introduces a new Toast pattern that will allow features to provide visual confirmation of user actions or a quick way to take a follow up action. For example, when adding something to a reading list, a Toast confirms that the item was added and offers a quick link to the reading list side panel. Toasts appear as a small chip that partially overlaps with the web contents and partially with the top toolbar of the browser.

   
  • Chrome 130 on ChromeOS, Linux, macOS, Windows: This will be enabled for an initial set of features in Chrome 130. Subsequent toasts will be rolled out independently by other teams utilizing the pattern.
   

  

   

   

• Platform picker for screen sharing on macOS 

  When screen sharing in Chrome on macOS X Sequoia, users can now select a window or screen to share using the updated platform picker. This new platform picker removes the need for assigning screen recording permission to Chrome and is consistent with screen sharing in other macOS applications.

  The new picker will not be activated before the first update of macOS Sequoia, version 15.1 expected a month after the initial version of 15.0. Before that Chrome users might see a warning dialog that Chrome is not using the new picker API yet.

   

  To test the new screen share picker experience:

  1. Update Chrome to version 129 or later.
  2. On your macOS, open the Terminal.
  3. At the prompt, type: open -b com.google.Chrome --args -enable-features=UseSCContentSharingPicker
  4. To execute the command, on your keyboard, press Enter.
   

  The feature can also be enabled in chrome://flags.

   
  • Chrome 130 on macOS
   

  

   

   

• New Account menu 

  Some users can now access a new Account menu by tapping on their avatar on the New tab page. The new Account menu allows them to sign out, switch accounts easily and resolve errors related to their account in Chrome. Existing policies like BrowserSignin and RestrictAccountsToPatterns can be used to determine which accounts a user can sign in or switch to.

   
  • Chrome 130 on iOS

  

   

   

• PDF Viewer on Android 

  This feature provides the ability to view PDFs within Chrome browser UI. Prior to this change, users have to complete many steps to view a PDF document. These steps force them out of Chrome to view the PDF document. With this feature, PDFs will render seamlessly in Chrome. Users will still be able to download PDFs and open with other first- or third-party apps of choice. 

   
  • Chrome 130 on Android 

   

• Tab freezing on Energy saver 

  When Energy saver is active, Chrome now 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, or tab capture, or an RTCPeerConnection with an open RTCDataChannel or a live MediaStreamTrack).
  • the tab controls an external device (detected using Web USB, Web Bluetooth, Web HID or Web Serial).
   

  This will extend battery life and speed up Chrome through reduced CPU usage.

   
  • Chrome 130 on ChromeOS, Linux, macOS, Windows: The feature can be tested in Chrome 130 via the #freezing-on-energy-saver entry in about:flags. Alternatively, it can be tested with the #freezing-on-energy-saver-testing which simulates that Energy saver is active and that all tabs use a lot of CPU (this allows verifying whether a tab is eligible for freezing and would be frozen if it used a lot of CPU). Energy saver availability can be controlled via the BatterySaverModeAvailability policy (this change has no effect when Energy saver is inactive).
  • Chrome 131 on ChromeOS, Linux, macOS, Windows: The feature will start rolling out to 1% of Stable in Chrome 131. It will gradually be ramped up to 100% of Stable. Energy saver availability can be controlled via the BatterySaverModeAvailability policy (this change has no effect when Energy saver is inactive).

   

• Compression dictionary transport with Shared Brotli and Shared Zstandard 

  This feature adds support for using designated previous responses as an external dictionary for content encoding compressing responses with Brotli or Zstandard.

  Enterprises might experience potential compatibility issues with enterprise network infrastructure that intercepts HTTPS traffic and is sensitive to unknown content encodings. The enterprise policy CompressionDictionaryTransportEnabled is available to turn off the compression dictionary transport feature.

   
  • Chrome 130 on Windows, macOS, Linux, Android

   

• Keyboard-focusable scroll containers 

  Chrome 130 improves accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more.

  By making scrollers focusable by default, users who can't (or don't want to) use a mouse can now focus clipped content using tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard-focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>.

  Note: The previous rollout of this feature (started in Chrome 127) was stopped due to web compatibility issues, which should be fixed in the implementation shipping in Chrome 130.

   
  • Chrome 130 on Windows, macOS, Linux, Android

   

• Support non-special scheme URLs 

  Chrome 130 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. Now, 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 on Android now supports third-party autofill and password providers 

  Until now, third-party autofill and password providers could be used in Chrome on Android via accessibility APIs. In Chrome 130, we're adding direct support for Android Autofill which means these providers now work with Chrome on Android without the need for accessibility APIs. This should improve the performance of Chrome on Android. To take advantage of this, users need to ensure they have their third party provider configured in Android settings. Then, in Chrome they'll need to open Settings > Autofill services and choose Autofill using another service. If users do not change both settings, they will continue to use Google to autofill their passwords, payment and address information.

   
  • Chrome 130 on Android: The new setting will be available from Chrome 130. If users use the new setting it will take immediate effect. If the new setting is not used, users will continue to use either Google and a third party via accessibility (if installed). The support for accessibility APIs will be deprecated in early 2025, at which point the new settings will be honored for all users.

   

• <meter> element fallback styles 

  In Chrome 130, <meter> elements with appearance: none now have a reasonable fallback style that matches Safari and Firefox, instead of just disappearing from the page. Additionally, developers can now custom style the <meter> elements.

  A feature flag MeterAppearanceNoneFallbackStyle is available in chrome://flags until Chrome 133 to control this feature.

   
  • Chrome 130 on Windows, macOS, Linux, Android

   

• New policies in Chrome browser 

  Policy	Description
  DataURLWhitespacePreservationEnabled	DataURL Whitespace Preservation for all media types
  CloudProfileReportingEnabled	Enable Google Chrome cloud reporting for managed profile

   

Chrome Enterprise Core changes

    

• Default change for GenAI policies  

  Starting with 130, we are changing the default setting for GenAI policies from switched off to allowed, without improving AI models, for Workspace for Education users. If you have devices enrolled in Chrome Enterprise Core, this policy is automatically applied to those devices to prevent sending data for AI model training. The existing policies that have the updated default setting are:

  • CreateThemesSettings (available in the US-only for now)
  • DevToolsGenAiSettings (available in most countries)
  • HelpMeWriteSettings (available in the US-only for now)
  • HistorySearchSettings (available in the US-only for now)
  • TabOrganizerSettings (available in the US-only for now)
  • TabCompareSettings (available in the US-only for now)
   

  For more details about the default settings, see Chrome—Generative AI features and policies.

   

• Support for user-level settings on Custom configurations 

  Custom configurations recently launched in Chrome 127 and this feature allows IT admins to configure Chrome policies that are not yet in the Admin console, using JSON scripts. As early as October 15, Custom configurations will support applying settings at the user-level, in addition to device-level support. In order words, you will be able to enforce policies when users sign in to a managed Google account using Custom configurations.

   
  • As early as October 15 2024, on Android, iOS, Linux, macOS, Windows: Feature rolls out
   

  To get started, you can navigate to Chrome browser > Custom configurations in the Admin console; the Chrome Enterprise Core SKU is required to access this feature.

  

   

• Audit-only URL navigation rules 

  This feature lets customers create Chrome URL navigation rules with the Audit action. These rules allow admins to dry-run URL navigation rules before starting to show user warnings. They also allow admins to silently audit users’ navigation to restricted or sensitive URLs.

  URL auditing is part of the existing real-time URL check connector policy, EnterpriseRealTimeUrlCheckMode, which can be turned on by Organizational Unit or by Group.

   
  • Chrome 130 on ChromeOS, Linux, macOS, Windows
   

   

• Chrome Security Insights 

  You can now enable Chrome Security Insights to monitor insider risk and data loss with enhanced monitoring for Chrome activity. This feature is available for the following licenses: 

  • Chrome Enterprise Core
  • Workspace Enterprise Standard
  • Workspace Enterprise Plus. 

  For more information, see Monitoring for insider risk and data loss.

   
  • Chrome 125 on ChromeOS, Linux, macOS, Windows: Feature enabled for Chrome Enterprise Core 
  • Chrome 130 on ChromeOS, Linux, macOS, Windows: Feature enabled for EDU customers (except K-12)
   

   

• Risk score on the Chrome Apps and extensions usage report 

  This feature adds a new column in the Admin console for browser management that displays the risk assessment for installed extensions in the admin's environment. This new addition allows IT admins to quickly identify extensions with a high, medium or low risk score using the sorting and filtering functionality of the report.

   
  • Currently available to Trusted Testers. You can sign up for our Trusted Tester program here.
  • As early as October 15 on Linux, macOS, Windows: Addition of risk assessment to summary view.
   

  

Chrome Enterprise Premium changes

   

• In Chrome 130, there are no updates for Chrome Enterprise Premium. 

Upcoming Chrome browser changes

 

    

• Search and receive answers in your Chrome history with AI  

  Starting in Chrome 131, users will be able to search their browsing history and receive generated answers based on page contents. Initially, this feature will only be available to users in English in the US. Admins can control this feature by using the HistorySearchSettings policy. You have the following options for your organization:  

  • 0 = Enable the feature for users, and send relevant data to Google to help train or improve AI models. Relevant data may include prompts, inputs, outputs, and source materials, depending on the feature. It may be reviewed by humans for the sole purpose of improving AI models.
  • 1 = Enable the feature for users, but do not send data to Google to train or improve AI models.
  • 2 = Fully disable feature

  For more information, see Search your history in Chrome with AI. 

  ● Chrome 131 on Linux, Mac, Windows: the feature generates answers to your search queries.

   

    

• Ad-hoc code signatures for Progressive Web App shims on macOS  

  Code signatures for application shims that are created when installing a Progressive Web App (PWA) on macOS are changing to use ad-hoc code signatures, which 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 will result in each PWA shim having a unique identity to macOS; currently every PWA looks like the same application to macOS.

  This will address problems when attempting to include multiple PWAs in the macOS Open at Login preference pane, and will permit future improvements for handling user notifications within PWAs on macOS.

  Administrators 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 via chrome://flags/#use-adhoc-signing-for-web-app-shims. They can then install a Progressive Web Apps and ensure that it launches as expected.

  If there is an incompatibility between the feature and their current security policies, the enterprise policy, AdHocCodeSigningForPWAsEnabled, 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 (https://santa.dev/). 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 131 on macOS: Feature will begin to roll out to Stable, starting at 1% rollout.
   

    

• Asynchronous real-time Safe Browsing check  

  Today, Safe Browsing checks are on the blocking path of page loads, meaning that the user cannot see the page until the checks are completed. In Chrome 122 and later on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, to improve Chrome's loading speed, real-time Safe Browsing checks no longer block page loads. We have evaluated the risk and put mitigations in place: 

  1. For malware and 0-day attacks, local-blocklist checks will still be conducted in a synchronous manner so that malicious payloads are still blocked by Safe Browsing. 
  2. For phishing attacks, we've looked at data and it is unlikely the user would have interacted with the page (for example, type a password) by the time we show the warning.
   
  • Chrome 122 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows
  • Chrome 131 on iOS
   

    

• Remove non-standard GPUAdapter requestAdapterInfo() method  

  The WebGPU working group decided it was impractical for requestAdapterInfo() to trigger a permission prompt so they’ve removed that option and replaced it with the GPUAdapter info attribute. This means that web developers can get the same GPUAdapterInfo value synchronously. For more information, see the previous Intent to Ship: WebGPU: GPUAdapter info attribute.

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

    

• Deprecate Safe Browsing Extended reporting  

  Safe Browsing Extended reporting is a feature that enhances the security of all users by collecting telemetry information from participating users that is used for Google Safe Browsing protections. The data collected includes URLs of visited web pages, limited system information, and some page content. However, this feature is now superseded by Enhanced protection mode. We suggest users switch to Enhanced protection to continue providing security for all users in addition to enabling the strongest security available in Chrome. For more information, see Safe Browsing protection levels. 

   
  • Chrome 129 on Android, iOS, ChromeOS, Linux, macOS, Windows: Deprecation of Safe Browsing Extended Reporting. Excluding real-time Client Safe Browsing Report Request
  • Chrome 131 on Android, iOS, ChromeOS, Linux, macOS, Windows: Deprecating SafeBrowsingExtendedReportingEnabled for real-time Client Safe Browsing Report Request
   

  

  
  
   

    

• Update Google Play Services to fix issues with on-device passwords  

  Users with old versions of Google Play Services will experience reduced functionality with their on-device passwords, and Password Manager might soon stop working for them altogether. These users will need to update Google Play Services, or will be guided through other troubleshooting methods depending on their state. This is part of an ongoing migration that only affects Android users of Google Password Manager.

   
  • Chrome 131 on Android
   

    

• Entrust certificate distrust  

  In response to sustained compliance failures, Chrome 127 changes how publicly-trusted TLS server authentication, that is, websites or certificates issued by Entrust, are trusted by default. This applies to Chrome 127 and later on Windows, macOS, ChromeOS, Android, and Linux; iOS policies do not allow use of the Chrome Root Store in Chrome for iOS.

  Specifically, TLS certificates validating to the Entrust root CA certificates included in the Chrome Root Store and issued:

      - after October 31, 2024, will no longer be trusted by default.

      - on or before October 31, 2024, will be unaffected by this change. 

  If a Chrome user or an enterprise explicitly trusts any of the affected Entrust certificates on a platform and version of Chrome relying on the Chrome Root Store, for example, when explicit trust is conveyed through a Windows Group Policy Object, the Signed Certificate Timestamp (SCT) constraints described above will be overridden and certificates will function as they do today.  

  For additional information and testing resources, see Sustaining Digital Certificate Security - Entrust Certificate Distrust.

  To learn more about the Chrome Root Store, see this FAQ.

  • Chrome 131 on Android, ChromeOS, Linux, macOS, Windows: All versions of Chrome 131 and higher that rely on the Chrome Root Store will honor the blocking action, but the blocking action will only begin for certificates issued after November 11, 2024.
   

    

• Simplified sign-in and sync experience  

  Starting in Chrome 131, existing users with Chrome sync turned on will experience a simplified and consolidated version of sign-in and sync in Chrome. Chrome sync will no longer be shown as a separate feature in settings or elsewhere. Instead, users can sign in to Chrome to use and save information like passwords, bookmarks and more in their Google Account, subject to the relevant enterprise policies.

  As before, the functionality previously part of Chrome sync that saves and accesses Chrome data in the Google Account can be controlled by SyncTypesListDisabled. Sign-in to Chrome can be disabled via BrowserSignin as before.

  Note that the changes do not affect users’ ability to sign in to Google services on the web (like Gmail) without signing in to Chrome, their ability to stay signed out of Chrome, or their ability to control what information is synced with their Google Account.

   
  • Chrome 131 on Android 
   

    

• User Link capturing on PWAs  

  Web links automatically direct users to installed web apps. To better align with users' expectations around installed web apps, Chrome makes it easier to move between the browser and installed web apps. When the user clicks a link that could be handled by an installed web app, Chrome adds a chip in the address bar to suggest switching over to the app. When the user clicks the chip, this either launches the app directly, or opens a grid of apps that can support that link. For some users, clicking a link always automatically opens the app.

   
  • Chrome 121 on Linux, macOS, Windows: When some users click a link, it always opens in an installed PWA, while some users see the link open in a new tab with a chip in the address bar, clicking on which will launch the app. A flag is available to control this feature: chrome://flags/#enable-user-link-capturing-pwa.
  • Chrome 131 on Linux, macOS, Windows: Launch to 100% of Stable with either a default on (always launch apps on link clicks) or a default off (always open in a tab, only launch if the user clicks on chip on address bar).
     

  

   

    

• Deprecation of CSS Anchor Positioning property inset-area  

  The CSS working group (CSSWG) resolved to rename the inset-area property to position-area. For more details, see the CSSWG discussion on github. The new property name, position-area, as a synonym for inset-area shipped via this feature update described on Chrome Platform Status, describing the deprecation and removal of the inset-area property.

   
  • Chrome 131 on Windows, macOS, Linux, Android
   

    

• X25519Kyber768 key encapsulation for TLS  

  Starting in Chrome 124, Chrome enables by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism X25519Kyber768, based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both TLS 1.3 and QUIC connections.

  However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary PostQuantumKeyAgreementEnabled enterprise policy, which will be available through the end of 2024. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed. Post-quantum cryptography is required for CSNA 2.0.

  For more detail, see this Chromium blog post and this Google Security blog post.

   
  • Chrome 124 on Windows, Mac, Linux: new post-quantum secure TLS key encapsulation mechanism X25519Kyber768 is enabled
  • Chrome 131 on Windows, Mac, Linux: Switch to standard version of ML-KEM
  • Chrome 141 on Windows, Mac, Linux: Remove enterprise policy PostQuantumKeyAgreementEnabled
   

    

• Chrome PDF Viewer OCR  

  Chrome Desktop now makes scanned PDFs more accessible. Using on-device OCR to maintain privacy (no content is sent to Google), Chrome automatically converts scanned PDFs, allowing you to select text, Ctrl+F, copy, and paste. The feature does not bypass secure PDFs. It will only OCR PDFs the user has access to. The solution unlocks PDF accessibility to Chrome users without any extra steps, making PDFs as accessible as the rest of the web.

   
  • Chrome 131 on ChromeOS, Linux, macOS, Windows
   

    

• Insecure form warnings on iOS  

  Chrome 125 started to block form submissions from secure pages to insecure pages on iOS. When Chrome detects an insecure form submission, it now displays a warning asking the user to confirm the submission. The goal is to prevent leaking of form data over plain text without the user's explicit approval. A policy InsecureFormsWarningsEnabled is available to control this feature, and will be removed in Chrome 131.

   
  • Chrome 125 on iOS: Feature rolls out
  • Chrome 131 on iOS: InsecureFormsWarningsEnabled policy will be removed
   

    

• Network Service on Windows will be sandboxed  

  To improve security and reliability, the network service, already running in its own process, will be sandboxed on Windows. As part of this, third-party code that is currently able to tamper with the network service may be prevented from doing so. This might cause interoperability issues with software that injects code into Chrome's process space, such as Data Loss Prevention software. The NetworkServiceSandboxEnabled policy allows you to disable the sandbox if incompatibilities are discovered. You can test the sandbox in your environment using these instructions. You can use the Chromium bug tracker to report any issues you encounter.

   
  • Chrome 132 on Windows: Network Service sandboxed on Windows
   

    

• Read aloud in Reading mode   

  Reading mode is a side-panel feature that provides a simplified view of text-dense web pages. Reading mode will now include a Read aloud feature which allows users to hear the text they are reading spoken out loud. Users can choose different natural voices and speeds, and see visual highlights.

   
  • Chrome 132 on ChromeOS, Linux, macOS, Windows
   

    

• Capture all screens  

  This feature captures all the screens currently connected to the device using getAllScreensMedia(). Calling getDisplayMedia() multiple times requires multiple user gestures, burdens the user with choosing the next screen each time, and does not guarantee to the app that all the screens were selected. getAllScreensMedia() improves on all of these fronts.

  This feature is only exposed behind the MultiScreenCaptureAllowedForUrls enterprise policy, and users are warned before recording even starts, that recording could start at some point. The API will only work for origins that are specified in the MultiScreenCaptureAllowedForUrls allowlist. Any origin not specified there, will not have access to it.

   
  • Chrome 132 on ChromeOS
   

    

• 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 133 on Android, iOS, ChromeOS, LaCrOS, Linux, macOS, Windows: This will be a gradual roll-out.
   

    

• Private network access checks for navigation requests: warning-only mode  

  Before a website A navigates to another site B in the user's private network, this feature does the following:

  1. Checks whether the request has been initiated from a secure context.

  2. Sends a preflight request, and checks whether B responds with a header that allows private network access.

  There are already features for subresources and workers, but this one is for navigation requests specifically. These checks protect the user's private network.  

  Since this feature is the warning-only mode, we do not fail the requests if any of the checks fail. Instead, a warning will be shown in the DevTools console, to help developers prepare for the coming enforcement.

   
  • Chrome 133 on Windows, macOS, Linux, Android
   

    

• Deprecate mutation events  

  Synchronous mutation events, including DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, and DOMCharacterDataModified, 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. Starting in Chrome 124, a temporary enterprise policy, MutationEventsEnabled, will be available to re-enable deprecated or removed mutation events. If you encounter any issues, file a bug here.

  Mutation event support will be disabled by default starting in Chrome 127, around July 30, 2024. Code should be 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 through Chrome 134, ending March 25, 2025.
  • A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 134.

  Please see this blog post for more detail. Report any issues here.

  • Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.
  
   

    

• UI Automation accessibility framework provider on Windows  

  Starting in Chrome 126, Chrome will start 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.

  Administrators 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 administrators 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 administrators 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

   

• GenAI Defaults policy 

  Starting in 131, Chrome Enterprise Core will offer a policy to control the default behavior of multiple GenAI policies via our Trusted Tester program. You can sign up for our Trusted Tester program here. This policy will not impact any manually-set policy values for generative AI features. This policy will control the default settings for the following policies:

  • CreateThemesSettings 
  • DevToolsGenAiSettings
  • HelpMeWriteSettings
  • HistorySearchSettings 
  • TabOrganizerSettings
  • TabCompareSettings
   
  • Only available to Trusted Testers. You can sign up for our Trusted Tester program here.

    

• Chrome extension telemetry integration with SecOps  

  We will begin to collect relevant Chronicle extension telemetry data from within Chrome, for managed profiles and devices, and send it to Google SecOps. Google SecOps will analyze the data to provide instant analysis and context on risky activity; this data is further enriched to provide additional context and is searchable for a year.

   
  • Chrome 131 on ChromeOS, LaCrOS, Linux, macOS, Windows
   

    

• New managed profile list and reporting for signed-in users   

  Chrome Enterprise Core will introduce a new Managed profile list and reporting in the Admin console. This feature will provide a list of profiles for managed users who sign in to Chrome using a Google Account. IT administrators will need to enable the new Chrome Profile Reporting policy to view more information about a managed profile. The reporting will include details on managed profiles such as the browser versions, policies applied (including conflicts), extensions installed, and more.

   
  • Currently available on Android, Linux, macOS, Windows for the Trusted Tester program. You can sign up for our Trusted Tester program here.
  • As early as Chrome 130 on Android, Linux, macOS, Windows
     

    

• Remove enterprise policy used for legacy same site behavior  

  In Chrome 79, we introduced the LegacySameSiteCookieBehaviorEnabledForDomainList policy to revert the SameSite behavior of cookies to legacy behavior on the specified domains. The LegacySameSiteCookieBehaviorEnabledForDomainList policy’s lifetime has been extended and will be removed on the milestone listed below.

   
  • Chrome 132 on Android, ChromeOS, Linux, macOS, Windows: Remove LegacySameSiteCookieBehaviorEnabledForDomainList policy.

 

Upcoming Chrome Enterprise Premium changes

 

   

• Chrome Enterprise Data Controls: Clipboard 

  Admins can set data control rules in the Google Admin console to protect end users from data leakage on Chrome browser. Data Controls are lightweight rules set in the Google Admin console that allow admins to set a Chrome policy to control sensitive user actions such as copying and pasting sensitive data and taking screenshots or screen sharing. 

   

  This feature can be controlled via DataControlsRules policy. This feature is available to test for the members of the Chrome Enterprise Trusted Tester program. You can sign up for our Trusted Tester program here.

   
  • Chrome 128 on ChromeOS, Linux, macOS, Windows: Trusted Tester program
  • Chrome 131 on ChromeOS, Linux, macOS, Windows: Feature rolls out

  

   

   

• Screenshot protections 

  Admins can prevent users from taking screenshots or screen sharing specific web pages considered to contain sensitive data. Admins create a DLP URL filtering rule to block users taking screenshots or screen sharing specific URLs or categories of URLs. This feature can be controlled via the same EnterpriseRealTimeUrlCheckMode policy that enables all real-time URL lookups.

   

  This feature is available to test for the members of the Chrome Enterprise Trusted Tester program. You can sign up for our Trusted Tester program here.

   
  • Chrome 129 on ChromeOS, Linux, macOS, Windows: Trusted Tester program
  • Chrome 131 on ChromeOS, Linux, macOS, Windows: Feature rolls out.

   

ChromeOS 130 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Quick Insert		✓
Settings and shortcuts changes		✓
Focus on ChromeOS		✓
Enhanced access for Drive files		✓
New suggestions in Tote		✓
Welcome Recap		✓
Studio-style mic		✓
AI-powered Recorder app		✓
Content scanning for Managed Guest Sessions	✓		✓
Additional URLs allowed in Kiosk mode	✓		✓
Appearance effects		✓
More accessible privacy controls	✓
Enhanced keyboard brightness controls		✓
Enhanced display brightness controls		✓
Help me read on ChromeOS		✓
Multi-calendar support		✓
Picture-in-Picture windows		✓
Improved ARC++ user experience		✓
New policy to control Access Point Names			✓
Microsoft SCEP SID update			✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
AI wallpapers and backgrounds		✓
ChromeOS Flex auto-enrollment			✓
Graduate data migration		✓	✓
Chrome App support ending on ChromeOS			✓
Native Client (NaCl) support ending on ChromeOS	✓

 

DOWNLOAD Release notes (PDF)

↑ back to top

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.

ChromeOS updates

   

• Quick Insert 

  Quick Insert provides a quick way to insert emojis, symbols, GIFs, Google Drive links, and quick calculations and unit conversions with a keyboard key (on select models) or a keyboard shortcut. 

  In ChromeOS 130, a new shortcut Launcher + f is available on all ChromeOS devices. A new hardware key is initially available on the Samsung Galaxy Chromebook Plus only, but the Quick Insert key will launch on a range of devices in 2025.

  

   

• Settings and shortcuts changes 

  We’ve updated the shortcut and input device options in Settings to include: 

  • Quick Insert: Launcher + f

   

• Focus on ChromeOS 

  We've designed Focus on ChromeOS to help users minimize distractions and create a more productive workspace. With Focus, you can effortlessly set and adjust your focus time, enable or disable Do-not-Disturb (DND) mode, sort through or create new Google Tasks, and immerse yourself in curated playlists that help you focus better with focus sound or YouTube Music Premium (subscription-based). To use Focus, go to Quick Settings > Focus.

  

   

• Enhanced access for Drive files 

  In addition to files you’ve starred within Tote, access all your starred Drive files directly from the shelf, which is now available to you offline. Enhanced Drive suggestions in Launcher and Tote allow you shortcut access to your most important and frequently used files.

   

• New suggestions in Tote 

  Quickly access and pin the files you need the most with local and Drive file suggestions. The new Suggestions section in Tote suggests files to users, up-leveling files that will be useful for them to pin and access offline.

   

• Welcome Recap 

  The new Welcome Recap features help users resume their work and explore new options at start-up. Once you enable this feature you will be able to preview and restore apps and tabs from your previous session. Welcome Recap also provides helpful information like weather, your next calendar event, recent tabs from other devices and relevant Google Drive suggestions. 

  To turn on this feature, select Settings > System Preferences > Startup > Welcome Recap, and make sure Ask every time is chosen for your device.

  

   

• Studio-style mic 

  Make your Chromebook's built-in microphone sound like a professional studio microphone by activating this feature in the video call controls. Studio-style mic includes the existing noise cancellation and de-reverberation effects, and further enhances them with advanced balancing, reconstruction of fine details, and room adaptation. Users who have enabled noise cancellation will get the Studio-style mic enhancements by default starting with this release. If a user wants to revert to the old noise cancellation-only effect, they can select the appropriate option in Settings > Device > Audio. This feature is only available on Chromebook Plus devices.

   

• AI-powered Recorder app 

  ChromeOS 130 introduces the new Google AI-powered Recorder app to create transcriptions that can detect and label speakers, and provide a summary of recorded content. Our app goes beyond recording, offering speech-to-text, content summarization, and title suggestions, all powered by Google AI.

   

• Content scanning for Managed Guest Sessions 

  We are now enabling organizations to extend Chrome Enterprise Premium’s powerful scanning and content and context-based protection to local files in Managed Guest Sessions on ChromeOS. For example, a misplaced file containing Social Security numbers is instantly blocked when a user attempts to copy it to an external drive, safeguarding this confidential information.

   

• Additional URLs allowed in Kiosk mode 

  If a Kiosk app uses more than one URL origin, IT Admins can now enter the additional origins. All specified origins will get permissions automatically granted. Permissions will be rejected for any other origins not included in this list. 

     

   

• Appearance effects 

  Appearance effects have been popular among the products of cameras, virtual meetings, and short videos for a long time and launched on some Google products. In ChromeOS 130, we integrate this feature into Chromebook for video call controls. Available on Chromebook Plus devices only.

   

• More accessible privacy controls 

  In this launch, we are making OS-level privacy controls more available to users of Chrome browser. This aims to make users more aware that to make the camera or microphone work, they need to enable OS-level privacy controls.

     

   

• Enhanced keyboard brightness controls 

  Chromebook users can now easily adjust keyboard brightness and control the ambient light sensor directly from the Settings app. This new feature lets you set your keyboard brightness to the perfect level and turn the ambient light sensor on or off as needed. These updates make it simpler to use your device and help manage battery life. Meanwhile, if the Chromebook supports RGB, the Settings > Keyboard option now has a direct link to RGB color selection options. For more details, see Using gaming features on your Chromebook.

   

• Enhanced display brightness controls 

  Chromebook users can now easily adjust display brightness and control the ambient light sensor directly from the Settings app. This new feature lets you set your screen brightness to the perfect level and turn the ambient light sensor on or off as needed in Settings. These updates make it simpler to use your device and help manage battery life.

   

• Help me read on ChromeOS 

  Help me read on ChromeOS provides an AI-powered solution to help you quickly find the information you need in any text. Easily get to the heart of what you’re reading in the browser and in Gallery by right-clicking on an empty space to reveal the Help me read card above the existing contextual menu. The Help me read panel showcases a summary of the text and a freeform Q&A field where you can ask specific questions about the text. Available on Chromebook Plus devices only.

     

   

• Multi-calendar support 

  We are launching Multi-calendar support to allow users to view all events from multiple calendars that they have selected within their Google Calendar. 

   
   

   

• Picture-in-Picture windows 

  ChromeOS users can now enjoy greater flexibility with Picture-in-Picture (PiP) windows. PiP Tuck allows users to temporarily move PiP windows to the side of their screen, freeing up valuable screen space while keeping the video easily accessible. Additionally, you can quickly adjust the size of PiP windows with a quick double-tap, toggling between two sizes for optimal viewing.

     

   

• Improved ARC++ user experience 

  To improve ChromeOS and ARC++ user experience, we're moving ARC++ non-urgent background and error notifications to the system tray. This prevents these messages from unnecessarily popping up in the foreground and disrupting the user's journey. By moving these notifications to the system tray, we can ensure that users are still notified of potential issues but are not interrupted while using their Chromebook. For more information about ARC++, see this ChromeOS developer blog.

   

   

• New policy to control Access Point Names 

  For Chromebooks with cellular capability, Access Point Name (APN) policies allow administrators to restrict usage of custom APNs. By setting the AllowAPNModification flag in general network settings to restrict, they can prevent end users from adding or using any custom APNs.

   
   

   

• Microsoft SCEP SID update 

   

  Only for SCEP deployments using Microsoft NPS for RADIUS. If you are not using SCEP certificates in combination with Microsoft NPS for Radius for Chromebook network connectivity, you may disregard the remainder of these instructions. We expect this to be a setup more common in enterprise rather than in education.

  Microsoft has announced a security update that will add a new required field, a Security Identifier (SID), to SCEP certificates in environments utilizing NPS for Radius for network authentication. This addition is due to a security vulnerability on Windows devices where usable certificates with private keys can be exported from one Windows device to be used on any other device. Addition of the SID means that the certificate becomes linked to a device or user in your Active Directory environment so that an unknown device/user cannot use it. This is not a security issue for Chromebooks, as they do not allow the exporting of certificates with private keys in them and they are protected by the TPM. However, any certificate lacking this new field will fail to authenticate against a NPS for Radius server after the hard enforcement deadline of February 11th, 2025.

  What do you need to do?

  As soon as possible, verify if your deployment relies on both SCEP certificates and NPS for Radius for network authentication. This can be done by going into event viewer on your Domain Controller -> System, and searching for event ID #39. If you see this event ID:

   

  Actions to take if you see the event ID #39:

  1. Create a new object, or reuse an existing one, in your Active Directory environment for SCEP use
  2. Extract the SID for the AD object, for example, PS> (Get-ADUser username).SID.value
  3. Create a new SCEP profile with all settings duplicated from your current setup and add in the SID of the newly created, or existing, AD object from step 1.
  4. Under the Subject Alternative name section select the Custom radio button. Add a new Subject Alternative name using the + button with the type Uniform Resource Identifier from the dropdown. Under string, the value should be similar to: 

       tag:microsoft.com,2022-09-14:sid:S-1-2-3-4-5-6-8
  
       where S-1-2-3-4-5-6-8 is the SID of the AD object 

  
  5. Deploy this new certificate to all potentially affected Chromebooks in your fleet:
     1. Wait, AT LEAST ONE MONTH, to reasonably guarantee that all devices have picked up the new certificate.
  6. Relink any and all policies from the old certificate to the new one from Step 2.
  7. Verify functionality using the new certificate.
  8. Delete the old profile.

   

Upcoming ChromeOS changes

   

• AI wallpapers and backgrounds  

  As early as ChromeOS 131, we plan to introduce high-resolution, generative AI wallpapers and video call backgrounds on ChromeOS. With this feature, you can unleash your creativity and turn your Chromebook into a canvas of personal expression. Choose from a diverse collection of templates and, in just a few clicks, infuse your Chromebook with your unique personality, mood, or interest. 

  Two new policies will be available to control these features; GenAIVcBackgroundSettings and GenAIWallpaperSettings. This feature will be available on Chromebook Plus devices only.

   

• ChromeOS Flex auto-enrollment  

  As early as ChromeOS 131, ChromeOS Flex auto-enrollment will allow you to deploy ChromeOS Flex devices at scale. Similar to ChromeOS zero-touch enrollment, automatic enrollment embeds an enrollment token created by an organization's administrator into a ChromeOS Flex image. This will determine which customer organization and organizational unit a device will enroll into during initial device setup.

   

• Graduate data migration  

  As early as ChromeOS 132, a new Content Transfer tool will guide graduate students or other EDU-managed users who want to migrate their data through the updated Google Takeout Transfer process. This allows them to take their Docs, Sheets, Slides, and Gmail content to a Gmail account of their choice. 

  This new application allows school administrators to pin an icon to the shelf, notify students and faculty on their Chromebooks, and set dates to trigger these nudges to encourage them to use the existing Takeout Transfer process.

   

• Chrome App support ending on ChromeOS  

  In 2016, we announced the deprecation of Chrome Apps in favor of web apps, and in 2021, we announced on the Chromium Blog that Chrome App support for ChromeOS Enterprise and Education customers and developers on ChromeOS would be extended until at least January 2025. With the majority of our customers having migrated off of Chrome Apps (including Legacy (v1) packaged apps and Hosted apps), we can confirm the following updates about Chrome App discontinuation dates.

  July 2025: End of support for user-installed Chrome Apps (scheduled for ChromeOS M138).
  • Chrome Apps that are force-installed through the Admin console will continue to be supported.
  July 2026: Last ChromeOS release with support for Chrome Apps in Kiosk Mode (scheduled for ChromeOS M150).
  • Devices on the LTS channel with Chrome Apps in Kiosk Mode will receive support until April 2027.
  February 2028: Last ChromeOS release with support for Chrome Apps (scheduled for ChromeOS M168), marking the end of life for all Chrome Apps.
  • Devices on the LTS channel can continue to use Chrome Apps until October 2028.
  • No exceptions will be granted.
   

  These deprecation timelines also apply to self-hosted Chrome Apps.

  While no new Chrome Apps can be added to the Chrome Web Store, existing Chrome Apps can continue to be updated through October 2028 when they will reach end of life on ChromeOS. After this date, Chrome Apps will be removed from the Chrome Web Store.

  If your organization has developed in-house Chrome Apps and you need assistance, please refer to Transition from Chrome Apps guide. You can also join us in the ChromeOS developer community on Discord, or reach out to us through the form at https://chromeos.dev/work-with-us. Refer to the ChromeOS release schedule for release dates and updates.

  In the coming weeks, additional detailed information will be sent to all remaining Chrome App developers and all ChromeOS Administrators.

   

• Native Client (NaCl) support ending on ChromeOS  

  In 2017, we announced the deprecation of Native Client (NaCl) in favor of WebAssembly. With the majority of our customers having migrated off of NaCl, we can confirm some important changes coming to ChromeOS.

  • January 2025: Native Client (NaCl) will be disabled by default from ChromeOS M132 onwards.
    • For unmanaged and consumer users, M131 will be the last ChromeOS release with support for NaCl.
    • For managed user environments, administrators who manage ChromeOS devices for a business or school already will have the option of extending the ability to use NaCl with a NaCl allow policy through the M138 release. Starting with M132, the policy will also be available for Kiosk sessions.
  • July 2025: ChromeOS M138 will mark the end of life for NaCl technology on ChromeOS.
    • For managed environments, M138 is a Long-term Support (LTS) ChromeOS release available to administrators who manage ChromeOS devices for a business or school. Devices that have been switched to the LTS channel and have the NaCl allow policy enabled can continue to use NaCl until LTS Last Refresh in April 2026.
   

  If your organization has developed in-house Chrome Apps with NaCl and you need assistance, please refer to Transition from Chrome Apps and WebAssembly Migration guides. You can also join us in the ChromeOS developer community on Discord, or reach out to us through the form at https://chromeos.dev/work-with-us. Refer to the ChromeOS release schedule for release dates and updates. 

  In the coming weeks, additional detailed information will be sent to NaCl developers and impacted ChromeOS Administrators.