Chrome Enterprise and Education release notes

Last updated on: January 29, 2025 

For administrators who manage Chrome browser or ChromeOS devices for a business or school.

 

Select the required tab to see Chrome browser or ChromeOS updates.

 

Chrome 133 release summary

 
Chrome browser changes Security/ Privacy User productivity/ Apps Management
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    
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 App  
Upcoming Chrome Enterprise Premium changes Security/ Privacy User productivity/ Apps Management
Refactor DLP rules user experience     
Screenshot prevention V2     
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

 

   

  • Ad-hoc code signatures for PWA shims on macOS back to top

    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 back to top

    Starting in February 2025, Chrome Sync (using and saving data in your Google Account) no longer supports Chrome versions that are more than four years old. To continue using Chrome Sync, you need to upgrade to a more recent version of Chrome. To read more, see this discussion: Chrome Sync will be sunset on versions of Chrome that are more than four years old.

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

      This change affects only the old versions of Chrome and will be rolled out server-side. Chrome 133 is specified only to reflect the timeline when the change will make an effect. 

     

   

  • New option in HttpsOnlyMode policy back to top

    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 back to top

    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 back to top

    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 back to top

    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 back to top

    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

   

   

  • Removed policies in Chrome browser back to top
    Policy Description
    CSSCustomStateDeprecatedSyntaxEnabled Controls whether the deprecated syntax for CSS custom state is enabled.
     

   

Chrome Enterprise Core changes

   

  • DownloadRestrictions policy support on iOS back to top

    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.

 

Coming soon

Note: The items listed below are experimental or planned updates. They might change, be delayed, or canceled before launching to the Stable channel.

 

Upcoming Chrome browser changes

 

    

  • Privacy and security panel in Chrome DevTools back to top

    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 back to top

    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 back to top

    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. 

      AI feature disabled
    AI feature disabledAI feature disabled
    • Chrome 134 on ChromeOS, Linux,  macOS, Windows

    

  • Blob URL Partitioning: Fetching/Navigation back to top

    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 back to top

    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 back to top

    When blocked by the Content Security Policy (CSP), Chromium currently throws a SecurityError exception from the  "new Worker(url)" or "new SharedWorker(url)" constructors. According to the CSP specification,  

    the CSP check is performed as part of fetch and an error event should fire after the object is returned. This update aims to make Chromium spec-conformant, by not throwing an exception from the constructor but instead firing an error event asynchronously.

     
    • Chrome 134 on Windows,  macOS, Linux, Android

    

  • Remove nonstandard getUserMedia audio constraints back to top

    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 back to top

    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.

    

  • Disallow spaces in non-file:// URL host back to top

    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

    

    

  • Deprecate getters of Intl Locale Info API back to top

    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 back to top

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

    SwiftShader is a useful tool for web developers to test their sites on systems that are headless or do not have a supported GPU. This use case will still be supported by opting in but is not intended for running untrusted content.

    To opt-in to lower security guarantees and allow SwiftShader for WebGL, run the chrome executable with the --enable-unsafe-swiftshader command-line switch.

    During the deprecation period, a warning will appear in the JavaScript console when a WebGL context is created and backed with SwiftShader. Passing --enable-unsafe-swiftshader will remove this warning message.

    Chromium and other browsers do not guarantee WebGL availability. You can test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user.

     

    

  • SafeBrowsing API v4 to v5 migration back to top

    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 back to top

    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 back to top

      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 back to top

    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 back to top

    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 back to top

    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 back to top

    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 back to top

    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

↑ back to top  

 Sign up for emails about future releases

Previous release notes 

Additional resources

Still need help?

Google and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
14044730112975112288
true
Search Help Center
true
true
true
true
true
410864
false
false