Previous release notes

Chrome 140 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Automated password change	✓
Contextual Search suggestions in Chrome address bar		✓
DSE Prewarming		✓
Enhanced autofill		✓
Launch Chrome into a new Profile using command line	✓		✓
Signed-in users: Autofill and settings from Google Account.	✓
ServiceWorkerAutoPreload mode			✓
Shared tab groups		✓
Update to No HTTPS warning	✓
Stop sending Purpose: prefetch header from prefetches and prerenders	✓		✓
Deprecate special font size rules for H1 within some elements			✓
SharedWorker inherits controller for blob URL			✓
New policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
New filters on the Chrome Enterprise Overview page			✓
Regionalize covered Chrome Enterprise data			✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Copy/Paste rules protection	✓		✓
DLP support for iFrames	✓		✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Add a search hijacking heuristic signal to extension telemetry	✓
New Tab page footer	✓	✓	✓
Gemini in Chrome		✓
PostQuantum cryptography for DTLS in WebRTC	✓
CSS find-in-page highlight pseudos		✓	✓
Local network access restrictions	✓		✓
Origin-bound cookies (by default)	✓
Permissions policy for Device Attributes API	✓		✓
Strict Same Origin policy for Storage Access API	✓
window.name property no longer preserved for cross-site navigations	✓
Deprecating savedTabGroups as individual value in SyncTypesListDisabled			✓
Disallow non-trustworthy plaintext HTTP prerendering	✓
HSTS tracking prevention	✓
Web App manifest: update eligibility algorithm			✓
Happy Eyeballs V3	✓		✓
2SV enforcement for admins			✓
Disallow spaces in non-file:// URL hosts	✓
Remove third-party storage partitioning policies	✓
SafeBrowsing API v4 → v5 migration	✓
X25519Kyber768 key encapsulation for TLS	✓
Isolated Web Apps			✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Enrolled browsers support for the Enterprise Chrome Web Store customizations		✓
Inactive profile deletion in Chrome Enterprise Core	✓		✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Chrome browser rule UX refactor	✓		✓
Increased file size support for DLP scans	✓		✓
Watermarking customization	✓		✓

 

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  

   

• Automated password change 

  When Chrome detects that a user has signed into a website with a known compromised password, it now offers to change it automatically. This feature is available on a set of eligible sites. The feature uses AI, and admins can control it using the AutomatedPasswordChangeSettings enterprise policy.

  • Chrome 140 on ChromeOS, Linux, macOS, Windows

   

• Contextual search suggestions in Chrome address bar 

  With this feature, you can ask anything about the page you’re on, directly in context. Building on the existing Search habit of the address bar, users can ask a question with Google Lens by selecting anything on screen or asking with words. A Google Lens action in the address bar and contextual suggestions guide people to the feature when it’s most helpful. Admins can control this feature with the existing LensOverlaySettings policy.

   
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature starts rollout
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: If the LensOverlaySettings policy is not set, this feature will respect the GenAiDefaultSettings policy if present.
  

 

   

• DSE Prewarming 

  DSE Prewarming optimizes the default search provider integration in the Omnibox. When the Omnibox gets a focus, Chrome starts prerendering the prewarm page that preload required resources for the search result page, and reuses the resources to accelerate navigating to the search result page in the next query. Admins can control this feature  with the, NetworkPredictionOptions enterprise policy.

   
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: Gradual roll-out
   

   

• Enhanced autofill 

  Starting in Chrome 137, some users can turn on Autofill with AI, a new feature that helps users fill out online forms more easily. On relevant forms, Chrome can use AI to better understand the form and offer users to automatically fill in previously-saved info. Admins can control the feature using the existing GenAiDefaultSettings policy and a new AutofillPredictionSettings policy.

  • Chrome 137 on ChromeOS, Linux, macOS, Windows
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: The existing Autofill with AI feature will be renamed to Enhanced autofill, allow users to save and fill additional types of info, and become available in more countries and languages 

 

   

• Launch Chrome into new profile via command line 

  This feature is designed for our enterprise partners and admins who need to launch web applications from their native app catalogs directly into a specific managed Chrome profile using Chrome-Cli. Currently, if the designated profile does not exist, Chrome defaults to the last-used profile, creating a disjointed user experience. With this new feature, when a specified profile is not found, Chrome initiates the existing profile creation flow, pre-populating the user's email address to streamline the setup process. This is a key technical enabler for admins aiming to onboard their enterprise users to Chrome Enterprise via managed profiles.

  • Chrome 140 on Linux, macOS, Windows
   

   

• Signed-in users: Autofill and settings from Google Account 

  As part of our effort to streamline Chrome’s identity model on Desktop, managed accounts that originally signed in to Chrome implicitly by signing in to a Google web property, and who are in a managed profile with user policies, can now save and use Autofill, settings and themes from their Google Account while signed in. Existing user policies continue to work as before, including SyncDisabled, SyncTypesListDisabled, BrowserSignin, AutofillAddressEnabled, AutofillCreditCardEnabled and PasswordManagerEnabled.

   
  • Chrome 140 on Linux, macOS, Windows
   

   

• ServiceWorkerAutoPreload mode 

  ServiceWorkerAutoPreload is a mode where the browser issues the network request in parallel with the service worker bootstrap, and consumes the network request result inside the fetch handler if the fetch handler returns the response with respondWith(). If the fetch handler result is fallback, it passes the network response directly to the browser. ServiceWorkerAutoPreload is defined as an optional browser optimization, which will change the existing service worker behavior. Admins can control this feature using an enterprise policy called ServiceWorkerAutoPreloadEnabled.

   
  • Chrome 140 on Android, Windows: ServiceWorkerAutoPreloadEnabled policy
  • Chrome 144 on Android, Windows: ServiceWorkerAutoPreloadEnabled policy will be removed
   

   

• Shared tab groups 

  Users can now collaborate on tabs using the shared tab groups feature. With this feature, users can create and use a set of tabs on their desktop or mobile device and their collaborative partners can browse the same tabs on their devices. When one person changes a tab in the group, the changes are reflected across all users’ browsers in the group. Admins can control this feature using an enterprise policy, TabGroupSharingSettings, in Chrome 140.

   
  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Rollout of the ability to join and use a shared tab group. Users on Stable Chrome will not be able to create a shared tab group (the entry point will not be available) - this part of the feature will only be available on Beta/Dev/Canary for this phase of rollout. 
  • Chrome 139 on iOS:  As early as Chrome 139, support for iOS will rollout
  • Chrome 140 on Android, iOS, ChromeOS, Linux, macOS, Windows: TabGroupSharingSettings enterprise policy will be available to the enterprise owner in the admin console. 100% of users on Stable will be able to join and use a shared tab group. However, the ability to create a shared tab group will remain exclusive to users on Beta/Dev/Canary, implying that only users on those channels could initiate a group (their friends and coworkers on Stable can then join).
   

   

• Update to No HTTPS warning 

  Chrome 140 updates the warning displayed when a user opts in to the Always use secure connections on chrome://settings/security from an interstitial to a dialog. The URL content security indicator on the warning changes from an asterisk to a broken lock, while the full page load remains blocked and the functionality remains unchanged. Some users might see this warning automatically when visiting HTTP sites. Users can opt in to the warning on chrome://settings/security.

   
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: New warning design on desktop platforms
  • Chrome 141 on Android: New warning design on Android 
  

   

• Stop sending Purpose: prefetch header from prefetches and prerenders 

  Now that prefetches and prerenders are using the Sec-Purpose header for prefetches and prerenders, this change removes the legacy Purpose: prefetch header that is still currently passed. This update is behind a feature flag or kill switch to prevent compatibility issues.

  The scope includes speculation rules prefetch, speculation rules prerender, <link rel=prefetch>, and Chromium's non-standard <link rel=prerender>.

   
  • Chrome 140 on Windows, macOS, Linux, Android

   

• Deprecate special font size rules for H1 within some elements 

  The HTML spec contains a list of special rules for <h1> tags nested within <article>, <aside>, <nav>, or <section> tags. Chrome 140 deprecates these special rules, because they can cause accessibility issues. For example, they can visually reduce the font size for nested <h1> tags so that they look like <h2> tags, but nothing in the accessibility tree reflects this demotion.

  • Chrome 140 on Windows, macOS, Linux, Android

   

• SharedWorker inherits controller for blob URL 

  According to Worker client case (github), 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 140 on Windows, macOS, Linux, Android 

   

• New policies in Chrome browser 

  Policy	Description
  DataControlsRules	Sets a list of Data Controls rules.
  LiveCaptionEnabled	Enable Live Caption
  ProtectedContentIdentifiersAllowed	Allows web pages to use identifiers for the purpose of protected content playback
  TabGroupSharingSettings	Tab group sharing settings
  RestrictCoreSharingOnRenderer	Restrict CPU core sharing for renderer process
  OriginKeyedProcessesEnabled	Enable origin-keyed process isolation by default.
  AutomatedPasswordChangeSettings	Enable automated password change
  ServiceWorkerAutoPreloadEnabled	Allow ServiceWorker to dispatch navigation requests without waiting for its startup
  PrivacySandboxFingerprintingProtectionEnabled	Choose whether the Privacy Sandbox Fingerprinting Protection feature is to be enabled in Incognito mode.
  WebRtcPostQuantumKeyAgreement	Enable post-quantum key agreement for WebRTC
  SerialAskForUrls	Allow the Serial API on these sites
  SerialBlockedForUrls	Block the Serial API on these sites
  DefaultSerialGuardSetting	Control use of the Serial API
  SerialAllowAllPortsForUrls	Automatically grant permission to sites to connect all serial ports.
  LocalNetworkAccessAllowedForUrls	Allow sites to make requests to local network endpoints.
  LocalNetworkAccessBlockedForUrls	Block sites from making requests to local network endpoints.

    

Chrome Enterprise Core changes

   

• New filters on the Chrome Enterprise Overview page 

  The Chrome Overview page now includes new filters that allows admins to refine data by last activity date and organizational unit. This Overview page was originally introduced in Chrome 137 as part of the Chrome browser Enterprise section within the Google Admin console.

  • Chrome 140 on Android, iOS, Linux, macOS, Windows: As early as Chrome 140, new filters will be available on the Overview page.

  

   

• Regionalize covered Chrome Enterprise data 

  With Chrome 139, administrators gained the ability to designate a specific geographic location for storing users' covered Chrome Enterprise data. Options include the United States, European Union (displayed as Europe in the Google Admin console), or No preference. The full migration is anticipated to conclude by the end of Chrome 140. This setting is configurable within the Google Admin console under Data > Compliance > Data regions > Region > Data at rest. For details on the types of data covered, refer to the Chrome Enterprise Service Specific Terms.

   
  • Chrome 139 on Android, iOS, ChromeOS, Linux, macOS, Windows: Rollout will begin. Admins may be able to set a region; however, data may not be fully regionalized until the end of Chrome 140.
  • Chrome 140 on Android, iOS, ChromeOS, Linux, macOS, Windows: The initial migration will be fully regionalized.

Chrome Enterprise Premium changes

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

   

• Copy/Paste rules protection   

  To help organizations better prevent data exfiltration on mobile devices, Chrome is extending its existing desktop clipboard data controls. Administrators can now use the DataControlsRules policy to set rules that block or warn users when they attempt to copy or paste content that violates organizational policies. This feature allows admins to define data boundaries and prevent sensitive information from being pasted from a work context into personal apps or websites on their mobile fleet. This addresses a significant security gap and a frequently requested feature from enterprise customers who have cited the lack of mobile data controls as a concern.

  To use this feature, administrators can configure clipboard restrictions within the DataControlsRules policy, providing a consistent management experience across desktop and mobile to strengthen their organization's overall security posture. This help center article provides further context on how administrators can configure and manage Chrome Enterprise reporting connectors to forward browser security and data protection events to third-party services for analysis.

   
  • Chrome 140 on Android: Copy/Paste Rules Protection becomes available on Android 

   

• DLP support for iFrames   

  To enhance security and prevent data exfiltration, Chrome 140 extends Data Loss Prevention (DLP) capabilities to content within iFrames. With this change, when a user performs a DLP-triggering action (such as uploading a file) from a site loaded in an iFrame, Chrome now sends the entire URL hierarchy, from the source iFrame up to the top-level page, to be evaluated against all applicable DLP rules.

  No new enterprise policies are required to enable this functionality; it works with existing DLP rules configured via the Connector policies. Administrators should be aware that their existing rules now apply to iFrame contexts, which might block user actions that were previously permitted.

   
  • Chrome 139 on Linux, macOS, Windows: Initial launch of Data Loss Prevention support for iFrames. This phase adds enforcement for file upload events originating from within an iFrame context and it will work with existing DLP rules configured via the OnFileAttachedEnterpriseConnector policy
  • Chrome 140 on Linux, macOS, Windows: This expanded phase combines two feature rollouts, extending DLP iFrame support to include enforcement for both file download and printing actions.

Upcoming Chrome browser changes

    

• Add a search hijacking heuristic signal to extension telemetry 

  Malicious Chrome extensions intercept and redirect Omnibox and Realbox (the search box in the New tab page) search queries from the Search Engine Results Page (SERP) to an attacker-controlled URL. This feature adds a client-side heuristic to detect such search hijacking. The core idea is to compare user-initiated searches with successful SERP landings; a significant discrepancy over time strongly indicates hijacking activity. This heuristic generates a new signal, uploaded to the Safe Browsing CRX telemetry server via the existing Extension Telemetry service in Chrome. Server-side analysis of signal data from multiple Chrome browsers can then identify potential search hijacking.

   
  • Chrome 141 on ChromeOS, Linux, macOS, Windows

    

• New tab page footer 

  An update to the New tab page includes a new footer designed to provide users with greater transparency and control over their Chrome experience.

   
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Extension Attribution  will begin to show on the NTP. If an extension has changed your default New tab page, you'll now see a message in the footer that attributes the change to that specific extension. This message often includes a link directly to the extension in the Chrome Web Store, making it easier to identify and manage unwanted extensions. If you're an administrator, you can disable this attribution using the NTPFooterExtensionAttributionEnabled policy.
   
  • Chrome 139 on Linux, macOS, Windows: Browser management disclosure will be shown if one of the policies to customize the footer is set by an enterprise admin. For users whose Chrome browser is managed by a trusted source, the New tab page footer will now display a management disclosure notice. This helps you understand how your browser is being managed. Administrators can disable this notice with the NTPFooterManagementNoticeEnabled policy. Additionally, organizations can customize the footer's appearance using the EnterpriseLogoUrlForBrowser and EnterpriseCustomLabelForBrowser policies to display a custom logo and label.
   
  • Chrome 141 on Linux, macOS, Windows: A default notice (Managed by <domain name>) will start to be shown in the New tab page footer for all managed browsers. Visibility can be changed with the NTPFooterManagementNoticeEnabled policy. 
  

 

    

• Gemini in Chrome 

  Gemini is now integrated into Chrome on macOS and Windows, and can understand the content of your current page. Users can now seamlessly get key takeaways, clarify concepts, and find answers, all without leaving their Chrome tab. This integration includes both chat—where users can interact with Gemini via text, and Gemini Live , by which users can interact with Gemini via voice.

  In Chrome 141, Gemini in Chrome will be available for users signed into Chrome in the US. Admins can turn off this feature (value 1) using the GeminiSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see Gemini in Chrome in the Help Center.

  • Chrome 137 on macOS, Windows: Feature is available for some Google AI Pro and Ultra subscribers in the US and on pre-Stable (Dev, Canary, Beta) channels in the US.
  • Chrome 141 on macOS, Windows: Feature gradually rolls out on Stable for users signed into Chrome in the US.

 

    

• PostQuantum cryptography for DTLS in WebRTC 

  This feature will enable the use of PostQuantum Cryptography (PQC) with WebRTC connections. The motivation for PQC is to get WebRTC media traffic up to date with the latest cryptography protocols and prevent Harvest Now to Crack Later scenarios. 

  This feature will be controllable by an enterprise policy WebRtcPostQuantumKeyAgreementEnabled,  to allow enterprise users to opt out of PQC. The policy will be temporary and is planned to be removed by Chrome 151.

  • Chrome 141 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
  • Chrome 151 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Remove Enterprise Policy
   

    

• CSS find-in-page highlight pseudos 

  This feature will expose find-in-page search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the browser defaults have insufficient contrast with the page colors or are otherwise unsuitable.

  • Chrome 141 on Windows, macOS, Linux, Android 

    

• Local network access restrictions 

  Chrome 140 restricts the ability to make requests to the user's local network, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (for example, Intranet) to loopback. Gating the ability for websites to perform these requests behind a permission mitigates the risk of cross-site request forgery attacks against local network devices such as routers, and reduces the ability of sites to use these requests to fingerprint the user's local network.

  This permission is restricted to secure contexts. If granted, the permissions additionally relaxes mixed content blocking for local network requests (since many local devices are not able to obtain publicly trusted TLS certificates for various reasons).

  This work supersedes a prior effort called Private Network Access, which used preflight requests to have local devices opt-in. Enterprises that need to disable or auto-grant the permission can do so using the LocalNetworkAccessAllowedForUrls and LocalNetworkAccessBlockedForUrls policies. The value of '*' can be used to allow local network access on all URLs, matching the behavior prior to rolling out the restrictions.

   
  • Chrome 141 on Windows, macOS, Linux, Android

    

• Origin-bound cookies (by default)  

  In Chrome 141, cookies are bound to their setting origin (by default) such that they're only accessible by that origin, that is, sent on a request or visible through document.cookie. Cookies might ease the host and port binding restrictions through use of the Domain attribute but all cookies will be bound to their setting scheme.

  Temporary enterprise policies LegacyCookieScopeEnabled and LegacyCookieScopeEnabledForDomainList are available to revert this change. These policies will stop working in Chrome 150.

   
  • Chrome 141 on Windows, macOS, Linux, Android, iOS:  policy will be made available
  • Chrome 150 on Windows, macOS, Linux, Android, iOS:  policy will be removed

    

• Permissions policy for Device Attributes API  

  The new Permissions policy enables restricting access to the Device Attributes API, which is available only for policy-installed kiosk web apps and policy-installed Isolated Web Apps, both only on managed ChromeOS devices.

  Additionally, the feature is controlled by content settings. 2 new policies are introduced: DeviceAttributesBlockedForOrigins and DefaultDeviceAttributesSetting, to complement the previously-introduced  DeviceAttributesAllowedForOrigins policy. The feature is enabled by default for the supported scenarios described above.

   
  • Chrome 141 on Windows, macOS, Linux

    

• Strict Same Origin policy for Storage Access API 

  We plan to adjust the Storage Access API semantics to strictly follow the Same Origin Policy, to enhance  security. Using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default. The CookiesAllowedForUrls policy or Storage Access Headers can still be used to unblock cross-site cookies.

   
  • Chrome 141 on Windows, macOS, Linux, Android 

    

• window.name property no longer preserved for cross-site navigations 

  The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, which can leak information and potentially be used as a tracking vector. As early as Chrome 142,  the window.name property will no longer be preserved in this case, which will mitigate this issue. 

  This update will introduce a new temporary enterprise policy, ClearWindowNameCrossSiteBrowsing, which will stop working in Chrome 146.

   
  • Chrome 142 on Windows, macOS, Linux, Android, iOS

    

• Deprecating savedTabGroups as individual value in SyncTypesListDisabled 

  Currently, the SyncTypesListDisabled enterprise policy allows administrators to disable the synchronization of savedTabGroups datatype on desktop platforms. On mobile platforms, however, Tab Groups synchronization is already managed by the tabs datatype. To align desktop behavior with mobile and simplify sync management, the individual savedTabGroups datatype will be deprecated and will no longer be an individually customizable value within the SyncTypesListDisabled policy

   

  Action required by administrators: 

  Starting with Chrome 142, if your SyncTypesListDisabled policy disables either tabs or savedTabGroups, both data types will now be considered disabled. This means that disabling tabs will also disable saved tab groups, and vice-versa. The savedTabGroups value will be entirely removed from the list of supported datatypes for this policy. Administrators who have saved tab groups disabled and intend to keep this behavior must explicitly disable the tabs datatype. This will ensure the desired behavior before the savedTabGroups value is fully removed.

   
  • Chrome 142 on Windows, macOS, Linux 

    

• Disallow non-trustworthy plaintext HTTP prerendering 

  This launch will provide the capability to disallow non-trustworthy plaintext HTTP prerendering.

   
  • Chrome 142 on Windows, macOS, Linux, Android 

    

• HSTS tracking prevention 

  This update will mitigate user tracking by third-parties via the HTTP Strict Transport Security (HSTS) cache. This feature only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. Doing so makes it infeasible for third-party sites to use the HSTS cache in order to track users across the web.

   
  • Chrome 142 on Windows, macOS, Linux, Android
   

    

• Web App manifest: update eligibility algorithm 

  As early as Chrome 139, the Web App manifest will specify an update eligibility algorithm. This makes the update process more deterministic and predictable, giving the developer more control over whether (and when) updates should apply to existing installations, and allowing removal of the update check throttle that user agents currently need to implement to avoid wasting network resources.

  • Chrome 142 on Windows, macOS, Linux
  • Chrome 143 on Android
   

    

• Happy Eyeballs V3 

  This launch is an internal optimization in Chrome that implements Happy Eyeballs V3 to achieve better network connection concurrency. Happy Eyeballs V3 performs DNS resolutions asynchronously and staggers connection attempts with preferable protocols (H3/H2/H1) and address families (IPv6 or IPv4) to reduce user-visible network connection delay. This feature is gated by a temporary policy HappyEyeballsV3Enabled.

   
  • Chrome 144 on Android, ChromeOS, Linux, macOS, Windows
   

    

• 2SV enforcement for admins 

  To better protect your organization’s information, Google will soon require all accounts with access to admin.google.com to have 2-Step Verification (2SV) enabled. As a Google Workspace administrator, you need to confirm your identity with 2SV, which requires your password plus something additional, such as your phone or a security key.

  The enforcement will be rolled out gradually over the coming months. You should enable 2SV for the admin accounts in your organization before Google enforces it. For more information, see this About 2SV enforcement for admins.

   
  • Chrome 137 on ChromeOS, Linux, macOS, Windows: 2SV enforcement starts
  • Chrome 145 on ChromeOS, Linux, macOS, Windows: 2SV mandatory
   

    

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

  According to the URL Standard specification, 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 (Github).

  • Chrome 145 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, Fuchsia

    

• Remove Third-party storage partitioning policies 

  Third-party storage partitioning became the default in Chrome 115. The chrome:// flag that allowed users to disable this feature was removed in Chrome 128, and the deprecation trial ended with Chrome 139. In Chrome 145, the enterprise policies DefaultThirdPartyStoragePartitioningSetting and ThirdPartyStoragePartitioningBlockedForOrigins will be removed. Users are advised to transition to alternative storage solutions, either by adapting to third-party storage partitioning or by using document.requestStorageAccess({...}) where needed.

  If you have any feedback, you can add it here in the Chromium bug.

   
  • Chrome 145 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Removal of DefaultThirdPartyStoragePartitioningSetting and ThirdPartyStoragePartitioningBlockedForOrigins
   

    

• SafeBrowsing API v4 → 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. For more details, see Migration From V4 - Safe Browsing. 

   
  • Chrome 145 on Android, iOS, ChromeOS, Linux, macOS, Windows: Feature would gradually roll-out 

    

• 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. To learn more, see Protect Chrome Traffic with Hybrid Kyber KEM.

  • Chrome 131 on Linux, macOS, Windows: Chrome will switch the key encapsulation mechanism to the final standard version of ML-KEM
  • Chrome 145 on Linux, macOS, Windows: Enterprise policy will be removed

    

• 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 that 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 the explainer. 

  In this initial release, IWAs will only be installable through an admin policy on enterprise-managed ChromeOS devices.

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

    

• 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 may use the UiAutomationProviderEnabled enterprise policy starting in 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 146, and will be removed in Chrome 147. 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 146.
  • Chrome 147 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 updates

    

• Enrolled browsers support for the Enterprise Chrome Web Store customizations 

  The Customized Chrome Web Store will support managed browsers enrolled in Chrome Enterprise Core (Cloud machine settings). This will allow admins to customize the Chrome Web Store without the need for users to sign in. The customizations include:

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

  The Chrome Web Store customization settings were previously launched in Chrome 132 but only supported user-level policies (for signed-in users). As early as Chrome 140, this feature will be available to Chrome Enterprise Core Truster Testers.

   
  • Chrome 141 on Linux, macOS, Windows: As early as Chrome 141, this feature will launch to General Availability (GA).
   

    

• Chrome Enterprise Overview page 

  Chrome 137 introduced a new Overview page in the Chrome browser section of the Google Admin console. The Overview page allows IT administrators to quickly find key information about their deployment:

  - Active & inactive profiles and enrolled browsers

  - Identify browsers out-of-date and with pending updates

  - Identify high-risk extensions (according to Spin.AI) and get a preview of most requested extensions

  - Security Insights (for example, sensitive file uploads or downloads)

   

  The Overview page also allows admins to quickly access key actions such as managing extensions, accessing the browser or profile list and setting update policies, to name a few.

   
  • Chrome 137 on Android, iOS, Linux, macOS, Windows: Publicly Available to IT administrators
  • Chrome 141 on Android, iOS, Linux, macOS, Windows: New filtering available on the Overview page for Organization Unit and Activity Dates
   

    

• Inactive profile deletion in Chrome Enterprise Core 

  In June 2025, the inactive period for profile deletion setting started to roll out. In September 2025, the setting will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. When releasing the setting, the inactivity period of time has a default value of 90 days. Meaning that by default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this setting. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If the set value is lowered, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is reactivated on a device, that profile will reappear in the console.

   
  • Chrome 141 on Android, ChromeOS, Linux, macOS, Windows: Policy was rolled out in June. Deletion will start in September and the initial wave of deletion will complete by the end of September. After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.

Upcoming Chrome Enterprise Premium changes

   

• Chrome browser rule UX refactor 

  To enhance the Data Loss Prevention (DLP) rule creation experience, the Google Admin console is being updated to streamline how administrators define policies for different applications like Chrome and Workspace. This first introduces mutually exclusive application groups, meaning that a single DLP rule can now only target one application group at a time—either Workspace apps (like Drive, Gmail), Chrome browser triggers (like file upload, URL visited), or ChromeOS triggers. This change simplifies rule configuration, eliminates potential conflicts from overlapping app selections, and lays the groundwork for more specialized and user-friendly workflows tailored to each platform's needs.

  Administrators will see an updated Apps selection interface using radio buttons to enforce this single-group selection for new rules. Existing rules that previously combined applications from multiple groups will be transparently migrated by the system into separate, compliant, single-platform rules to ensure continued protection and a seamless transition. Banners within the Admin console will provide information regarding these changes and the migration process. No new enterprise policies are introduced with this update; the changes are to the rule configuration interface.

   
  • Chrome 141 on ChromeOS, Linux, macOS, Windows: Enables mutually exclusive app selection for DLP rule configuration in Admin Console
  
  
   

   

• Increased file size support for DLP scans 

  Chrome Enterprise Premium now extends its Data Loss Prevention (DLP) and malware scanning capabilities to include large and encrypted files. Previously, files larger than 50 MB and all encrypted files were skipped during content scanning. This update closes that critical security gap. For policies configured to save evidence, files up to 2GB can now be sent to the Evidence Locker. This provides administrators with greater visibility and control, significantly reducing the risk of data exfiltration through large file transfers.

  No new policy is required to enable this feature. It is automatically controlled by the existing DLP rule configurations in the Google Admin console. If admins have rules that apply to file uploads, downloads, or printing, they will now also apply to large and encrypted files.

  • Chrome 140 on Linux, macOS, Windows: Feature is rolled out
   

   

• Watermarking customization 

  Chrome Enterprise Premium now allows administrators to customize the appearance of watermarks. This enhancement is motivated by the need to improve user experience, addressing concerns such as eyestrain and readability on pages with existing watermarks.

  To control the watermark's appearance, administrators can use the new WatermarkStyle policy. Within this policy, admins can configure the following:

  • 'font_size': Sets the font size of the text in pixels. 
  • 'fill_opacity': Sets the fill opacity of the text, from 0 (transparent) to 100 (opaque). 
  • 'outline_opacity': Sets the outline opacity of the text, from 0 (transparent) to 100 (opaque). 

  This provides administrators with greater flexibility to balance security requirements with user productivity.

  • Chrome 141 on ChromeOS, Linux, macOS, Windows: This launch enables administrators to customize watermark font size and opacity using the new WatermarkStyle policy in the Google Admin Console.

ChromeOS 140 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Screen recording notifications		✓
Device Attributes API in IWAs	✓
GoogleLocationServicesEnabled policy	✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Battery charge limit setting in UI			✓

 

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.

Current ChromeOS updates

   

• Screen recording notifications 

  This feature introduces a notification bypass allowlist for the getAllScreensMedia API for trusted applications. 

   

• Device Attributes API in IWAs 

  This launch brings a new Permissions-Policy for Device Attributes API on managed devices and changes how the permission to that API is obtained for Isolated Web Apps.

   

• GoogleLocationServicesEnabled policy 

  Early 2025, ChromeOS shipped a new system-wide geolocation control inside of Privacy and security settings that can be set to Allow, Only allowed for system services (for example, automatic time zone and local weather), or Off. Admins can choose to either set a default value that users can override, or enforce one of the settings. To change their device settings, users can select Settings >  Privacy and security > Privacy control > Location access > Change access.

  If an extension or app relies on access to device location as part of your management strategy, you need to set the GoogleLocationServicesEnabled policy to enforce allow. Otherwise, devices might only be able to send location to these apps or extensions with precise IP address data.

  

Upcoming ChromeOS changes

   

• Battery Charge Limit setting in UI 

  As early as ChromeOS 143, users will be able to take direct control of their Chromebook’s battery health to extend its lifespan with new charging optimization settings. These features help preserve your battery’s long-term health by adjusting how your device charges.

  To configure these options, users can navigate to Settings > System preferences > Power and click Change next to Optimized charging. You can choose between:

  • Adaptive charging: Intelligently delays charging to 100% until it's needed, based on your daily usage patterns.
  • Charge limit: Maximizes your battery's lifespan by limiting the maximum charge to 80%.

  

  This feature is the user-facing counterpart to the DevicePowerBatteryChargingOptimization policy available in the Google Admin console. Admins can set this policy to one of three options:

  1. Adaptive: The device delays charging to 100% until necessary.
  2. Limited: The battery charges only to around 80%.
  3. Standard: If neither of the above optimized settings are selected, the battery charges normally to 100% 

  It is important to note that the policy set by an administrator overrides any setting selected by the user. A user can only benefit from adjusting the charge optimization options on their device if no overriding policy is enforced. By default, if no policy is enforced, Optimized Charging is enabled on the device with the Adaptive Charging option selected.

Chrome 139 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
AI Mode for search recommendations in Chrome		✓
Admin-configurable site search		✓	✓
Chrome on Android no longer supports Android Oreo or Android Pie			✓
Malicious APK download checks	✓
Migrate extensions to Manifest V3 before June 2025	✓	✓	✓
New tab page footer	✓	✓	✓
Prevent accidental password deletions on Chrome	✓
Promotional notifications			✓
Remove risky extension flags in Chrome	✓
Remove SwiftShader fallback	✓
Shared tab groups		✓
Support accounts in pending state on Chrome iOS	✓
Upcoming change for CA certificates included in the Chrome Root Store	✓
Stop sending Purpose: prefetch header from prefetches and prerenders	✓		✓
Chrome removes support for macOS 11			✓
Fire error event instead of throwing exception for CSP blocked worker			✓
Randomizing TCP port allocation on Windows			✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Group based policies for connector configuration selection			✓
New remote commands and CSV export for the Managed Profile List			✓
New tab page cards for Microsoft 365		✓	✓
Regionalize covered Chrome Enterprise data			✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Active account detection	✓		✓
Chrome Enterprise Connectors API	✓		✓
Copy and paste rules protection	✓		✓
Data Loss Prevention support for iFrames	✓		✓
Enable watermarking on Single Page Applications	✓		✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
2SV enforcement for admins			✓
Automated password change	✓
Contextual search suggestions in Chrome address bar		✓
Enhanced autofill		✓
Gemini in Chrome		✓
Happy Eyeballs V3	✓		✓
Launch Chrome into new profile from command line	✓		✓
PostQuantum cryptography for DTLS in WebRTC	✓
ServiceWorkerAutoPreload			✓
CSS find-in-page highlight pseudos		✓	✓
Deprecate special font size rules for H1 within some elements			✓
IP protection	✓		✓
Local network access restrictions	✓		✓
Probabilistic reveal tokens	✓		✓
Propagate Viewport overscroll-behavior from Root	✓		✓
Script blocking in Incognito	✓		✓
SharedWorker script inherit controller for blob script URL			✓
Strict Same Origin Policy for Storage Access API	✓
Web App Manifest: specify update eligibility, icon urls are Cache-Control: immutable			✓
Clear window name for cross-site navigations that switches browsing context group	✓
Disallow non-trustworthy plaintext HTTP prerendering	✓
HSTS tracking prevention	✓
Disallow spaces in non-file:// URL hosts			✓
Remove third-party storage partitioning policies	✓
SafeBrowsing API v4 → v5 migration	✓
Isolated Web Apps			✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Inactive profile deletion in Chrome Enterprise Core	✓		✓
Chrome Enterprise Overview page			✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Increased file size support for Data Loss Prevention scans	✓		✓
Watermarking customization	✓		✓
Chrome browser rule UX refactor	✓		✓

 

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  

   

• AI Mode for search recommendations in Chrome 

  AI Mode is a feature that helps users dive deeper into topics they care about by showing AI Mode for search recommendations in Chrome. A new policy, AIModeSettings, is available to control search recommendations in the address bar and New tab page search box. This policy also controls AI Mode recommendations in the address bar and the new tab page omnibox.

   
  • Chrome 138 on ChromeOS, Linux,  macOS, Windows: AI Mode recommendations starts rolling out in the address bar and the new tab page search box. The AI Mode entry point is also rolled out in the new tab page search box.
  • Chrome 139 
    • on Windows,  macOS, Linux and ChromeOS: The AI Mode entrypoint button in the address bar begins rollout. AI Mode inline compose box in new tab page omnibox begins rollout. 
    • on Android, iOS: The AI Mode entrypoint in the new tab page omnibox begins to roll out. And for iOS  the AI Mode recommendations starts rollout in the address bar as well. 
   

  

  

  

   

   

• Admin-configurable site search 

  Site search shortcuts are a way to use the address bar (omnibox) as a search box for a specific site without navigating directly to the site’s URL, similar to how you can use the omnibox to perform a broad Google search of the web. Administrators can now create site shortcuts for users to shortcut to the most critical enterprise sites. Users can initiate a search by typing the shortcut or @shortcut (for example, @work), followed by Space or Tab, in the address bar.

  Admins control these shortcut settings using the SiteSearchSettings policy.

   
  • Chrome 128 on ChromeOS, Linux,  macOS, Windows: Gradual rollout
  • Chrome 139 on ChromeOS, Linux,  macOS, Windows: Adding an additional policy parameter allowing admins to specify Allow user override, which allows users to edit, disable, or delete admin-set shortcuts
   

  

  

   

   

• Chrome on Android no longer supports Android Oreo or Android Pie 

  The last version of Chrome that supports Android Oreo or Android Pie is Chrome 138, and it includes a message to affected users informing them to upgrade their operating system. Chrome 139 and later versions will not be supported on, nor shipped or available to, users running Android Oreo or Android Pie.

   
  • Chrome 139 on Android: Chrome on Android no longer supports Android Oreo or Android Pie.
   

   

• Malicious APK download checks 

  Chrome on Android now contacts Google servers about Android Package Kit (APK) files downloaded in Chrome, to get a verdict about their safety. If a downloaded APK file is determined to be dangerous, Chrome shows a warning and blocks the download, to protect users against mobile malware. Such download warnings are bypassable by the user through the Chrome UI. These malicious APK download checks are performed for users enrolled in Standard Protection or Enhanced Protection from Google Safe Browsing. This feature can be disabled by setting the Safe Browsing mode to No Protection using the SafeBrowsingProtectionLevel policy.

   
  • Chrome 139 on Android
   

  

   

   

• Migrate extensions to Manifest V3 before June 2025 

  Extensions must be updated to use Manifest V3. Chrome extensions are transitioning to a new manifest version, Manifest V3. This brings improved privacy for your users—for example, by moving to a model where extensions modify requests declaratively, without the ability to see individual requests. This also improves extension security, as remotely-hosted code is disallowed on Manifest V3. 

  Beginning June 2024, Chrome gradually disables Manifest V2 extensions running in the browser. An enterprise policy - ExtensionManifestV2Availability - can be used to test Manifest V3 in your organization ahead of the migration. Additionally, machines on which the policy is enabled are not subject to the disabling of Manifest V2 extensions until June 2025 - at which point the policy is to be removed.

  You can see which Manifest version is being used by all Chrome extensions running on your fleet using the Apps & extensions usage page in Chrome Enterprise Core. 

   
  • Chrome 127 on ChromeOS, LaCrOS, Linux, macOS, Windows: Chrome will gradually disable Manifest V2 extensions on user devices. Only those with the ExtensionManifestV2Availability enterprise policy enabled would be able to continue using Manifest V2 extensions in their organization.
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Remove ExtensionManifestV2Availability policy.
   

   

• New tab page footer 

  An update to the New tab page includes a new footer designed to provide users with greater transparency and control over their Chrome experience.

   
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Extension Attribution  will begin to show on the NTP. If an extension has changed your default New tab page, you'll now see a message in the footer that attributes the change to that specific extension. This message often includes a link directly to the extension in the Chrome Web Store, making it easier to identify and manage unwanted extensions. If you're an administrator, you can disable this attribution using the NTPFooterExtensionAttributionEnabled policy.
  • Chrome 139 on Linux, macOS, Windows: Browser management disclosure will be shown if one of the policies to customize the footer is set by an enterprise admin. For users whose Chrome browser is managed by a trusted source, the New tab page footer will now display a management disclosure notice. This helps you understand how your browser is being managed. Administrators can disable this notice with the NTPFooterManagementNoticeEnabled policy. Additionally, organizations can customize the footer's appearance using the EnterpriseLogoUrlForBrowser and EnterpriseCustomLabelForBrowser policies to display a custom logo and label.
  • Chrome 140 on Linux, macOS, Windows: A default notice (Managed by <domain name>) will start to be shown in the New tab page footer for all managed browsers. Visibility can be changed with the NTPFooterManagementNoticeEnabled policy. 
   

  

   

   

• Prevent accidental password deletions on Chrome 

  To reduce the risk of accidental deletion of passwords on Delete browsing data, Chrome 139 now points users to Google Password Manager settings, where they can better manage and delete passwords and passkeys. The feature removes the Passwords and other sign-in data selection in Delete browsing data and instead directs users to Google Password Manager where they can delete individually or in bulk.

  This feature does not impact the existing enterprise policies ClearBrowsingDataOnExitList and BrowsingDataLifetime. 

   
  • Chrome 139 on ChromeOS, Linux,  macOS, Windows:  Feature will gradually roll out. 

  

   

   

• Promotional notifications 

  In Chrome 128, new promotional OS-level notifications began to be shown to users. These notifications are governed by the PromotionsEnabled enterprise policy.

   
  • Chrome 128 on ChromeOS, Linux, macOS, Windows
  • Chrome 139 on Windows: In Chrome 138, promotional notifications were only activated on Chrome clients when upgrading from Windows 10 to Windows 11. From Chrome 139, this is being extended to all Windows Chrome installations. Notifications will still be only shown to a subset of low-engaged users, and these can be disabled through the PromotionsEnabled enterprise policy.
   

   

• Remove risky extension flags in Google Chrome 

  To enhance the security and stability of the Chrome browser for our users, official Chrome branded builds will be removing --extensions-on-chrome-urls and --disable-extensions-except command-line flags starting in Chrome 139. This change aims to mitigate the risks associated with harmful and unwanted extensions. 

  Developers can still use the both flags in non-branded builds such as Chromium and Chrome For Testing.

   
  • Chrome 139 on Linux, macOS, Windows
   

   

• Remove SwiftShader fallback 

  Allowing automatic fallback to WebGL backed by SwiftShader is deprecated and WebGL context creation now fails 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. It is important to 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 139 
    • on Linux, macOS: Swiftshader will be disabled on macOS and Linux.  Users on machines without a GPU will not be able to use WebGL.
    • On Windows: The fallback to Swiftshader after three out-of-memory (OOM) errors will be disabled on Windows. Swiftshader usage will be limited to devices without a GPU or those with a GPU on the blocklist. 
   

   

• Shared tab groups 

  Users can now collaborate on tabs using the shared tab groups feature. With this feature, users can create and use a set of tabs on their desktop or mobile device and their collaborative partners can browse the same tabs on their devices. When one person changes a tab in the group, the changes are reflected across all users’ browsers in the group. An enterprise policy, TabGroupSharingSettings, will be available in Chrome 140 to control this feature.

   
  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Rollout of the ability to join and use a shared tab group. Users on Stable Chrome will not be able to create a shared tab group (the entry point will not be available) - this part of the feature will only be available on Beta/Dev/Canary for this phase of rollout. 
  • Chrome 139 on iOS:  As early as Chrome 139, support for iOS will rollout
  • Chrome 140 on Android, iOS, ChromeOS, Linux,  macOS, Windows: TabGroupSharingSettings enterprise policy will be available to the enterprise owner in the Google Admin console.
   

   

• Support accounts in pending state on Chrome iOS 

  Accounts whose credentials somehow became invalid are no longer automatically signed out and removed from Chrome on iOS. Instead, these accounts stay signed in to the browser, in a newly introduced pending state associated with a persistent error indication in the UI so users are encouraged to resolve it. This also means that local data associated with these accounts are no longer automatically deleted, but instead kept on disk. Existing policies controlling sign-in (for example, BrowserSignin) continue to work as before.

   
  • Chrome 139 on iOS: Feature will gradually roll out 
   

   

• Upcoming change for CA certificates included in the Chrome Root Store 

  In response to sustained compliance failures, Chrome 139 changes how publicly-trusted TLS server authentication, that is, websites or certificates issued by Chunghwa Telecom and Netlock, are trusted by default. This applies to Chrome 139 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 Chunghwa Telecom or Netlock root CA certificates included in the Chrome Root Store and issued:

      - after July 31, 2025, will no longer be trusted by default.

      - on or before July 31, 2025, will be unaffected by this change. 

  If a Chrome user or an enterprise explicitly trusts any of the affected Chunghwa Telecom or Netlock 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 - Upcoming Changes to the Chrome Root Store.

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

   
  • Chrome 139 on Android, ChromeOS, Linux, macOS, Windows: All versions of Chrome 139 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 July 31, 2025.
   

   

• Stop sending Purpose: prefetch header from prefetches and prerenders 

  Now that prefetches and prerenders are using the Sec-Purpose header for prefetches and prerenders, this change  removes the legacy Purpose: prefetch header that is still currently passed. This update is behind a feature flag or kill switch to prevent compatibility issues.

  The scope includes speculation rules prefetch, speculation rules prerender, <link rel=prefetch>, and Chromium's non-standard <link rel=prerender>.

   
  • Chrome 139 on Windows,  macOS, Linux, Android
   

   

• Chrome to remove support for macOS 11 

  Chrome 138 is the last release to support macOS 11; Chrome 139 and later will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

  On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome updated, they need to update their computer to a support version of macOS. For new installations of Chrome 139 and later, macOS 12 and later will be required.

   
  • Chrome 139 on Windows, macOS, Linux
   

   

• Fire error event instead of throwing exception for CSP blocked worker 

  When blocked by Content Security Policy (CSP), Chromium currently throws a SecurityError from the constructor of Worker and SharedWorker. To be spec-compliant, the CSP needs to be checked as part of fetch and then fire error events asynchronously instead of throwing an exception when the script runs new Worker(url) or new SharedWorker(url). 

  This update aims to make Chromium spec-conformant, which is, it no longer throws exceptions following constructor calls, and fires error events asynchronously.

   
  • Chrome 139 on Windows, macOS, Linux, Android
   

   

• Randomizing TCP port allocation on Windows 

  This feature enables TCP port randomization on Windows versions 2020 H1 and later. We do not anticipate issues with rapid re-use of prior ports (which can cause rejections due to port re-use timeouts) on these versions. The rapid port re-use issue stems from the Birthday problem, where the probability of randomly re-picking an already used port quickly approaches 100% with each new port chosen, unlike sequential port re-use models.

   
  • Chrome 139 on Windows, macOS, Linux
   

   

• New policies in Chrome browser 

  Policy	Description
  GeminiSettings	Settings for Gemini integration
  WatermarkStyle	Configure Custom Watermark Settings
  EnableUnsafeSwiftShader	Allow software WebGL fallback using SwiftShader
  NTPFooterManagementNoticeEnabled	Control the visibility of the management notice on the New Tab Page for managed browsers
  EnterpriseLogoUrlForBrowser	Enterprise Logo URL for a managed browser
  EnterpriseCustomLabelForBrowser	Set a custom enterprise label for a managed browser
  LocalNetworkAccessRestrictionsEnabled	Specifies whether to apply restrictions to requests to local network endpoints
  LocalNetworkAccessAllowedForUrls	Allow sites to make requests to local network endpoints.
  LocalNetworkAccessBlockedForUrls	Block sites from making requests to local network endpoints.

   

• Removed policies in Chrome browser 

  Policy	Description
  ExtensionManifestV2Availability	Control Manifest v2 extension availability
  SelectParserRelaxationEnabled	Controls whether the new HTML parser behavior for the <select> element is enabled
  KeyboardFocusableScrollersEnabled	Enable keyboard focusable scrollers

   

   

Chrome Enterprise Core changes
 

   

• Group based policies for connector configuration selection 

  Reporting connector configurations that receive events sent by managed browsers can now be configured by groups in addition to organizational units. 

  • Chrome 139 on ChromeOS, Linux,  macOS, Windows

  

  

   

   

• New remote commands and CSV export for the Managed profiles list 

  The Admin console will support profile-level "Clear cache" and "Clear cookies" remote commands, and CSV export for the Managed Profiles list. You can select one or multiple profiles and perform a remote command.

   
  • Chrome 137 on Android, Linux, macOS, Windows: Adding CSV export for Managed profiles. 
  • Chrome 139 on Linux, macOS, Windows: Profile-level support for remote commands. 
   

   

• New tab page cards for Microsoft 365 

  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 can enable the cards with NTPSharepointCardVisible and NTPOutlookCardVisible. For Microsoft tenants who do not allow for self-authorization, the admin must also consent to the app permissions during first authentication or approve the app for use in Microsoft Entra.

   
  • Chrome 134 on Linux, macOS, Windows: Available to Trusted Testers 
  • Chrome 137 on Linux, macOS, Windows:  Gradual rollout to all customers 
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Users do not need to be signed into Chrome to use this feature
   

  

  

   

• Regionalize covered Chrome Enterprise data 

  Starting in Chrome 139, Admins can use data regions to store users’ covered Chrome Enterprise data in a specific geographic location. The location options are United States, European Union (labeled Europe in the Google Admin console), or No preference. The initial migration will not complete until the end of Chrome 140. This can be set in the Google Admin console via Data > Compliance > Data regions > Region > Data at rest. For more information about the types of data covered, see the Chrome Enterprise Service Specific Terms.  

   
  • Chrome 139 on Android, iOS, ChromeOS, Linux,  macOS, Windows: Rollout will begin. Admins may be able to set a region; however, data may not be fully regionalized until the end of Chrome 140.
  • Chrome 140 on Android, iOS, ChromeOS, Linux,  macOS, Windows: The initial migration will be fully regionalized.
    

Chrome Enterprise Premium changes

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

   

• Active account detection   

  Chrome Enterprise can now detect whether an employee is using their corporate or personal Google account on Google Workspace pages like Google Drive, Docs, or Gmail. This allows administrators to create more granular Data Loss Prevention (DLP) rules to prevent sensitive data from being moved to personal accounts, addressing a critical data exfiltration risk. For instance, an administrator can now configure a policy in the Google Admin console to block a file upload to a personal Google Drive account while still allowing it to a corporate account. To use this feature, administrators should create or update their DLP rules to include the new Google Workspace Web app signed-in account condition. There is no single enterprise policy to enable or disable this feature; control is managed through the creation of these specific DLP rules.

   
  • Chrome 139 on ChromeOS, Linux,  macOS, Windows: The Chrome browser can detect the active user account on Google Workspace pages and sends this information as a new signal with Data Loss Prevention (DLP) scan requests.
   

   

• Chrome Enterprise Connectors API   

  Chrome Enterprise is introducing programmatic management for Chrome Enterprise Connectors. This update exposes connector settings as new and updated policies within the existing Chrome Policy API, allowing IT administrators and technology partners to manage these configurations at scale. Previously, this was a manual process in the Google Admin console. This update enables automation, which helps reduce manual errors and improve the efficiency of managing integrations with third-party security solutions.

  Administrators can use the Chrome Policy API to programmatically control settings for event reporting, content analysis, and real-time URL checks. This launch includes updates to the OnSecurityEventEnterpriseConnector policy and adds new policies such as OnFileAttachedEnterpriseConnector, OnFileDownloadedEnterpriseConnector, OnFileTransferEnterpriseConnector, OnBulkDataEntryEnterpriseConnector, OnPrintEnterpriseConnector, and EnterpriseRealTimeUrlCheckMode.

  For technical details, developers should refer to the main Chrome Policy API documentation 

   
  • Chrome 139 on Android, iOS, Linux,  macOS, Windows: This rollout adds support for programmatic management of Chrome Enterprise Connectors via a new API
   

   

• Copy and paste rules protection   

  To help organizations better prevent data exfiltration on mobile devices, Chrome is extending its existing desktop clipboard data controls. Administrators can now use the DataControlsRules policy to set rules that block or warn users when they attempt to copy or paste content that violates organizational policies. This feature allows admins to define data boundaries and prevent sensitive information from being pasted from a work context into personal apps or websites on their mobile fleet. This addresses a significant security gap and a frequently requested feature from enterprise customers who have cited the lack of mobile data controls as a concern. To use this feature, administrators can configure clipboard restrictions within the DataControlsRules policy, providing a consistent management experience across desktop and mobile to strengthen their organization's overall security posture.

   
  • Chrome 139 on Android: Copy and Paste rules protection becomes available on Android

   

• Data Loss Prevention support for iFrames   

  To enhance security and prevent data exfiltration, Chrome's Data Loss Prevention (DLP) capabilities are being extended to the content within iFrames. Currently, DLP rules configured by administrators do not apply to content inside an iFrame, which allows a potential security loophole where users can bypass restrictions. This feature closes that gap. With this change, when a user performs a DLP-triggering action (such as uploading a file) from a site loaded in an iFrame, Chrome will send the entire URL hierarchy, from the source iFrame up to the top-level page, to be evaluated against all applicable DLP rules.

   

  The motivation for this change is to provide a more robust security posture and eliminate a known method for bypassing data protection policies. No new enterprise policies are required to enable this functionality; it will work with existing DLP rules configured via the Connector policies. Administrators should be aware that their existing rules will now apply to iFrame contexts, which may block user actions that were previously permitted.

   
  • Chrome 139 on Linux,  macOS, Windows: Initial launch of Data Loss Prevention support for iFrames. This phase adds enforcement for file upload events originating from within an iFrame context and it will work with existing DLP rules configured via the OnFileAttachedEnterpriseConnector policy
  • Chrome 140 on Linux,  macOS, Windows: This expanded phase combines two feature rollouts, extending DLP iFrame support to include enforcement for both file download and printing  actions.

   

• Enable watermarking on Single Page Applications   

  To enhance data security, Chrome Enterprise Premium’s watermarking feature now supports Single Page Applications (SPAs). This addresses a significant customer request, as watermarks previously only applied to traditional websites. This capability is controlled by your existing Data Loss Prevention (DLP) policies in the Google Admin Console; no new policy configuration is required for this enhancement.

   

  IT administrators should be aware of a key technical limitation. SPAs utilize same-document navigations, which cannot be paused for a security scan like a standard page load. Consequently, there may be a brief delay before a watermark appears after navigating within an SPA. Additionally, DLP rules set to Warn or Block will not display an interstitial page for these SPA navigations; the action would only trigger on a full page reload.

   
  • Chrome 139 on ChromeOS, Linux,  macOS, Windows: This rollout adds support for watermarking on Single Page Applications (SPAs)
   

Upcoming Chrome browser changes

 

    

• 2SV enforcement for admins 

  To better protect your organization’s information, Google will soon require all accounts with access to admin.google.com to have 2-Step Verification (2SV) enabled. As a Google Workspace administrator, you need to confirm your identity with 2SV, which requires your password plus something additional, such as your phone or a security key.

  The enforcement will be rolled out gradually over the coming months. You should enable 2SV for the admin accounts in your organization before Google enforces it. For more information, see this About 2SV enforcement for admins.

   
  • Chrome 137 on ChromeOS, Linux, macOS, Windows: 2SV enforcement starts
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: 2SV mandatory
   

    

• Automated password change 

  When Chrome detects that a user has signed into a website with a known compromised password, it will offer the user to change it automatically. This feature will be available on a set of eligible sites. The feature uses AI, and can be controlled via the Enterprise policy AutomatedPasswordChangeSettings.

   
  • Chrome 140 on ChromeOS, Linux,  macOS, Windows

  

   

    

• Contextual search suggestions in Chrome Address bar 

  With this feature you can ask anything about the page you’re on, directly in context. Building on the existing Search habit of the address bar, users can ask a question with Google Lens by selecting anything on screen or asking with words. A Google Lens action in the address bar and contextual suggestions guide people to the feature when it’s most helpful. This feature is gated by the existing LensOverlaySettings policy.

   
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature starts rollout
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: If the LensOverlaySettings policy is not set this feature will respect the GenAiDefaultSettings policy if present.

  

    

• Enhanced autofill 

  Starting in Chrome 137, some users can turn on Autofill with AI, a new feature that helps users fill out online forms more easily. On relevant forms, Chrome can use AI to better understand the form and offer users to automatically fill in previously saved info. Admins can control the feature using the existing GenAiDefaultSettings policy and a new AutofillPredictionSettings policy.

   
  • Chrome 137 on ChromeOS, Linux,  macOS, Windows
  • Chrome 140 on ChromeOS, Linux,  macOS, Windows: The existing "Autofill with AI" feature will be renamed to "Enhanced autofill", allow users to save and fill additional types of info, and become available in more countries and languages.
   

    

• Gemini in Chrome 

  Gemini is now integrated into Chrome on macOS and Windows, and can understand the content of your current page. Users can now seamlessly get key takeaways, clarify concepts, and find answers, all without leaving their Chrome tab. This integration includes both chat—where users can interact with Gemini via text, and Gemini Live, with which users can interact with Gemini via voice.

  In Chrome 140, Gemini in Chrome will become available for users signed into Chrome in the US. Admins can turn off this feature (value 1) using the GeminiSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see Gemini in Chrome in the Help Center.

   
  • Chrome 137 on macOS, Windows: Feature is available for some Google AI Pro and Ultra subscribers in the US and on pre-Stable (Dev, Canary, Beta) channels in the US.
  • Chrome 140 on macOS, Windows: Feature gradually rolls out on Stable for users signed into Chrome in the US. 
   

    

• Happy Eyeballs V3 

  This launch is an internal optimization in Chrome that implements Happy Eyeballs V3 to achieve better network connection concurrency. Happy Eyeballs V3 performs DNS resolutions asynchronously and staggers connection attempts with preferable protocols (H3/H2/H1) and address families (IPv6 or IPv4) to reduce user-visible network connection delay. This feature is gated by a temporary policy HappyEyeballsV3Enabled.

   
  • Chrome 140 on Android, ChromeOS, Linux, macOS, Windows

    

• Launch Chrome into new profile via command line   

  This enhancement addresses a critical gap for our enterprise partners and admin who need to launch web applications from their native app catalogs directly into a specific managed Chrome profile using Chrome CLI (command line interface). Currently, if the designated profile does not exist, Chrome defaults to the last-used profile, creating a disjointed and insecure user experience. With this new feature, when a specified profile is not found, Chrome will initiate the existing profile creation flow, pre-populating the user's email address to streamline the setup process. This is a key technical enabler for admins aiming to onboard their enterprise users to Chrome Enterprise via Managed Profiles.

   
  • Chrome 140 on Linux,  macOS, Windows
   

    

• PostQuantum cryptography for DTLS in WebRTC 

  This feature enables the use of PostQuantum Cryptography (PQC) with WebRTC connections. The motivation for PQC is to get WebRTC media traffic up to date with the latest cryptography protocols and prevent Harvest Now to Crack Later scenarios. 

  This feature will be controllable by an enterprise policy WebRtcPostQuantumKeyAgreementEnabled,  to allow enterprise users to opt out of PQC. The policy will be temporary and is planned to be removed by Chrome 150.

   
  • Chrome 140 on Android, ChromeOS, Linux,  macOS, Windows, Fuchsia
  • Chrome 150 on Android, ChromeOS, Linux,  macOS, Windows, Fuchsia: Remove Enterprise Policy
   

    

• ServiceWorkerAutoPreload mode 

  ServiceWorkerAutoPreload is a mode where the browser issues the network request in parallel with the service worker bootstrap, and consumes the network request result inside the fetch handler if the fetch handler returns the response with respondWith(). If the fetch handler result is fallback, it passes the network response directly to the browser. ServiceWorkerAutoPreload is defined as an optional browser optimization, which will change the existing service worker behavior.

  A temporary enterprise policy called ServiceWorkerAutoPreloadEnabled will be added to control this feature.

   
  • Chrome 140 on Android, Windows: policy will be made available
  • Chrome 144 on Android, Windows: policy will be removed
   

    

• CSS find-in-page highlight pseudos 

  Exposes find-in-page search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the UA defaults have insufficient contrast with the page colors or are otherwise unsuitable.

   
  • Chrome 140 on Windows,  macOS, Linux, Android
   

    

• Deprecate special font size rules for H1 within some elements 

  The HTML spec contains a list of special rules for <h1> tags nested within <article>, <aside>, <nav>, or <section> tags. These special rules are deprecated, because they cause accessibility issues. Namely, they visually reduce the font size for nested <h1>s so that they "look" like <h2>s, but nothing in the accessibility tree reflects this demotion.

   
  • Chrome 140 on Windows,  macOS, Linux, Android
   

    

• IP protection 

  This feature limits availability of a user’s original IP address in third-party contexts in Incognito mode, enhancing Incognito's protections against cross-site tracking when users choose to browse in this mode. IP addresses facilitate a range of use cases, including routing traffic and preventing fraud and spam. However, they can also be used for tracking. For Chrome users who choose to browse in Incognito mode, we want to provide additional control over their IP address, without breaking essential web functionality. To strike this balance between protection and usability, this proposal focuses on limiting the use of IP addresses in a third-party context in Incognito mode. To that end, this proposal uses a list-based approach, where only domains on the Masked Domain List (MDL) in a third-party context will be impacted. For enterprises, this feature can be controlled via the PrivacySandboxIpProtectionEnabled enterprise policy.

   
  • Chrome 140 on Windows, macOS, Linux, Android
   

    

• Local network access restrictions 

  Chrome 140 restricts the ability to make requests to the user's local network, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (for example,. intranet) to loopback. Gating the ability for websites to perform these requests behind a permission mitigates the risk of cross-site request forgery attacks against local network devices such as routers, and reduces the ability of sites to use these requests to fingerprint the user's local network.

  This permission is restricted to secure contexts. If granted, the permissions additionally relaxes mixed content blocking for local network requests (since many local devices are not able to obtain publicly trusted TLS certificates for various reasons).

  This work supersedes a prior effort called Private Network Access, which used preflight requests to have local devices opt-in. Enterprises that need to disable or auto-grant the permission can do so using the LocalNetworkAccessAllowedForUrls and LocalNetworkAccessBlockedForUrls policies. The value of '*' can be used to allow local network access on all URLs, matching the behavior prior to rolling out the restrictions.

   
  • Chrome 140 on Windows,  macOS, Linux, Android

    

• Probabilistic Reveal Tokens 

  To ensure that all businesses can continue to estimate the amount of fraud on their systems, train models to defend against fraud, and analyze emerging fraudulent behavior while still mitigating the ability to track users at scale using IP addresses, we propose to introduce a delayed IP sampling mechanism called Probabilistic Reveal Tokens (PRTs) alongside IP Protection for use in protected traffic.

  PRTs will be included on proxied requests in a new HTTP header added by the browser for domains that indicate they want to receive them via a signup process. Each PRT will contain a ciphertext, generated by an Issuer and re-randomized for unlinkability by the browser prior to the request, that the recipient can decrypt after a delay. Google will be the issuer for Chrome's implementation. A minority of the decrypted PRTs contain the client's pre-proxy IP address (that is, non-masked, and as observed by the token issuer), while the remaining PRTs provide no information about the client's original IP address. This results in only a small percent of PRTs containing and revealing the user's IP. Since PRTs will only be attached when IP Protection is enabled, admins can use the PrivacySandboxIpProtectionEnabled policy to control IP Protection and PRTs.

   
  • Chrome 140 on Windows,  macOS, Linux, Android
   

    

• Propagate Viewport overscroll-behavior from Root 

  This feature will propagate overscroll-behavior from the root instead of the body. The CSS working group resolved on not propagating properties from the body to the viewport. Rather, properties of the viewport are to be propagated from the root element e.g. scroll-behavior, scroll-snap-type, scroll-padding. As such, overscroll-behavior should be propagated from the root element. However, Chrome has had a longstanding issue of propagating overscroll-behavior from the body rather than the root, which deviates from the behavior of Safari(WebKit) and Firefox(Gecko). This feature intends to fix this by propagating overscroll-behavior from the root rather than the body.

   
  • Chrome 140 on Windows,  macOS, Linux, Android

    

• Script blocking in Incognito 

  Mitigating API Misuse for Browser Re-Identification, otherwise known as Script Blocking, is a feature that will block scripts engaging in known, prevalent techniques for browser re-identification in third-party contexts. These techniques typically involve the misuse of existing browser APIs to extract additional information about the user's browser or device characteristics.

  This feature uses a list-based approach, where only domains marked as “Impacted by Script Blocking” on the Masked Domain List (MDL) in a third-party context will be impacted. When the feature is enabled, Chrome will check network requests against the blocklist. The Chromium's subresource_filter component will be reused, which is responsible for tagging and filtering subresource requests based on page-level activation signals, and a ruleset is used to match URLs for filtering. The enterprise policy name is PrivacySandboxFingerprintingProtectionEnabled.

   
  • Chrome 140 on Windows,  macOS, Linux, Android

    

• SharedWorker script inherit controller for blob script URL 

  According to Worker client case (github), 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 140 on Windows,  macOS, Linux, Android

    

• Strict Same Origin Policy for Storage Access API 

  We plan to adjust the Storage Access API semantics to strictly follow the Same Origin Policy, to enhance  security. Using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default. The CookiesAllowedForUrls policy or Storage Access Headers can still be used to unblock cross-site cookies.

   
  • Chrome 140 on Windows, macOS, Linux, Android
   

    

• Web App Manifest: specify update eligibility, icon URLs are Cache-Control: immutable 

  As early as Chrome 139, the Web App manifest will specify an update eligibility algorithm. This makes the update process more deterministic and predictable, giving the developer more control over whether (and when) updates should apply to existing installations, and allowing removal of the 'update check throttle' that user agents currently need to implement to avoid wasting network resources.

   
  • Chrome 141 on Windows, macOS, Linux
  • Chrome 142 on Android
   

    

• Clear window name for cross-site navigations that switches browsing context group 

  The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, which can leak information and potentially be used as a tracking vector. Clear the window.name property in this case addresses this issue. 

  This update will introduce a new temporary enterprise policy, ClearWindowNameCrossSiteBrowsing, which will stop working in Chrome 146.

   
  • Chrome 142 on Windows, macOS, Linux, Android, iOS
   

    

• Disallow non-trustworthy plaintext HTTP prerendering 

  This launch will provide the capability to disallow non-trustworthy plaintext HTTP prerendering.

   
  • Chrome 142 on Windows, macOS, Linux, Android

    

• HSTS tracking prevention 

  This update will mitigate user tracking by third-parties via the HTTP Strict Transport Security (HSTS) cache. This feature only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. Doing so makes it infeasible for third-party sites to use the HSTS cache in order to track users across the web.

   
  • Chrome 142 on Windows, macOS, Linux, Android
   

    

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

  According to the URL Standard specification, 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 (Github).

   
  • Chrome 145 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, Fuchsia

    

• Remove Third-party storage partitioning policies 

  Third-party storage partitioning became the default in Chrome 115. The chrome:// flag that allowed users to disable this feature was removed in Chrome 128, and the deprecation trial ended with Chrome 139. In Chrome 145, the enterprise policies DefaultThirdPartyStoragePartitioningSetting and ThirdPartyStoragePartitioningBlockedForOrigins will be removed. Users are advised to transition to alternative storage solutions, either by adapting to third-party storage partitioning or by using  document.requestStorageAccess({...}) where needed.

  If you have any feedback, you can add it here in the Chromium bug.

   
  • Chrome 145 on Android, ChromeOS, Linux,  macOS, Windows, Fuchsia: Removal of DefaultThirdPartyStoragePartitioningSetting and ThirdPartyStoragePartitioningBlockedForOrigins

    

• SafeBrowsing API v4 → 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. For more details, see Migration From V4 - Safe Browsing. 

   
  • Chrome 145 on Android, iOS, ChromeOS, Linux, macOS, Windows: Feature would gradually roll-out 

    

• 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 that 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 the explainer. 

  In this initial release, IWAs will only be installable through an admin policy on enterprise-managed ChromeOS devices.

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

    

• 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 may use the UiAutomationProviderEnabled enterprise policy starting in 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 146, and will be removed in Chrome 147. 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 146.
  • Chrome 147 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 updates

 

    

• Inactive profile deletion in Chrome Enterprise Core 

  In June 2025, the inactive period for profile deletion setting started to roll out. In August 2025, the setting will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. When releasing the setting, the inactivity period of time has a default value of 90 days. Meaning that by default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this setting. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If  the set value is lowered, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is reactivated on a device, that profile will reappear in the console.

   
  • Chrome 140 on Android, ChromeOS, Linux,  macOS, Windows: Policy was rolled out in June. Deletion will start in August and the initial wave of deletion will complete by the beginning of September. After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.
   

    

• Chrome Enterprise Overview page 

  This feature is introducing a new Overview page in the Chrome browser section of the Google Admin console. The Overview page allows IT administrators to quickly find key information about their deployment:

  - Active & inactive profiles and enrolled browsers

  - Identify browsers out-of-date and with pending updates

  - Identify high-risk extensions (according to Spin.AI) and get a preview of most requested extensions

  - Security Insights (for example, sensitive file uploads or downloads)

  The Overview page also allows admins to quickly access key actions such as managing extensions, accessing the browser or profile list and setting Update policies, to name a few.

   
  • Chrome 137 on Android, iOS, Linux, macOS, Windows
  • Chrome 141 on Android, iOS, Linux, macOS, Windows: New filtering available on the Overview page for Organization Unit and Activity Dates

   

Upcoming Chrome Enterprise Premium changes

   

• Increased file size support for Data Loss Prevention scans 

  Chrome Enterprise Premium now extends its Data Loss Prevention (DLP) and malware scanning capabilities to include large and encrypted files. Previously, files larger than 50 MB and all encrypted files were skipped during content scanning. This update closes that critical security gap. For policies configured to save evidence, files up to 2GB can now be sent to the Evidence Locker. This provides administrators with greater visibility and control, significantly reducing the risk of data exfiltration through large file transfers.

  No new policy is required to enable this feature. It is automatically controlled by the existing DLP rule configurations in the Google Admin Console. If admins have rules that apply to file uploads, downloads, or printing, they will now also apply to large and encrypted files.

   
  • Chrome 140 on Linux,  macOS, Windows: Feature is rolled out
   

   

• Watermarking customization 

  Chrome Enterprise Premium now allows administrators to customize the appearance of watermarks. This enhancement is motivated by the need to improve user experience, addressing concerns such as eyestrain and readability on pages with existing watermarks.

  To control the watermark's appearance, administrators should use the new WatermarkStyle policy. Within this policy, admins can configure the following:

  • 'font_size': Sets the font size of the text in pixels. 
  • 'fill_opacity': Sets the fill opacity of the text, from 0 (transparent) to 100 (opaque). 
  • 'outline_opacity': Sets the outline opacity of the text, from 0 (transparent) to 100 (opaque). 

  This provides administrators with greater flexibility to balance security requirements with end-user productivity.

   
  • Chrome 140 on ChromeOS, Linux,  macOS, Windows: This launch enables administrators to customize watermark font size and opacity using the new WatermarkStyle policy in the Google Admin Console.
  • Chrome 141 on ChromeOS, Linux,  macOS, Windows: As an enhancement, a new chrome:// enterprise page is introduced that allows administrators to preview their configured watermark style before deployment.
   

   

• Chrome browser rule UX refactor 

  To enhance the Data Loss Prevention (DLP) rule creation experience, the Google Admin console is being updated to streamline how administrators define policies for different applications like Chrome and Workspace. This first introduces mutually exclusive application groups, meaning that a single DLP rule can now only target one application group at a time—either Workspace apps (like Drive, Gmail), Chrome browser triggers (like file upload, URL visited), or ChromeOS triggers. This change simplifies rule configuration, eliminates potential conflicts from overlapping app selections, and lays the groundwork for more specialized and user-friendly workflows tailored to each platform's needs.

  Administrators will see an updated "Apps" selection interface using radio buttons to enforce this single-group selection for new rules. Existing rules that previously combined applications from multiple groups will be transparently migrated by the system into separate, compliant, single-platform rules to ensure continued protection and a seamless transition. Banners within the Admin console will provide information regarding these changes and the migration process. No new enterprise policies are introduced with this update; the changes are to the rule configuration interface.

   
  • Chrome 141 on ChromeOS, Linux,  macOS, Windows: Enables mutually exclusive app selection for DLP rule configuration in Admin Console
   

ChromeOS 139 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
ChromeOS desk sync		✓
Chrome apps changes	✓		✓
Native Client (NaCl) deprecation	✓		✓
Touchscreen calibration tool		✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Chrome Sign Builder Deprecation		✓	✓
EAP/TLS server certificate validation	✓		✓

 

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 desk sync 

  Starting from ChromeOS 139, ChromeOS desk sync helps users quickly pick up from where they left off when switching to another device. Desk sync restores all windows, tabs, and even cookies from the previous session to allow for a seamless transition. Admins can switch on this feature for managed users. Desk sync is particularly useful for shared devices and frontline workers in healthcare, hospitality, and manufacturing settings. For more details, see our blog post or our help center. 

  
  

   

• Chrome apps changes 

  Starting with ChromeOS 139, planned for stable release on August 19th, user-installed Chrome apps on ChromeOS will stop working. Apps that are force-installed through the admin console for Managed Guest sessions (MGS) and user sessions will continue to be supported. For more details, see End of support for Chrome apps.

  A new policy, KioskChromeAppsForceAllowed, is available for administrators to re-enable Chrome apps in kiosk sessions. With this policy turned on, Chrome apps in kiosk sessions will be supported through ChromeOS 150.

   

• Native Client (NaCl) deprecation 

  ChromeOS 139 and later no longer supports Native Client (NaCl) in managed environments with the NaCl allow policy enabled. For devices on the Long-term Support (LTS) channel with this policy active, NaCl support will continue to be supported until the ChromeOS 138 LTS Last Refresh in April 2026.

   

• Touchscreen calibration tool 

  With ChromeOS 139, you can now calibrate boundaries of external touch screen displays. Chromebook users can now calibrate boundaries of external touch screen displays connected to a Chromebook. This setting helps with aligning external display boundaries, so that touch inputs correspond correctly to the displayed content. To calibrate the external touch screen display, go to Settings > Device > Display, go to the corresponding external touchscreen display and access Calibrate touchscreen. For more details, see Connect your Chromebook to a monitor.

Upcoming ChromeOS changes

   

• Chrome Sign Builder deprecation 

  The Chrome Sign Builder Chrome App is scheduled to reach its end of life in July 2026, with ChromeOS M150 being the final release to support it in kiosk mode. Devices on the Long-term Support (LTS) channel will continue to receive support until April 2027. This deprecation means that after the specified timelines, Chrome Sign Builder will no longer be available for installation or configuration, potentially leading to service disruptions for organizations currently utilizing it for digital signage.

  To avoid any interruptions, organizations must migrate to an alternative solution before July 2026. Two recommended options are

  • Migrate to Comeen: A Chrome Enterprise Recommended Partner that offers a web app replacement (comeen.com)

  • Deploy alternative web apps: Utilize the Google Admin console to deploy other web apps to ChromeOS kiosk devices.

   

• EAP/TLS server certificate validation 

  Note: This change only affects customers utilizing EAP/TLS network setups and only affects networks set up before January of 2022.

  Starting October 1, 2025, we will roll out this fix to the ChromeOS stable channel. A very small number of customers using EAP/TLS configurations might experience connectivity issues if their server certificates are signed by a Certificate Authority (CA) that is currently included in ChromeOS as a System CA.

  To minimize disruption, admins can perform one of the following actions:

  Option 1 (providing a higher level of security):

  1. Generate a new certificate for your Authentication Server, and ensure it is signed by the same Certificate Authority (CA) as used previously.
  2. Replace the existing certificates on your Authentication Server with the newly-generated certificates.
   

  Option 2 ( if more time is needed before implementing Option 1):

  1. Sign in to Google Admin console.

  2. From August 15 to October 1, to check for affected devices, admins can follow these instructions on the Beta channel:

     • Access chrome://histograms in Chrome browser.
     • Perform several disconnect and reconnect cycles for your Ethernet or Wi-Fi network.
     • Allow approximately 10 seconds for data aggregation.
     • Within the chrome://histograms page, search the histogram identified as Network.Shill.Eap.EventCaCertExperiment1:
       1. If the histogram is not present, your configuration is not impacted.
       2. Your configuration is likely to be impacted if a positive value is observed for both Event 8 (FirstCertVerificationFailure) and Event 9 (CertVerificationRetryAttempt).
  3. Navigate to the configuration settings for the affected EAP/TLS network.
  4. Modify the Server Certificate Authority setting to System default certificate authorities.

Chrome 138 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
AI Mode for search recommendations in Chrome		✓
Bookmarks and reading list improvements on Chrome Desktop	✓	✓
Client’s LLM assistance in mitigating scams	✓
Contextual search suggestions in Chrome Address bar		✓
Enhanced Safe Browsing is a synced setting	✓
Generating insights for Chrome DevTools console warnings and errors			✓
History sync opt-in via profile pill	✓
New tab page footer	✓	✓	✓
Per-extension user script toggle	✓
Removal of Private Network Access enterprise policies	✓
Search your screen with Google Lens on iPad		✓
Shared tab groups		✓
Speculation rules prefetch for ServiceWorker		✓
TLS 1.3 Early Data		✓
Deprecate asynchronous range removal for Media Source extensions	✓
Language Detector API		✓
Summarizer API		✓
Translator API		✓
Web serial over Bluetooth on Android		✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Agentspace recommendations in the Chrome search bars		✓	✓
Deprecation of the Chrome browser page on the Chrome Insights report			✓
Inactive profile deletion in Chrome Enterprise Core	✓		✓
New LayerX risk assessment in the Admin console	✓
Multiple identity support on iOS		✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
SecOps integration	✓		✓
URL Filtering capabilities on iOS	✓		✓
DLP download support for File System Access API (FSA)	✓		✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Chrome on Android no longer supports Android Oreo or Android Pie			✓
Gemini in Chrome		✓
Malicious APK download checks	✓
Upcoming change for CA certificates included in the Chrome Root Store	✓
Migrate extensions to Manifest V3 before June 2025	✓	✓	✓
Promotional notifications			✓
Remove risky extension flags in Google Chrome	✓
Remove SwiftShader fallback	✓
Support accounts in pending state on Chrome iOS	✓
Chrome to remove support for macOS 11		✓
Clear window name for cross-site navigations that switches browsing context group			✓
Fire error event instead of throwing for CSP blocked worker			✓
Web App Manifest: specify update eligibility, icon urls are Cache-Control: immutable		✓
2SV enforcement for admins			✓
Happy Eyeballs V3		✓
Isolated Web Apps		✓
Disallow non-trustworthy plaintext HTTP prerendering	✓
HSTS tracking prevention	✓
IP Protection	✓
Strict Same Origin Policy for Storage Access API	✓	✓
Disallow spaces in non-file:// URL hosts			✓
SafeBrowsing API v4 → v5 migration	✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
New remote commands and CSV export for the Managed Profile list			✓
New tab page cards for Microsoft 365		✓	✓
Chrome Enterprise Overview page			✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
Chrome browser rule UX refactor	✓		✓
Copy and paste rules protection	✓		✓

 

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  

   

• AI Mode for search recommendations in Chrome 

  AI Mode is a feature that helps users dive deeper into topics they care about by showing AI Mode for search recommendations in Chrome. A new policy, AIModeSettings, is available to control search recommendations in the address bar and New tab page search box. 

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature starts rollout in the address bar.
  • Chrome 139 on Android, iOS: Feature starts rollout in the address bar.
   

  

  

  

   

 

   

• Bookmarks and reading list improvements on Chrome Desktop 

  For Chrome 138 on Desktop, some users who sign in to Chrome upon saving a new bookmark can now use and save bookmarks and reading list items in their Google Account. Relevant enterprise policies controlling bookmarks, as well as BrowserSignin, SyncDisabled or SyncTypesListDisabled, continue to work as before, so admins can configure whether or not users can use and save items in their Google Account. Setting EditBookmarksEnabled to false also prevents users from uploading a bookmark saved on their device to their Google Account.  

  • Chrome 138 on Linux, macOS, Windows
   

   

• Client’s LLM assistance in mitigating scams 

  Users on the web are facing significant amounts of different kinds of scams a day. To combat these scams, Chrome now uses on-device LLM to identify scam websites for Enhanced Safe Browsing users. Chrome sends the page content to an on-device LLM to infer security-related signals of the page and send these signals to the Safe Browsing server for a final verdict. When enabled, Chrome can consume more bandwidth to download the LLM. 

  Enhanced Safe Browsing is an existing feature, controlled by the SafeBrowsingProtectionLevel policy.

  • Chrome 134 on Linux, macOS, Windows: Gather the brand name and intent summary of the page that triggers keyboard lock to identify scam websites.
  • Chrome 135 on Linux, macOS, Windows: Show the warnings to the user based on the server verdict, which uses the brand and intent summary of the page that triggered keyboard lock.
  • Chrome 137 on Linux, macOS, Windows: Gather brand and intent summary of the page based on server reputation scoring system.
  • Chrome 138 on Linux, macOS, Windows: Show the warnings to the user based on the server verdict, which uses the brand and intent of the pages that the server reputation system scored.

 

   

• Contextual search suggestions in Chrome Address bar 

  With this feature you can ask anything about the page you’re on, directly in context. Building on the existing Search habit of the address bar, users can ask a question with Google Lens by selecting anything on screen or asking with words. A Google Lens action in the address bar and contextual suggestions guide people to the feature when it’s most helpful. This feature is gated by the existing LensOverlaySettings policy.

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature starts rollout
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: If the LensOverlaySettings policy is not set this feature will respect the GenAiDefaultSettings policy if present.
  

 

   

• Enhanced Safe Browsing is a synced setting 

  In Chrome 138, Chrome's Enhanced Safe Browsing is a synced feature. This means that if a user opts into Enhanced Safe Browsing on one device, this protection level automatically applies across all other devices where they are signed into Chrome with the same account. The goal is to provide stronger, more consistent security protection and a standardized user experience.

  Users who enable Enhanced Safe Browsing benefit from its protections, for example, proactive phishing protection, improved detection of malware and malicious extensions consistently across their synced Chrome instances on Desktop (Windows, macOS, Linux, ChromeOS), Android, and iOS. Users receive onscreen notifications when their Enhanced Safe Browsing setting is synced.

  The Safe Browsing protection level is an existing feature, controlled by the SafeBrowsingProtectionLevel policy.

  • Chrome 138 on Android, 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 available to users (18+) in English only. Admins can control this feature using the DevToolsGenAiSettings policy.

  • 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.
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: The AI assistance panel exposes an internal API that simplifies the use of AI assistance panel features by external tools such as Model Context Protocol (MCP) servers.

 

   

• History sync opt-in using the profile pill 

  In Chrome 138, some signed-in users see a new option to opt in to history and tab sync. This change is designed to offer the benefits of history sync in a non-disruptive way by using the profile pill to display a short in-line message. Users who click on the profile pill are taken to their profile menu where they can choose to turn on sync. The goal is to provide users with an intuitive and contextually relevant entry point for syncing data like browsing history, separate from the sign-in flow. For Enterprise users, the expanded profile pill only appears after 4 hours of browser inactivity. 

  Relevant enterprise policies controlling History or Tab sync (SyncDisabled, SyncTypesListDisabled and SavingBrowserHistoryDisabled) continue to work as before.

  • Chrome 138 on Linux, macOS, Windows: Feature starts gradual rollout.
   

  

 

   

• New tab page footer 

  An update to the New tab page includes a new footer designed to provide users with greater transparency and control over their Chrome experience.

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Extension Attribution will begin to show on the NTP. If an extension has changed your default New tab page, you'll now see a message in the footer that attributes the change to that specific extension. This message often includes a link directly to the extension in the Chrome Web Store, making it easier to identify and manage unwanted extensions. If you're an administrator, you can disable this attribution using the NTPFooterExtensionAttributionEnabled policy.
  • Chrome 139 on Linux, macOS, Windows: Browser management disclosure will be shown if one of the policies to customize the footer is set by an enterprise admin. For users whose Chrome browser is managed by a trusted source, the New tab page footer will now display a management disclosure notice. This helps you understand how your browser is being managed. Administrators can disable this notice with the NTPFooterManagementNoticeEnabled policy. Additionally, organizations can customize the footer's appearance using the EnterpriseLogoUrlForBrowser and EnterpriseCustomLabelForBrowser policies to display a custom logo and label.
  • Chrome 140 on Linux, macOS, Windows: A default notice (Managed by <domain name>) will start to be shown in the New tab page footer for all managed browsers. Visibility can be changed with the NTPFooterManagementNoticeEnabled policy. 
   

 

   

• Per-extension user script toggle 

  In Chrome 138, the way that users and administrators control an extension’s ability to run user created scripts and use the userScripts API is changing. This change enhances security. Users won’t unintentionally grant user script permissions to every extension when enabling Developer mode by explicitly deciding which extensions can run these potentially powerful scripts. For more detail on the motivation for the change, see this Chrome for developers blog.

  End users will now toggle this per extension on the chrome://extensions page via a Allow User Scripts toggle, replacing the global Developer mode toggle for more granular control. Existing extensions will have this toggle automatically enabled if Developer mode is on and the extension has been granted the User Scripts permission.

  Administrators who currently manage user scripts by disabling developer mode should now use the blocked_permissions field of the ExtensionSettings policy or the Google Admin console to independently control the User Scripts permission and extension Developer mode.

  Extension developers are advised to update their documentation to reflect the new toggle. See the Chromium Extensions Google Groups mailing list for more information and other changes to usage of the API.

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature rolls out
   

 

   

• 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) (Github). 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 immediately. 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.

  • Chrome 135 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Deprecate InsecurePrivateNetworkRequestsAllowedForUrls, InsecurePrivateNetworkRequestsAllowed, and PrivateNetworkAccessRestrictionsEnabled policies.
  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Removal of PrivateNetworkAccessRestrictionsEnabled, InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed. There should be a PNA2 replacement policy available in Chrome 138.

 

   

• Search your screen with Google Lens on iPad 

  Expand Search your screen with Google Lens on iOS so it is available on iPad devices. iPad is a form factor typically associated with more complex tasks, for example, shopping, and expanding Lens functionality on iPad enables users to perform these tasks easily. Admins can control this feature using the LensOverlaySettings policy. 

  • Chrome 138 on iOS: Feature rolls out gradually.

 

   

• Shared tab groups 

  Users can now collaborate on tabs using the shared tab groups feature. With this feature, users can create and use a set of tabs on their desktop or mobile device and their collaborative partners can browse the same tabs on their devices. When one person changes a tab in the group, the changes are reflected across all users’ browsers in the group. An enterprise policy, TabGroupSharingSettings, is available to control this feature.

  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Rollout of the ability to join and use a shared tab group. Users on Stable Chrome will not be able to create a shared tab group (the entry point will not be available) - this part of the feature will only be available on Beta/Dev/Canary for this phase of rollout. 
  • Chrome 139 on iOS:  As early as Chrome 139, support for iOS will roll out.

 

   

• Speculation rules prefetch for ServiceWorker 

  This feature enables Service Worker-controlled prefetches, that is, a speculation rules prefetch to URLs controlled by a Service Worker. Previously, the prefetch is cancelled upon detecting a controlling Service Worker, thus subsequent navigation to the prefetch target is served by the non-prefetch path. This feature enables the prefetch request to go through the Service Worker's fetch handler and the response with the Service Worker interception is cached in the prefetch cache, resulting in a subsequent navigation being served by the prefetch cache. Please use the enterprise policy PrefetchWithServiceWorkerEnabled to control this feature. For more details, see this explainer.

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

 

   

• TLS 1.3 Early Data 

  TLS 1.3 Early Data allows GET requests to be sent during the handshake when resuming a connection to a compatible TLS 1.3 server. The feature is expected to demonstrate performance improvements and will be available in Chrome 138 with a policy (TLS13EarlyDataEnabled) to control this change.

  TLS 1.3 Early Data is an established protocol. Existing TLS servers, middleboxes, and security software are expected to either handle or reject TLS 1.3 Early Data without dropping the connection. However, devices that do not correctly implement the TLS standard (RFC8446) might malfunction and disconnect when TLS 1.3 Early Data is in use. If this occurs, administrators should contact the vendor for a fix.

  The TLS13EarlyDataEnabled policy is a temporary measure to control the feature and will be removed in a future milestone. You can turn on the feature using the policy to allow you to test for issues and turn it off again as issues are resolved.

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

 

   

• Deprecate asynchronous range removal for Media Source extensions 

  The Media Source standard changed in the past to disallow ambiguously-defined behavior involving asynchronous range removals:

  • SourceBuffer.abort() no longer aborts SourceBuffer.remove() operations
  • Setting MediaSource.duration can no longer truncate currently buffered media
   

  Exceptions are thrown in both of these cases now. Safari and Firefox have long shipped this behavior; Chromium is the last browser remaining with the old behavior. Use counters show ~0.001%-0.005% of page loads hit the deprecated behavior. If a site hits this issue, playback may now break. Usage of abort() cancelling removals is increasing, so it's prudent to resolve this deprecation before more incompatible usage appears.

  • Chrome 138 on Windows, macOS, Linux, Android

 

   

• Language Detector API 

  Language Detector API is a JavaScript API for detecting the language of text, with confidence levels. An important supplement to translation is language detection. This can be combined with translation, for example, taking user input in an unknown language and translating it to a specific target language. Browsers today often already have language detection capabilities, and we want to offer them to web developers through a JavaScript API, supplementing the translation API. An enterprise policy, GenAILocalFoundationalModelSettings, is available to disable the underlying model downloading, which would render this API unavailable.

  • Chrome 138 on Windows, macOS, Linux

 

   

• Summarizer API 

  Summarizer API is a JavaScript API for producing summaries of input text, backed by an AI language model. Browsers and operating systems are increasingly expected to gain access to a language model. By exposing this built-in model, we avoid every website needing to download their own multi-gigabyte language model, or send input text to third-party APIs. The Summarizer API, in particular, exposes a high-level API for interfacing with a language model to summarize inputs for a variety of use cases (Github), in a way that does not depend on a specific language model. 

  An enterprise policy (GenAILocalFoundationalModelSettings) is available to disable the underlying model downloading, which would render this API unavailable.

  • Chrome 138 on Windows, macOS, Linux

 

   

• Translator API 

  Translator API is a JavaScript API to provide language translation capabilities to web pages. Browsers are increasingly offering language translation to their users. Such translation capabilities can also be useful to web developers. This is especially the case when the browser's built-in translation abilities cannot help. An enterprise policy, GenAILocalFoundationalModelSettings, is available to disable the underlying model downloading, which would render this API unavailable.

  • Chrome 138 on Windows, macOS, Linux

 

   

• Web serial over Bluetooth on Android 

  This feature allows web pages and web apps to connect to serial ports over Bluetooth on Android devices. Chrome on Android now supports Web Serial API over Bluetooth RFCOMM. Existing enterprise policies (DefaultSerialGuardSetting, SerialAllowAllPortsForUrls, SerialAllowUsbDevicesForUrls, SerialAskForUrls and SerialBlockedForUrls) on other platforms are enabled in future_on states for Android. All policies except SerialAllowUsbDevicesForUrls will be enabled after the feature is enabled. SerialAllowUsbDevicesForUrls will be enabled in a future launch after Android provides system level support of wired serial ports.

  • Chrome 138 on Android

 

   

• New policies in Chrome browser 

  Policy	Description
  AIModeSettings	Settings for Google's AI Mode integrations in the address bar and New Tab page search box.
  PdfAnnotationsEnabled	Enable PDF Annotations.
  TLS13EarlyDataEnabled	Enable TLS 1.3 Early Data.
  NTPFooterExtensionAttributionEnabled	Control the visibility of the extension attribution on the New tab page
  PrefetchWithServiceWorkerEnabled	Allow SpeculationRules prefetch to ServiceWorker-controlled URLs.
  EnterpriseRealTimeUrlCheckMode	Check Safe Browsing status of URLs in real time.
  LocalNetworkAccessRestrictionsEnabled	Apply restrictions to requests to local network endpoints.
  PrivacySandboxIpProtectionEnabled	Choose whether the IP Protection feature should be enabled.
  PasswordManagerBlocklist	Configure the list of domains for which the Password Manager will be disabled.

   

• Removed policies in Chrome browser 

  Policy	Description
  PrivateNetworkAccessRestrictionsEnabled	Apply restrictions to requests to more-private network endpoints.
  InsecurePrivateNetworkRequestsAllowed	Allow websites to make requests to more-private network endpoints in an insecure manner.
  InsecurePrivateNetworkRequestsAllowedForUrls	Allow the listed sites to make requests to more-private network endpoints in an insecure manner.

   

   

Chrome Enterprise Core changes

   

• Agentspace recommendations in Chrome search bars 

  To help enterprise users with their internal information needs, you can now add enterprise search results, such as people, file, or query suggestions, from Agentspace to the Chrome address bar and realbox (search bar on the New tab page). Results can be shown by default or only when triggered by a custom keyword. 

  With keyword mode in the address bar, users can trigger actions through Agentspace, such as, "help me write an email that summarizes the current project status". 

  The enterprise search provider is shown when the user types @ in the address bar. The organization can customize a keyword or shortcut and the icon shown. 

  This can be configured via the EnterpriseSearchAggregatorSettings policy. 

  • Chrome 135 on ChromeOS, Linux, macOS, Windows: Trusted Tester
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: General Availability
   
   

   

• Deprecation of the Chrome browser page on the Chrome Insights report 

  As early as July 1st, the Chrome browser page on the Chrome Insights report will be deprecated. This page is replaced by the Chrome Overview page that was launched in Chrome 137. The information, which was displayed on the Chrome browser page of the Chrome Insights report, can now be found on the Overview page.

  • Chrome 138 on Android, iOS, Linux, macOS, Windows
  

   

• Inactive profile deletion in Chrome Enterprise Core 

  In June 2025, the inactive period for profile deletion setting started to roll out. In July 2025, the setting will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. The inactivity period of time has a default value of 90 days. By default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this setting. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If you lower the set value, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is re-activated on a device, that profile will reappear in the console.

  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Policy will roll out in June. Deletion will start in July and the initial wave of deletion will complete by the end of August. After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.

   

• New LayerX risk assessment in the Admin console 

  We are adding a new extension risk assessment provider: LayerX Security to the Admin console. This score is available to Admins in the Apps and Extensions Usage report. 

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: The score would be available to admins as early as Chrome 138.  
   

   

• Multiple identity support on iOS 

  Chrome on iOS now supports multiple accounts, particularly for managed (work or school) accounts. This update introduces separate browser profiles for each managed account, ensuring strict data separation between work and personal browsing. Regular accounts continue to share a single profile. 

  This change aims to improve Chrome's enterprise offering and provide a more secure and organized browsing experience, especially for end users with both personal and work accounts on their device. Users experience a one-time onboarding flow when adding a managed account to the device. They can switch between accounts by tapping on the account particle disk on the New tab page. 

  Admins who enabled Chrome policies on iOS (see instructions) can continue to use existing policies. 

  • Chrome 138 on iOS 
   

Chrome Enterprise Premium changes

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

   

• SecOps integration   

  This feature delivers a native integration between Chrome Enterprise Premium (CEP) and Google Security Operations (SecOps), enabling organizations to send a richer set of security events and detailed browser telemetry from Chrome directly to their SecOps instance. The motivation for this change is to use the browser as a primary security sensor for web-based threats like phishing, malware, and data exfiltration. This can significantly improve an organization's ability to: 

  • prevent
  • detect
  • investigate
  • and respond to web-based threats.
   

  For administrators, this integration introduces new, enhanced security event types, including URL navigation telemetry and suspicious URL visits. These events are automatically enriched with Safe Browsing risk scores and other threat intelligence before being sent to SecOps. The launch also includes a new, streamlined "one-click" setup process in the Admin console to replace the previous manual workflow, simplifying the connection to SecOps.

  To use this feature, administrators must have a Chrome Enterprise Premium subscription and will need to enable the integration through the new workflow in the Admin console. The collection of certain high-volume event types, such as URL navigation events, is an opt-in setting within the connector configuration. This feature does not add or modify any enterprise policies.

  • Chrome 137 on Linux, macOS, Windows: Adds referrer data to URLFilteringInterstitialEvent and SafeBrowseInterstitialEvent
  • Chrome 138 on Linux, macOS, Windows: Extends referrer data population to SafeBrowseDangerousDownloadEvent and DlpSensitiveDataEvent
   

   

• URL Filtering capabilities on iOS   

  The current WebProtect URL Filtering capabilities on Desktop are being extended to mobile so that organizations can audit, warn, or block certain URLs or categories of URLs from loading on managed Chrome browsers or managed user profiles on mobile devices. This feature is part of Chrome Enterprise Premium and aims to provide secure and safe internet access for enterprise users on any device. Admins can create URL filtering rules to ensure that employees can only access safe and authorized URLs on iOS devices. Chrome reports URL filtering events and unsafe site events via the Reporting Connector on mobile. This feature allows administrators to manage which URLs can be accessed on managed Chrome browsers or profiles on company-owned or BYOD iOS devices. 

  Key changes include:

  - Admins can block, warn, or audit users when accessing certain sites or categories.    

  - Users see interstitial pages when attempting to visit blocked or warned URLs.    

  - Chrome reports URL filtering events.    

  - Updates to the chrome://management page reflect the new functionality.

  • Chrome 138 on iOS: The URL Filtering feature becomes available on iOS.
   

  

          

   

• DLP Download Support for File System Access API (FSA)   

  Data Loss Prevention (DLP) protection now covers files and directories downloaded using the File System Access (FSA) API. This enhancement ensures that downloads from modern web applications, such as browser-based editors, are scanned according to your organization's DLP rules. Users and websites receive notifications on scan verdicts, strengthening data security and compliance. If a download violates a DLP policy, it is blocked, resulting in an empty file, and the website might indicate a "Blocked by Safe Browsing" error. This change primarily benefits security by preventing data exfiltration through this vector. Administrators should test this with web applications using the FSA API to observe the behavior with their current DLP configurations.

  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Enables DLP content analysis for downloads initiated via File System Access API on selected platforms, governed by existing enterprise policies.

Upcoming Chrome browser changes

    

• Chrome on Android no longer supports Android Oreo or Android Pie 

  The last version of Chrome that supports Android Oreo or Android Pie is Chrome 138, and it includes a message to affected users informing them to upgrade their operating system. Chrome 139 and newer versions will not be supported on, nor shipped or available to, users running Android Oreo or Android Pie.

  • Chrome 139 on Android: Chrome on Android no longer supports Android Oreo or Android Pie.

    

• Gemini in Chrome 

  Gemini is now integrated into Chrome on macOS and Windows, and can understand the content of your current page. Users can now seamlessly get key takeaways, clarify concepts, and find answers, all without leaving their Chrome tab. This integration includes both chat—where users can interact with Gemini via text, and “Gemini Live” , by which users can interact with Gemini via voice.

  In Chrome 137, Gemini in Chrome is available for Google AI Pro and Ultra subscribers in the US. A broader rollout will come in future milestones. Admins can turn off this feature (value 1) using the GeminiSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see Gemini in Chrome in the Help Center.

  • Chrome 137 on macOS, Windows: Feature is available for some Google AI Pro and Ultra subscribers in the US and on pre-Stable (Dev, Canary, Beta) channels in the US.
  • Chrome 139 on macOS, Windows: Feature gradually rolls out on Stable for users signed into Chrome in the US. 

    

• Malicious APK download checks 

  Chrome on Android will now contact Google servers about APK files downloaded in Chrome, to get a verdict about their safety. If a downloaded APK file is determined to be dangerous, Chrome will show a warning and block the download, to protect users against mobile malware. Such download warnings will be bypassable by the user through the Chrome UI. These malicious APK download checks will be performed for users enrolled in Standard Protection or Enhanced Protection from Google Safe Browsing. This feature can be disabled by setting the Safe Browsing mode to "No Protection" via the SafeBrowsingProtectionLevel policy.

  • Chrome 139 on Android
   

  

   

    

• Upcoming change for CA certificates included in the Chrome Root Store 

  In response to sustained compliance failures, Chrome 139 changes how publicly-trusted TLS server authentication, that is, websites or certificates issued by Chunghwa Telecom and Netlock, are trusted by default. This applies to Chrome 139 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 Chunghwa Telecom or Netlock root CA certificates included in the Chrome Root Store and issued:

      - after July 31, 2025, will no longer be trusted by default.

      - on or before July 31, 2025, will be unaffected by this change. 

  If a Chrome user or an enterprise explicitly trusts any of the affected Chunghwa Telecom or Netlock 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 - Upcoming Changes to the Chrome Root Store.

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

  • Chrome 139 on Android, ChromeOS, Linux, macOS, Windows: All versions of Chrome 139 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 July 31, 2025.
   

    

• Migrate extensions to Manifest V3 before June 2025 

  Extensions must be updated to leverage Manifest V3. Chrome extensions are transitioning to a new manifest version, Manifest V3. This will bring improved privacy for your users—for example, by moving to a model where extensions modify requests declaratively, without the ability to see individual requests. This also improves extension security, as remotely hosted code will be disallowed on Manifest V3. 

  In June 2024, Chrome began to gradually disable Manifest V2 extensions running in the browser. An Enterprise policy - ExtensionManifestV2Availability - can be used to test Manifest V3 in your organization ahead of the migration. Additionally, machines on which the policy is enabled will not be subject to the disabling of Manifest V2 extensions until the following year - June 2025 - at which point the policy will be removed.

  You can see which Manifest version is being used by all Chrome extensions running on your fleet using the Apps & extensions usage page in Chrome Enterprise Core. 

  • Chrome 127 on ChromeOS, LaCrOS, Linux, macOS, Windows: Chrome will gradually disable Manifest V2 extensions on user devices. Only those with the ExtensionManifestV2Availability enterprise policy enabled would be able to continue using Manifest V2 extensions in their organization.
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Remove ExtensionManifestV2Availability policy.
   

    

• Promotional notifications 

  From Chrome 128, promotional OS-level notifications are shown to users. These notifications are governed by the PromotionsEnabled enterprise policy.

  • Chrome 128 on ChromeOS, Linux, macOS, Windows
  • Chrome 139 on Windows: In Chrome 138, promo notifications were only activated on Chrome clients when upgrading from Windows 10 to Windows 11. From Chrome 139, this is being extended to all Windows Chrome installations. Notifications will still be only shown to a subset of low-engaged users, and these can be disabled through the PromotionsEnabled enterprise policy.
   

    

• Remove risky extension flags in Google Chrome 

  To enhance the security and stability of the Chrome browser for our users, official Chrome branded builds will be removing --extensions-on-chrome-urls and --disable-extensions-except command-line flags starting in Chrome 139. This change aims to mitigate the risks associated with harmful and unwanted extensions. 

  Developers can still use the both flags in non-branded builds such as Chromium and Chrome For Testing.

  • Chrome 139 on Linux, macOS, Windows: Gradual roll-out 
   

    

• Remove SwiftShader fallback 

  Allowing automatic fallback to WebGL backed by SwiftShader is deprecated and WebGL context creation now fails 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. It is important to test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user. A temporary enterprise policy will be available in Chrome 138 to revert the change. 

  • Chrome 137 on Windows: SwiftShader will be disabled and replaced with another software WebGL fallback, WARP. Tests depending on the exact pixel values generated by SwiftShader may start failing.
  • Chrome 139 on Linux, macOS: Swiftshader will be disabled on macOS and Linux as early as Chrome 138. Users on machines without a GPU will not be able to use WebGL.
   

    

• Support accounts in pending state on Chrome iOS 

  Accounts whose credentials somehow became invalid will no longer be automatically signed out and removed from Chrome on iOS. Instead, these accounts will stay signed in to the browser, in a newly introduced "pending state" associated with a persistent error indication in the UI so users are encouraged to resolve it. This also means that local data associated with these accounts will no longer be automatically deleted, but instead kept on disk. Existing policies controlling sign-in (for example, BrowserSignin) will continue to work as before.

  • Chrome 139 on iOS: Feature will gradually roll out 
   

    

• Chrome to remove support for macOS 11 

  Chrome 138 will be the last release to support macOS 11; Chrome 139+ will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

  On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome updated, they need to update their computer to a support version of macOS. For new installations of Chrome 139+, macOS 12+ will be required.

  • Chrome 139 on Windows, macOS, Linux
   

    

• Clear window name for cross-site navigations that switches browsing context group 

  The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, which can leak information and potentially be used as a tracking vector. Clear the window.name property in this case addresses this issue. 

  This update will introduce a new temporary enterprise policy, ClearWindowNameCrossSiteBrowsing, which will stop working in Chrome 142.

  • Chrome 139 on Windows, macOS, Linux, Android, iOS
   

    

• Fire error event instead of throwing exception for CSP blocked worker 

  When blocked by Content Security Policy (CSP), Chromium currently throws a SecurityError from the constructor of Worker and SharedWorker. To be spec-compliant,  the CSP needs to be checked as part of fetch and then fire error events asynchronously instead of throwing an exception when the script runs "new Worker(url)" or "new SharedWorker(url)". 

  This update aims to make Chromium spec-conformant, which is, it no longer throws exceptions following constructor calls, and fires error events asynchronously.

  • Chrome 139 on Windows, macOS, Linux, Android
   

    

• Web App Manifest: specify update eligibility, icon URLs are Cache-Control: immutable 

  As early as Chrome 139, the Web App manifest will specify an update eligibility algorithm. This makes the update process more deterministic and predictable, giving the developer more control over whether (and when) updates should apply to existing installations, and allowing removal of the 'update check throttle' that user agents currently need to implement to avoid wasting network resources.

  • Chrome 139 on Windows, macOS, Linux
  • Chrome 140 on Android
   

    

• 2SV enforcement for admins 

  To better protect your organization’s information, Google will soon require all accounts with access to admin.google.com to have 2-Step Verification (2SV) enabled. As a Google Workspace administrator, you need to confirm your identity with 2SV, which requires your password plus something additional, such as your phone or a security key.

  The enforcement will be rolled out gradually over the coming months. You should enable 2SV for the admin accounts in your organization before Google enforces it. For more information, see this Help Center article.

  • Chrome 137 on ChromeOS, Linux, macOS, Windows: 2SV enforcement starts
  • Chrome 140 on ChromeOS, Linux, macOS, Windows: 2SV mandatory

    

• Happy Eyeballs V3 

  This launch is an internal optimization in Chrome that implements Happy Eyeballs V3 to achieve better network connection concurrency. Happy Eyeballs V3 performs DNS resolutions asynchronously and staggers connection attempts with preferable protocols (H3/H2/H1) and address families (IPv6 or IPv4) to reduce user-visible network connection delay. This feature is gated by a temporary policy HappyEyeballsV3Enabled.

  • Chrome 140 on Android, ChromeOS, Linux, macOS, Windows

    

• 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 that 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 the explainer. 

  In this initial release, IWAs will only be installable through an admin 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.

    

• Disallow non-trustworthy plaintext HTTP prerendering 

  This launch will provide the capability to disallow non-trustworthy plaintext HTTP prerendering.

  • Chrome 140 on Windows, macOS, Linux, Android

    

• HSTS tracking prevention 

  This update will mitigate user tracking by third-parties via the HTTP Strict Transport Security (HSTS) cache. This feature only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. Doing so makes it infeasible for third-party sites to use the HSTS cache in order to track users across the web.

  • Chrome 140 on Windows, macOS, Linux, Android

    

• IP Protection 

  This feature  limits availability of a user’s original IP address in third-party contexts in Incognito mode, enhancing Incognito's protections against cross-site tracking when users choose to browse in this mode. IP addresses facilitate a range of use cases, including routing traffic and preventing fraud and spam. However, they can also be used for tracking. For Chrome users who choose to browse in Incognito mode, we want to provide additional control over their IP address, without breaking essential web functionality. To strike this balance between protection and usability, this proposal focuses on limiting the use of IP addresses in a third-party context in Incognito mode. To that end, this proposal uses a list-based approach, where only domains on the Masked Domain List (MDL) in a third-party context will be impacted. For enterprises, this feature can be controlled via the PrivacySandboxIpProtectionEnabled enterprise policy.

  • Chrome 140 on Windows, macOS, Linux, Android
   

    

• Strict Same Origin Policy for Storage Access API 

  We plan to adjust the Storage Access API semantics to strictly follow the Same Origin Policy, to enhance security. Using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default. The CookiesAllowedForUrls policy or Storage Access Headers can still be used to unblock cross-site cookies.

  • Chrome 140 on Windows, macOS, Linux, Android
   

    

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

  According to the URL Standard specification, 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 (Github).

  • Chrome 141 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, Fuchsia

    

• SafeBrowsing API v4 → 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. For more details, see Migration From V4 - Safe Browsing. 

  • Chrome 145 on Android, iOS, ChromeOS, Linux, macOS, Windows: Feature would gradually roll-out 

    

• 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 may use the UiAutomationProviderEnabled enterprise policy starting in 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 146, and will be removed in Chrome 147. 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 146.
  • Chrome 147 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 remote commands and CSV export for the Managed profiles list 

  The Admin console will support profile-level "Clear cache" and "Clear cookies" remote commands, and CSV export for the Managed Profiles list. You can select one or multiple profiles and perform a remote command.

  • Chrome 137 on Android, Linux, macOS, Windows: Adding CSV export for Managed profiles. 
  • Chrome 139 on Linux, macOS, Windows: Profile-level support for remote commands. 

    

• New tab page cards for Microsoft 365 

  Enterprise users with Outlook or SharePoint will be able to 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 can enable the cards with NTPSharepointCardVisible and NTPOutlookCardVisible. For Microsoft tenants who do not allow for self-authorization, the admin must also consent to the app permissions during first authentication or approve the app for use in Microsoft Entra.

  • Chrome 134 on Linux, macOS, Windows: Available to Trusted Testers 
  • Chrome 137 on Linux, macOS, Windows:  Gradual rollout to all customers 
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Users will not need to be signed into Chrome to use this feature

    

• Chrome Enterprise Overview page 

  This launch is introducing a new Overview page in the Chrome browser section of the Google Admin console. The Overview page allows IT administrators to quickly find key information about their deployment:

  - Active & inactive profiles and enrolled browsers

  - Identify browsers out-of-date and with pending updates

  - Identify high-risk extensions (according to Spin.AI) and get a preview of most requested extensions

  - Security Insights (for example, sensitive file uploads or downloads)

  The Overview page also allows admins to quickly access key actions such as managing extensions, accessing the browser or profile list and setting Update policies, to name a few.

  • Chrome 137 on Android, iOS, Linux, macOS, Windows
  • Chrome 140 on Android, iOS, Linux, macOS, Windows: New filtering available on the Overview page for Organization Unit and Activity Dates
   

   

Upcoming Chrome Enterprise Premium changes

   

• Chrome browser rule UX refactor 

  To enhance the Data Loss Prevention (DLP) rule creation experience, the Google Admin console is being updated to streamline how administrators define policies for different applications like Chrome and Workspace. This first introduces mutually exclusive application groups, meaning that a single DLP rule can now only target one application group at a time—either Workspace apps (like Drive, Gmail), Chrome browser triggers (like file upload, URL visited), or ChromeOS triggers. This change simplifies rule configuration, eliminates potential conflicts from overlapping app selections, and lays the groundwork for more specialized and user-friendly workflows tailored to each platform's needs.

  Administrators will see an updated "Apps" selection interface using radio buttons to enforce this single-group selection for new rules. Existing rules that previously combined applications from multiple groups will be transparently migrated by the system into separate, compliant, single-platform rules to ensure continued protection and a seamless transition. Banners within the Admin console will provide information regarding these changes and the migration process. No new enterprise policies are introduced with this update; the changes are to the rule configuration interface.

  • Chrome 139 on ChromeOS, Linux, macOS, Windows:  Enables mutually exclusive app selection for DLP rule configuration in Admin console
   

   

• Copy and Paste rules protection 

  To help organizations better prevent data exfiltration on mobile devices, Chrome is extending its existing desktop clipboard data controls. Administrators can now use the DataControlsRules policy to set rules that block or warn users when they attempt to copy or paste content that violates organizational policies. This feature allows admins to define data boundaries and prevent sensitive information from being pasted from a work context into personal apps or websites on their mobile fleet. This addresses a significant security gap and a frequently requested feature from enterprise customers who have cited the lack of mobile data controls as a concern. To use this feature, administrators can configure clipboard restrictions within the DataControlsRules policy, providing a consistent management experience across desktop and mobile to strengthen their organization's overall security posture.

  • Chrome 139 on Android: Copy and Paste rules protection available on Android

ChromeOS 138 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Class Tools		✓	✓
ChromeOS freeform wallpapers		✓
Help me read on ChromeOS		✓
Accessibility updates		✓
Expansion of the Disabled System Features policy			✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Chrome apps changes		✓
Native Client (NaCl) deprecation	✓
EAP/TLS server certificate validation	✓		✓

 

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

   

• Class Tools 

  Class Tools are premium teaching and learning tools built for Chromebooks. They aim to provide teachers with real-time classroom management tools and enhance learning for students. Class Tools help teachers to:

  • send and lock website content on student Chromebooks.
  • offer students on-screen captions and real-time translations.
  • view and share students' screens.

  To learn more, see Overview of Class Tools in the Help Center. To use Class Tools, your organization needs to have a Google Workspace for Education Plus or a Teaching and Learning add-on license. For more details, see Education Plus edition. 

  

   

• ChromeOS freeform wallpapers 

  As early as ChromeOS 138, freeform wallpapers offer an unrestricted input field that empowers users to express their individuality, creativity, and passions by turning their background into a personal canvas. Users can generate wallpapers by inputting different prompts in the text field, or use the Inspire me feature, which will generate random prompts and wallpapers until you find one you like. This feature is available on Chromebook Plus devices only. For more information, see Wallpaper settings.

  Admins can control this feature using the GenAIWallpaperSettings policy.

  • For 18+ consumers, the default is Allow with data collection. 
  • For 18+ managed users, the default is Allow without data collection. 
  • Users under 18 cannot access the feature. 

   

  

   

• Help me read on ChromeOS 

  As early as ChromeOS 138, Help me read on ChromeOS provides an AI-powered solution to help you quickly understand text information written in verbose and convoluted language or with jargon. Select a piece of text and right-click on it to reveal the simplify button that can give you a straightforward version of the source, which can be digested at a glance.

  Admins can control access to this feature using the HelpMeReadSettings policy, but users need to explicitly opt in to use Help me read on ChromeOS. This feature is available on Chromebook Plus devices only. For more details, see Chrome—Generative AI features and policies. 

 

• Expansion of the Disabled system features policy 

  We're releasing a significant expansion of the Disabled system features policy. You now have granular control over a wider range of applications, to allow for more tailored device management.
  ChromeOS 138 supports disabling the following additional applications:

   

  This update provides administrators with enhanced flexibility to configure available apps according to specific organizational needs and security requirements.

  
  • Web Store
  • Canvas
  • Explore
  • Gallery
  • Terminal
  • Print Jobs
  • Key Shortcuts
  • YouTube
  • Google Maps
  • Gmail
  • Google Docs
  • Google Slides
  • Google Sheets
  • Google Drive
  • Google Keep
  • Google Calendar
  • Google Chat

   

• Accessibility updates 

  In ChromeOS 138, we've focused on refining the accessibility experience by addressing several key issues to improve usability and conformance. 

  Resolved issues:

  • Incorrect Heading Levels: The Wallpaper and style page now uses correct heading levels, improving navigation for screen reader users.
  • Gallery App - Date Announcement: ChromeVox now accurately announces date information when browsing the Google Photos image list within the Gallery App.
  • Gallery App - px Unit Announcement: To provide clearer context, the px unit is now announced by ChromeVox when navigating Width and Height fields for image rescaling in the Gallery App.
  • Out-of-Box Experience (OOBE) - Redundant Announcements: We've streamlined ChromeVox announcements during OOBE updates. The progress indicator is now hidden from screen readers to prevent redundant announcements like Progress indicator, min 0 max 100 and incorrect image announcements.
  • Out-of-Box Experience (OOBE) - Focus Disruption: We’ve addressed an issue in OOBE where switching between personal and corporate account enrollment buttons with ChromeVox incorrectly shifted focus to the calendar. Focus now correctly remains on the updated screen or dialog.

Upcoming ChromeOS changes

   

• Chrome apps changes 

  Starting with ChromeOS 138, admin-installed Chrome apps in kiosk sessions will be disabled by default. A new policy, KioskChromeAppsForceAllowed, will be available prior to the release of ChromeOS 138 for administrators to re-enable Chrome apps in kiosk sessions. With this policy turned on, Chrome apps in kiosk sessions will be supported through ChromeOS 150.

  Starting with ChromeOS 139, planned for stable release on August 19th, user-installed Chrome apps on ChromeOS will stop working. Apps that are force-installed through the admin console for Managed Guest sessions (MGS) and user sessions will continue to be supported. For more details, see End of support for Chrome apps.

 

   

• Native Client (NaCl) deprecation 

  ChromeOS 138 will be the final release to support Native Client (NaCl) in managed environments with the NaCl allow policy enabled. For devices on the Long-term Support (LTS) channel with this policy active, NaCl support will continue until the LTS Last Refresh in April 2026.

 

   

• EAP/TLS server certificate validation 

  Note: This change only affects customers utilizing EAP/TLS network setups and only affects networks set up before January of 2022.

  Starting October 1, 2025, we will roll out this fix to the ChromeOS stable channel. A very small number of customers using EAP/TLS configurations might experience connectivity issues if their server certificates are signed by a Certificate Authority (CA) that is currently included in ChromeOS as a System CA.

  To minimize disruption, admins can perform one of the following actions:

  Option 1 (providing a higher level of security):

  1. Generate a new certificate for your Authentication Server, and ensure it is signed by the same Certificate Authority (CA) as used previously.
  2. Replace the existing certificates on your Authentication Server with the newly-generated certificates.
   

  Option 2 ( if more time is needed before implementing Option 1):

  1. Sign in to Google Admin console.

  2. From August 15 to October 1, to check for affected devices, admins can follow these instructions on the Beta channel:

     • Access chrome://histograms in Chrome browser.
     • Perform several disconnect and reconnect cycles for your Ethernet or Wi-Fi network.
     • Allow approximately 10 seconds for data aggregation.
     • Within the chrome://histograms page, search the histogram identified as Network.Shill.Eap.EventCaCertExperiment1:
       1. If the histogram is not present, your configuration is not impacted.
       2. Your configuration is likely to be impacted if a positive value is observed for both Event 8 (FirstCertVerificationFailure) and Event 9 (CertVerificationRetryAttempt).
  3. Navigate to the configuration settings for the affected EAP/TLS network.
  4. Modify the Server Certificate Authority setting to System default certificate authorities.

Chrome 137 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Gemini in Chrome		✓
Blob URL Partitioning: Fetching/Navigation	✓
Client’s LLM assistance in mitigating scams	✓
DTLS 1.3	✓
Remove --load-extension command line switch in Google Chrome	✓
Remove SwiftShader fallback	✓
Customizing managed profiles with custom logo and label			✓
Align error type thrown for payment WebAuthn credential creation: SecurityError => NotAllowedError	✓
HSTS tracking prevention	✓
2SV enforcement for admins	✓
Autofill with AI		✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
IP Address Logging & Reporting			✓
Chrome Enterprise Overview page			✓
New remote commands and CSV export for the Managed Profile list			✓
New tab page cards for Microsoft 365		✓	✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
DLP download support for File System Access API (FSA)	✓		✓
Reporting Connector on Mobile	✓		✓
Reporting Safe Browsing events on iOS	✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Bookmarks and reading list improvements on Chrome Desktop	✓	✓
Per-extension user script toggle			✓
Enhanced Safe Browsing as a synced setting	✓
Shared tab groups		✓
Generating insights for Chrome DevTools Console warnings and errors			✓
Removal of Private Network Access enterprise policies	✓
TLS 1.3 Early Data		✓
Predictable reported storage quota		✓
Strict Same Origin Policy for Storage Access API		✓
Summarizer API		✓
Language Detector API		✓
Translator API		✓
Web serial over Bluetooth on Android			✓
Upcoming change for CA certificates included in the Chrome Root Store	✓
Chrome on Android no longer supports Android Oreo or Android Pie			✓
Migrate extensions to Manifest V3 before June 2025	✓	✓	✓
Chrome will remove support for macOS 11			✓
Happy Eyeballs V3		✓
Isolated Web Apps	✓		✓
Disallow spaces in non-file:// URL hosts	✓
SafeBrowsing API v4 → v5 migration	✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Agentspace recommendations in the Chrome omnibox		✓	✓
Inactive profile deletion in Chrome Enterprise Core	✓		✓
Multiple Identity Support on iOS		✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
URL Filtering capabilities on iOS	✓
DLP Download Support for File System Access API (FSA)	✓

 

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  

   

• Gemini in Chrome 

  Gemini is now integrated into Chrome on macOS and Windows, and can understand the content of your current page. Users can now seamlessly get key takeaways, clarify concepts, and find answers, all without leaving their Chrome tab. This integration includes both chat—where users can interact with Gemini via text, and Gemini Live , by which users can interact with Gemini via voice.

  In Chrome 137, Gemini in Chrome is available for Google AI Pro and Ultra subscribers in the US. A broader rollout will come in future milestones. You can check the upcoming publications of these Enterprise Release Notes for availability updates. 

  Admins can turn off this feature (value 1) using the GeminiSettings policy or by using the GenAiDefaultSettings (value 2). For more details, see Gemini in Chrome in the Help Center.

   
  • Chrome 137: Feature becomes available for some Google AI Pro and Ultra subscribers in the US and on pre-Stable (Dev, Canary, Beta) channels in the US.
  • A broader rollout will come in future milestones. You can check the upcoming publications of the Enterprise Release Notes for availability updates.

   

• Blob URL Partitioning: Fetching/Navigation 

  As a continuation of Storage Partitioning, Chrome 137 now implements 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, Chrome 137 now enforces 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 Chrome 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 137 on Android, ChromeOS, Linux, macOS, Windows

   

• Client’s LLM assistance in mitigating scams 

  Users on the web are facing significant amounts of different kinds of scams a day. To combat these scams, Chrome now leverages on-device LLM to identify scam websites for Enhanced Safe Browsing users. Chrome sends 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 might consume more bandwidth to download the LLM. 

  Enhanced Safe Browsing is an existing feature, controlled by the SafeBrowsingProtectionLevel policy.

  • Chrome 134 on Linux, macOS, Windows: Gather the brand name and intent summary of the page that triggers keyboard lock to identify scam websites.
  • Chrome 135 on Linux, macOS, Windows: Show the warnings to the user based on the server verdict which uses the brand and intent summary of the page that triggered keyboard lock.
  • Chrome 137 on Linux, macOS, Windows: Gather brand and intent summary of the page based on server reputation scoring system.
  • Chrome 138 on Linux, macOS, Windows: Show the warnings to the user based on the server verdict which uses the brand and intent of the pages that the server reputation system scored.

   

• DTLS 1.3 

  Chrome 137 adds support for Datagram Transport Layer Security (DTLS) 1.3 for Web Realtime Communication (WebRTC) connections. Previously, DTLS 1.2 was used for all WebRTC connections. This is required to add quantum-resistant cryptography to WebRTC.

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

   

• Remove --load-extension command line switch in Google Chrome 

  To enhance the security and stability of the Chrome browser for our users, official Chrome-branded builds now deprecate the ability to load extensions via the --load-extension command-line flag, starting in Chrome 137. This change aims to mitigate the risks associated with harmful and unwanted extensions. 

  Unpacked extensions can be loaded via the Load Unpacked button on the extension management page (chrome://extensions/) with developer mode enabled. Developers can still use the --load-extension switch in non-branded builds such as Chromium and Chrome For Testing.

   
  • Chrome 137 on Linux, macOS, Windows

   

• Remove SwiftShader fallback 

  Allowing automatic fallback to WebGL backed by SwiftShader is deprecated and WebGL context creation now fails 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. It is important to test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user. A temporary enterprise policy will be available in Chrome 138 to revert the change. 

   
  • Chrome 137 on Windows: SwiftShader will be disabled and replaced with another software WebGL fallback, WARP. Tests depending on the exact pixel values generated by SwiftShader may start failing.
  • Chrome 138 on Linux, macOS: Swiftshader will be disabled on macOS and Linux as early as Chrome 138. Users on machines without a GPU will not be able to use WebGL.

   

• Customizing managed profiles with custom logo and label 

  Chrome 137 has a 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 BYOD 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 became available to customize the logo and label shown on a managed profile. Starting Chrome 137, there are updates to the default behavior of the profile label and icon overlaid on the account avatar. In Chrome 138, 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 LaCrOS, macOS, Windows: Policies to customize the toolbar label and icon (in profile menu). 
  • Chrome 136 on Linux, macOS, Windows: Rollout of Managed by your organization in profile menu . The logo can be customized via EnterpriseLogoUrl policy.
  • Chrome 137 on Linux, macOS, Windows: Rollout of default work and school labels in Chrome toolbar. The label can be turned off via EnterpriseProfileBadgeToolbarSettings.
   

  

   

• Align error type thrown for payment WebAuthn credential creation: SecurityError => NotAllowedError 

  This change corrects the error type thrown during WebAuthn credential creation for payment credentials. Due to a historic specification mismatch, creating a payment credential in a cross-origin iframe without a user activation would throw a SecurityError instead of a NotAllowedError, which is what is thrown for non-payment credentials.

  Code that previously detected the type of error thrown, for example,  `e instanceof SecurityError`, would be affected. Code that just generally handles errors during credential creation, for example,  `catch (e)`, will continue to function correctly.

   
  • Chrome 137 on Windows, macOS, Linux, Android

   

• HSTS tracking prevention 

  HTTP Strict Transport Security (HSTS) tracking prevention mitigates user tracking by third-parties via the HSTS cache. This feature only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. Doing so makes it infeasible for third-party sites to use the HSTS cache in order to track users across the web.

   
  • Chrome 137 on Windows, macOS, Linux, Android

   

• 2SV enforcement for admins 

  To better protect your organization’s information, Google will soon require all accounts with access to admin.google.com to have 2-Step Verification (2SV) enabled. As a Google Workspace administrator, you need to confirm your identity with 2SV, which requires your password plus something additional, such as your phone or a security key.

  The enforcement will be rolled out gradually over the coming months. You should enable 2SV for the admin accounts in your organization before Google enforces it. For more information, see this Help Center article.

   

   

• Autofill with AI 

  Starting in Chrome 137, some users can turn on Autofill with AI, a new feature that helps users fill out online forms more easily. On relevant forms, Chrome can use AI to better understand the form and offer users to automatically fill in previously saved info. Admins can control the feature using the existing GenAiDefaultSettings policy and a new AutofillPredictionSettings policy.

   
  • Chrome 137 on Linux, macOS, Windows, ChromeOS
   

   

• New policies in Chrome browser 

  Policy	Description
  GeminiSettings	Settings for Gemini integration
  AutofillPredictionSettings	Settings for Autofill with AI
  ProvisionalNotificationsAllowed	Allows the app to use provisional notification authorization on iOS
  RelaunchFastIfOutdated	Relaunch fast if outdated
  UserSecurityAuthenticatedReporting	Enable cloud reporting of security signals in managed profiles
  BuiltInAIAPIsEnabled	Allow pages to use the built-in AI APIs
  OnSecurityEventEnterpriseConnector	Configuration policy for the OnSecurityEvent Chrome Enterprise Connector (now available on iOS)
  UserSecuritySignalsReporting	Enable cloud reporting of security signals in managed profiles

   

• Removed policies in Chrome browser 

  Policy	Description
  MutationEventsEnabled	Re-enable deprecated/removed Mutation Events
  TabOrganizerSettings	Settings for Tab Organizer
  ZstdContentEncodingEnabled	Enable zstd content-encoding support

   

   

Chrome Enterprise Core changes

   

• IP Address Logging & Reporting 

  Chrome Enterprise will enhance security monitoring and incident response capabilities by collecting and reporting local and remote IP addresses and sending those IP addresses to the Security Investigation Tool (SIT) logs. In addition, Chrome Enterprise will allow admins to optionally send the IP addresses to first-party and third-party security information and event management (SIEM) providers via the Chrome Enterprise reporting connector. For more details, see Manage Chrome Enterprise reporting connectors. This will be available for Chrome Enterprise Core and Chrome Enterprise Premium customers.

   
  • Chrome 137 on Windows, macOS, Linux

   

• Chrome Enterprise Overview page 

  Chrome Browser Enterprise is introducing a new Overview page in the Chrome browser section of the Google Admin console. The Overview page allows IT administrators to quickly find key information about their deployment:

  - Active and inactive profiles and enrolled browsers

  - Identify browsers out-of-date and with pending updates

  - Identify high-risk extensions (according to Spin.AI) and get a preview of most requested extensions

  The Overview page also allows you to quickly access key actions, such as, managing extensions (block and allow) and accessing browser and profile lists.

   
  • Chrome 137 on Android, iOS, Linux, macOS, Windows
   

  

   

• New remote commands and CSV export for the Managed profiles list 

  The Admin console will support profile-level "Clear cache" and "Clear cookies" remote commands, and CSV export for the Managed Profiles list. You can select one or multiple profiles and perform a remote command.

  • Chrome 137 on Android, Linux, macOS, Windows: Adding CSV export for Managed profiles. You can export the Managed profile data outside of the Admin console.
  • Chrome 138 on Linux, macOS, Windows: Profile-level support for the Clear cache and Clear cookies remote commands. In the Managed profile list, you will be able to select one or multiple profiles and perform a remote command.

   

• New tab page cards for M365 

  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 can enable the cards with NTPSharepointCardVisible and NTPOutlookCardVisible. For Microsoft tenants who do not allow for self-authorization, the admin must also consent to the app permissions during first authentication or approve the app for use in Microsoft Entra.

   
  • Chrome 134 on Linux, macOS, Windows: Trusted Testers 
  • Chrome 137 on Linux, macOS, Windows: Rollout starts

 

Chrome Enterprise Premium changes

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

   

• DLP download support for File System Access API (FSA)   

  Chrome Enterprise Premium's Data Loss Prevention (DLP) content analysis and Safe Browse deep scans now extend to folder and directory downloads initiated via the File System Access (FSA) API, for example, in web-based IDEs. This addresses a gap, enhancing data security by applying existing DLP rules (configured via DataLeakPreventionRulesList and SafeBrowsingDeepScanningEnabled policies) to these operations.

  If a download violates a DLP policy, it will be blocked, resulting in an empty file, and the website might indicate a Blocked by Safe Browse error. This change primarily benefits security by preventing data exfiltration through this vector. Administrators should test this with web applications using the FSA API to observe the behavior with their current DLP configurations.

   
  • Chrome 137 on ChromeOS, Linux, macOS, Windows: Enables DLP content analysis for downloads initiated via File System Access API on selected platforms, governed by existing enterprise policies.

   

• Reporting Connector on Mobile   

  The Chrome Enterprise Reporting Connector is being updated to include security event reporting from Chrome on mobile devices (Android and iOS). This will provide IT admins with visibility into events such as unsafe site visits, sensitive data transfers (as per Data Protection rules), and URL Filtering matches occurring on mobile, achieving feature parity with existing desktop reporting. This enhancement aims to improve the organization's overall security posture by extending threat detection and data protection capabilities to mobile platforms.

  For customers utilizing the Security Investigation Tool (SIT), these new mobile browser events will be available for investigation; this SIT integration is a feature of Chrome Enterprise Premium. IT admins should be aware that these additional event types from mobile will begin to flow through their configured Reporting Connector.

  No new, specific enterprise policies are being introduced to control this mobile reporting extension itself; existing configurations for the Reporting Connector, Data Protection rules, and URL Filtering policies will determine the events generated and reported.

   
  • Chrome 137 on Android, iOS: Enables security event reporting, for example, unsafe sites, sensitive data transfers, URL filtering, via the Reporting Connector for Chrome on Mobile

   

• Reporting Safe Browsing events on iOS   

  The feature will enable Safe Browsing events reporting on iOS to help increase the security of enterprise environments. This feature has already been implemented on Desktop and Android, we are now extending it to iOS. For details on how to turn on this feature, see this Help Center article. 

   
  • Chrome 137 on iOS: Reporting Safe Browsing events become available on iOS

Upcoming Chrome browser changes

    

• Bookmarks and reading list improvements on Chrome Desktop 

  On Chrome 138 on Desktop, some users who sign in to Chrome upon saving a new bookmark can now use and save bookmarks and reading list items in their Google Account. Relevant enterprise policies controlling bookmarks, 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. Setting EditBookmarksEnabled to false will also prevent users from uploading a bookmark saved on their device to their Google Account.  

   
  • Chrome 138 on Linux, macOS, Windows

    

• Per-extension user script toggle 

  In Chrome 138, the way that users and administrators control an extension’s ability to run user created scripts and use the userScripts API is changing. This change enhances security. End-users won’t unintentionally grant user script permissions to every extension when enabling Developer mode by explicitly deciding which extensions can run these potentially powerful scripts. For more detail on the motivation for the change, see this Chrome for developers blog.

  End users will now toggle this per extension on the chrome://extensions page via a Allow User Scripts toggle, replacing the global Developer mode toggle for more granular control. Existing extensions will have this toggle automatically enabled if Developer mode is on and the extension has been granted the User Scripts permission.

  Administrators who currently manage user scripts by disabling developer mode should now use the `blocked_permissions` policy or the Google Admin console to independently control the User Scripts permission and extension Developer mode.

  Extension developers are advised to update their documentation to reflect the new toggle. See the Chromium Extensions Google Groups mailing list for more information and other changes to usage of the API.

   
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: Feature rolls out
   

  

   

    

• Enhanced Safe Browsing as a synced setting 

  Chrome's Enhanced Safe Browsing is becoming a synced feature. This means that if a user opts into Enhanced Safe Browsing on one device, this protection level will automatically apply across all other devices where they are signed into Chrome with the same account. The goal is to provide stronger, more consistent security protection and a standardized user experience.

  Users who enable Enhanced Safe Browsing will benefit from its protections, for example, proactive phishing protection, improved detection of malware and malicious extensions) consistently across their synced Chrome instances on Desktop (Windows, macOS, Linux, ChromeOS), Android, and iOS. Users will be notified of this change via UI elements when their Enhanced Safe Browsing setting is synced.

  The Safe Browsing protection level is an existing feature, controlled by the SafeBrowsingProtectionLevel policy.

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

    

• Shared tab groups 

  Users will be able to collaborate on tabs via the shared tab groups feature. With this feature users can create and use a set of tabs on their desktop or mobile device and their collaborative partners will browse the same tabs on their devices. When one person changes a tab in the group, the changes are reflected across all user's browsers in the group. An enterprise policy, TabGroupSharingSettings, will be available to control this feature.

   
  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Rollout of the ability to join and use a shared tab group. Users on Stable Chrome will not be able to create a shared tab group (the entry point will not be available) - this part of the feature will only be available on Beta/Dev/Canary for this phase of rollout. 

    

• 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.
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: The AI assistance panel exposes an internal API that simplifies the use of AI assistance panel features by external tools such as Model Context Protocol (MCP) servers.

    

• 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) (Github). 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 immediately. 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.

   
  • Chrome 135 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Deprecate InsecurePrivateNetworkRequestsAllowedForUrls, InsecurePrivateNetworkRequestsAllowed, and PrivateNetworkAccessRestrictionsEnabled policies.
  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia: Removal of PrivateNetworkAccessRestrictionsEnabled, InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed. There should be a PNA2 replacement policy available in Chrome 138.

    

• TLS 1.3 Early Data 

  TLS 1.3 Early Data allows GET requests to be sent during the handshake when resuming a connection to a compatible TLS 1.3 server. The feature is expected to demonstrate performance improvements and will be available in Chrome 138 with a policy (TLS13EarlyDataEnabled) to control this change.

  TLS 1.3 Early Data is an established protocol. Existing TLS servers, middleboxes, and security software are expected to either handle or reject TLS 1.3 Early Data without dropping the connection. However, devices that do not correctly implement the TLS standard (RFC8446) may malfunction and disconnect when TLS 1.3 Early Data is in use. If this occurs, administrators should contact the vendor for a fix.

  This policy is a temporary measure to control the feature and will be removed in a future milestone. The policy may be enabled to allow you to test for issues and disabled while issues are being resolved.

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

    

• Predictable reported storage quota 

  Chrome 138 will introduce a predictable storage quota from StorageManager's estimate API for sites that do not have unlimited storage permissions.

  It is possible to detect a user's browsing mode via the reported storage quota because the storage space made available is significantly smaller in incognito mode than in regular mode. This is a mitigation that prevents detection of a user's browsing mode via the storage API by reporting an artificial quota, equal to usage + min(10 GiB, disk rounded up to the nearest 1 GiB), in all browsing modes for sites with limited storage permissions. Sites with unlimited storage permissions will be unaffected. Enforced quota will also be unaffected.

   
  • Chrome 138 on Windows, macOS, Linux, Android

    

• Strict Same Origin Policy for Storage Access API 

  We plan to adjust the Storage Access API semantics to strictly follow the Same Origin Policy, to enhance  security. Using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default. The CookiesAllowedForUrls policy or Storage Access Headers can still be used to unblock cross-site cookies.

   
  • Chrome 138 on Windows, macOS, Linux, Android

    

• Summarizer API 

  Summarizer API is a JavaScript API for producing summaries of input text, backed by an AI language model. Browsers and operating systems are increasingly expected to gain access to a language model. By exposing this built-in model, we avoid every website needing to download their own multi-gigabyte language model, or send input text to third-party APIs. The summarizer API in particular exposes a high-level API for interfacing with a language model in order to summarize inputs for a variety of use cases (Github), in a way that does not depend on the specific language model in question. 

  An enterprise policy, GenAILocalFoundationalModelSettings, is available to disable the underlying model downloading which would render this API unavailable.

   
  • Chrome 138 on Windows, macOS, Linux

    

• Language Detector API 

  Language Detector API is a JavaScript API for detecting the language of text, with confidence levels. An important supplement to translation is language detection. This can be combined with translation, for example, taking user input in an unknown language and translating it to a specific target language. Browsers today often already have language detection capabilities, and we want to offer them to web developers through a JavaScript API, supplementing the translation API. An enterprise policy, GenAILocalFoundationalModelSettings, is available to disable the underlying model downloading which would render this API unavailable.

   
  • Chrome 138 on Windows, macOS, Linux

    

• Translator API 

  The Translator API is a JavaScript API to provide language translation capabilities to web pages. Browsers are increasingly offering language translation to their users. Such translation capabilities can also be useful to web developers. This is especially the case when the browser's built-in translation abilities cannot help. An enterprise policy, GenAILocalFoundationalModelSettings, is available to disable the underlying model downloading which would render this API unavailable.

   
  • Chrome 138 on Windows, macOS, Linux

    

• Web serial over Bluetooth on Android 

  This feature allows web pages and web apps to connect to serial ports over Bluetooth on Android devices. Chrome on Android now supports Web Serial API over Bluetooth RFCOMM. Existing enterprise policies (DefaultSerialGuardSetting, SerialAllowAllPortsForUrls, SerialAllowUsbDevicesForUrls, SerialAskForUrls and SerialBlockedForUrls) on other platforms are enabled in future_on states for Android. All policies except SerialAllowUsbDevicesForUrls will be enabled after the feature is enabled. SerialAllowUsbDevicesForUrls will be enabled in a future launch after Android provides system level support of wired serial ports.

   
  • Chrome 138 on Android

    

• Upcoming change for CA certificates included in the Chrome Root Store

  In response to sustained compliance failures, Chrome 139 changes how publicly-trusted TLS server authentication, that is, websites or certificates issued by Chunghwa Telecom and Netlock, are trusted by default. This applies to Chrome 139 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 Chunghwa Telecom or Netlock root CA certificates included in the Chrome Root Store and issued:

      - after July 31, 2025, will no longer be trusted by default.

      - on or before July 31, 2025, will be unaffected by this change. 

  If a Chrome user or an enterprise explicitly trusts any of the affected Chunghwa Telecom or Netlock 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 - Upcoming Changes to the Chrome Root Store.

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

  • Chrome 139 on Android, ChromeOS, Linux, macOS, Windows: All versions of Chrome 139 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 July 31, 2025.

    

• Chrome on Android no longer supports Android Oreo or Android Pie 

  The last version of Chrome that supports Android Oreo or Android Pie is Chrome 138, and it includes a message to affected users informing them to upgrade their operating system. Chrome 139 and newer versions will not be supported on, nor shipped or available to, users running Android Oreo or Android Pie. 

  • Chrome 139 on Android: Chrome on Android no longer supports Android Oreo or Android Pie.

    

• Migrate extensions to Manifest V3 before June 2025 

  Extensions must be updated to leverage Manifest V3. Chrome extensions are transitioning to a new manifest version, Manifest V3. This will bring improved privacy for your users—for example, by moving to a model where extensions modify requests declaratively, without the ability to see individual requests. This also improves extension security, as remotely hosted code will be disallowed on Manifest V3. 

  Beginning June 2024, Chrome will gradually disable Manifest V2 extensions running in the browser. An Enterprise policy - ExtensionManifestV2Availability - can be used to test Manifest V3 in your organization ahead of the migration. Additionally, machines on which the policy is enabled will not be subject to the disabling of Manifest V2 extensions until the following year - June 2025 - at which point the policy will be removed.

  You can see which Manifest version is being used by all Chrome extensions running on your fleet using the Apps & extensions usage page in Chrome Enterprise Core. 

  • Chrome 127 on ChromeOS, LaCrOS, Linux, macOS, Windows: Chrome will gradually disable Manifest V2 extensions on user devices. Only those with the ExtensionManifestV2Availability enterprise policy enabled would be able to continue using Manifest V2 extensions in their organization.
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Remove ExtensionManifestV2Availability policy.

    

• Chrome will remove support for macOS 11 

  Chrome 138 will be the last release to support macOS 11; Chrome 139 and later will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

  On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome updated, they need to update their computer to a supported version of macOS. For new installations of Chrome 139 and later, macOS 12 or later will be required.

  • Chrome 139 on Windows, macOS, Linux

    

• Happy Eyeballs V3 

  This launch is an internal optimization in Chrome that implements Happy Eyeballs V3 to achieve better network connection concurrency. Happy Eyeballs V3 performs DNS resolutions asynchronously and staggers connection attempts with preferable protocols (H3/H2/H1) and address families (IPv6/IPv4) to reduce user-visible network connection delay. This feature is gated by a temporary policy HappyEyeballsV3Enabled.

  • Chrome 140 on Android, ChromeOS, Linux, macOS, Windows

    

• 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 that 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 the explainer. 

  In this initial release, IWAs will only be installable through an admin 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.

    

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

  According to the URL Standard specification, 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 (Github).

  • Chrome 141 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, Fuchsia

    

• Safe Browsing API v4 → v5 migration 

  Chrome calls into the Safe Browsing 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. For more details, see Migration From V4 - Safe Browsing. 

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

    

• 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 may use the UiAutomationProviderEnabled enterprise policy starting in 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 146, and will be removed in Chrome 147. 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 146.
  • Chrome 147 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

    

• Agentspace recommendations in the Chrome omnibox 

  This launch helps Enterprise users with their internal information needs by adding Enterprise Search results, such as people, file, or query suggestions, from Agentspace to the Chrome address bar. Results can be shown by default in Chrome's address bar recommendations or only when triggered by a custom keyword. 

  Users can also leverage the keyword mode to trigger actions through Agentspace, such as "help me write an email that summarizes the current project status". 

  The enterprise search provider will be shown when the user types "@" in the address bar. The organization will be able to customize a keyword or shortcut and the icon shown. 

  This can be configured via the EnterpriseSearchAggregatorSettings policy. 

  • Chrome 135 on ChromeOS, Linux, macOS, Windows: Trusted Tester
  • Chrome 138 on ChromeOS, Linux, macOS, Windows: General Availability

  

    

• Inactive profile deletion in Chrome Enterprise Core 

  In June 2025, the inactive period for profile deletion setting started to roll out. In July 2025, the setting will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. When releasing the setting, the inactivity period of time has a default value of 90 days. Meaning that by default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this setting. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If you lower the set value, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is re-activated on a device, that profile will reappear in the console.

  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Policy will roll out in June. Deletion will start in July and the initial wave of deletion will complete by the end of August. After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.

    

• Multiple Identity Support on iOS 

  Chrome on iOS is introducing support for multiple accounts, particularly for managed (work or school) accounts. This update introduces separate browser profiles for each managed account, ensuring strict data separation between work and personal browsing. Regular accounts will continue to share a single profile. 

  This change aims to improve Chrome's enterprise offering and provide a more secure and organized browsing experience, especially for end users with both personal and work accounts on their device. Users will experience a one-time onboarding flow when adding a managed account to the device. They will be able to switch between accounts by tapping on the account particle disk on the New tab page. 

  Admins who enabled Chrome policies on iOS (instructions here) can continue to leverage existing policies.  

  • Chrome 138 on iOS 

  

Upcoming Chrome Enterprise Premium changes

   

• URL filtering capabilities on iOS 

  The current WebProtect URL Filtering capabilities on Desktop are being extended to mobile so that organizations can audit, warn, or block certain URLs or categories of URLs from loading on managed Chrome browsers or managed user profiles on mobile devices. This feature is part of Chrome Enterprise Premium and aims to provide secure and safe internet access for enterprise users on any device. Admins will be able to create URL filtering rules to ensure that employees can only access safe and authorized URLs on iOS devices. Chrome will report URL filtering events and unsafe site events via the Reporting Connector on mobile.

   
  • Chrome 138 on iOS: The URL Filtering feature becomes available on iOS.
  
  

   

• DLP Download Support for File System Access API (FSA) 

  Data Loss Prevention (DLP) protection will be extended to cover files and directories downloaded using the File System Access (FSA) API. This enhancement will ensure that downloads from modern web applications, such as browser-based editors, are scanned according to your organization's DLP rules. Users and websites will receive notifications on scan verdicts, strengthening data security and compliance.

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

ChromeOS 137 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Face control policy on ChromeOS			✓
Crosstalk cancellation		✓
ChromeVox keyboard shortcut to caption audio with braille devices		✓
Event-based log collection			✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Chrome apps changes		✓
Upcoming Native Client (NaCl) deprecation	✓

 

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

   

• Face Control policy on ChromeOS 

  With ChromeOS 137, we introduce a new policy, FaceGazeEnabled, to allow admins to have more control over access to Face Control on an organizational level. 

  For more details, see Use facial gestures & head movements to control your Chromebook with Face control.

   

• Crosstalk cancellation 

  Crosstalk cancellation provides an immersive audio experience when using the internal speaker. Users can feel the audio surrounding their head instead of coming from the geometric position of the internal speaker. Any playable audio content benefits from this feature, especially when playing games or watching videos with spatialized audio. Users experience immersive, surround-sound audio, similar to wearing a headset.

   

• ChromeVox keyboard shortcut to caption audio with braille devices 

  ChromeVox now enables a command that displays spoken text as braille captions on connected (USB or Bluetooth) braille displays. 

  The ChromeVox command is Search + O + C and stands for Search Open Captions. 

  The braille command is space + dots 1-4-7. For more details, see Use a braille device with your Chromebook - Google Accessibility Help. 

   

• Event-based log collection 

  For event-based log collection, when an event occurs—for example, an OS crash or update failure—you'll see a notification on the device details page. You can also view device events in the device details page, to see when events occurred and to get detailed information. Google uploads any logs relevant to the specific event type, which makes troubleshooting more efficient.

  To enable this feature:

  • Turn on the Device system log upload setting.
  • Turn on OS update status reporting—For the Report device OS information setting, select OS update status.
  • Turn on device telemetry reporting on crash information—For the Report device telemetry setting, select Crash information.

  These uploads can happen at most two times per day on one device.

  

Upcoming ChromeOS changes

   

• Chrome apps changes 

  Starting with ChromeOS 138,  planned for stable release on July 22nd, admin-installed Chrome apps in kiosk sessions will be disabled by default. A new policy, KioskChromeAppsForceAllowed, will be available prior to the release of ChromeOS 138 for administrators to re-enable Chrome apps in kiosk sessions. With this policy turned on, Chrome apps in kiosk sessions will be supported through ChromeOS 150.

  Additionally, as a reminder, as early as ChromeOS 139, planned for stable release on August 19th, user-installed Chrome apps will stop working. 

  For more details, see End of support for Chrome apps.

   

• Upcoming Native Client (NaCl) deprecation 

  ChromeOS 138 will be the final release to support Native Client (NaCl) in managed environments with the NaCl allow policy enabled. For devices on the Long-term Support (LTS) channel with this policy active, NaCl support will continue until the LTS Last Refresh in April 2026.

Chrome 136 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Google Lens result presentation updates		✓
Malicious APK download checks (telemetry-only)	✓
Proactive notifications for Chrome Tips on iOS		✓
Custom data directory required for remote debugging	✓
Partitioning :visited links history	✓
Rename string attr() type to raw-string	✓
Update ProgressEvent to use double type for loaded and total	✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
WebAuthn Support for Remote Desktop Clients on managed devices	✓		✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
New reporting connector: CrowdStrike Falcon Next-Gen SIEM	✓		✓
URL filtering capabilities on Android	✓		✓
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Removal of Private Network Access enterprise policies	✓
Remove --load-extension command line switch	✓
Remove SwiftShader fallback	✓
Align error type thrown for payment WebAuthn credential creation: SecurityError => NotAllowedError	✓
Blob URL Partitioning: Fetching/Navigation	✓
Web serial over Bluetooth on Android	✓
Happy Eyeballs V3	✓
Strict Same Origin policy for Storage Access API	✓
Web App Manifest: update_token and update eligibility	✓
Migrate extensions to Manifest V3 before June 2025	✓	✓	✓
Chrome will remove support for macOS 11			✓
Isolated Web Apps	✓		✓
Disallow spaces in non-file:// URL hosts	✓
SafeBrowsing API v4 → v5 migration	✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
IP Address logging and reporting	✓
Inactive profile deletion in Chrome Enterprise Core	✓		✓
Multiple identity support on iOS		✓
Google Agentspace recommendations in Chrome omnibox		✓	✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
URL filtering capabilities on iOS	✓		✓

 

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

   

• Google Lens result presentation updates 

  Search results for Google Lens queries originating from the device camera and from searching images on web pages are presented on a native UI panel that slides from the bottom of the screen. Previously, these answers were presented on a separate web page on a new tab. Admins can control this feature with the existing policy LensCameraAssistedSearchEnabled.

  • Chrome 136 on iOS
   

  

   

   

• Malicious APK download checks (telemetry-only) 

  Chrome on Android now contacts Google about Android Package Kit (APK) files downloaded in Chrome, to verify their safety. This is a telemetry-only experimental state of a feature that will eventually show warnings and block downloads of malicious APK files, to protect users against mobile malware. At this time, the malicious APK download check is telemetry-only: no warnings will be shown and downloads will not be blocked. In telemetry-only mode, the malicious APK download check will only be performed for users enrolled in Enhanced Protection from Google Safe Browsing. 

  This feature can be disabled by setting the Safe Browsing mode to NoProtection (value 0) via the SafeBrowsingProtectionLevel policy.

  • Chrome 136 on Android
   

   

• Proactive notifications for Chrome Tips on iOS 

  Users can now receive Chrome Tips as provisional notifications. Previously, only users who have explicitly opted into Chrome Tips notifications would receive these helpful notifications.

  In this release, Chrome sends these proactively as notifications to users who have installed Chrome on iOS, but have been inactive for several days. In this way, users won't even have to open the app to learn about useful features such as Google Lens or Enhanced Safe browsing. Admins can turn these off by using the policy ProvisionalNotificationsAllowed (policy will be available in Chrome 137).

  • Chrome 136 on iOS
   

   

• Custom data directory required for remote debugging 

  Remote debugging via a TCP port or a pipe is no longer possible in Google Chrome with the default data directory on Windows, Linux, and macOS. A custom data directory must be specified to remotely debug Google Chrome using the --user-data-dir switch, when using the --remote-debugging-pipe or --remote-debugging-port switches.

  We’ve made this change because these remote debugging switches are being abused by infostealers and malware to extract data from Google Chrome. A custom user data directory uses a different encryption key and so it prevents malware stealing encrypted data such as cookies. 

  This change does not affect Chrome for Testing and Chromium.

  • Chrome 136 on Linux, macOS, Windows
   

   

• 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, that is, 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 which improves user experience as well.

  • Chrome 136 on Windows, macOS, Linux, Android
   

   

• Rename attr() type string keyword to raw-string 

  The attr() type argument specifies how the attribute value is parsed into a CSS value. In a recent decision by the W3C CSS Working Group, it was resolved to rename the attr() type string keyword to the more explicit raw-string. If the attribute value is given as the raw-string keyword, or omitted entirely, it causes the attribute’s literal value to be treated as the value of a CSS string, with no CSS parsing performed at all (including CSS escapes, whitespace removal, comments, etc). No value triggers fallback; only the lack of the attribute entirely does. 

  For more details about attr() notation, see CSS Values and Units Module Level 5. 

  • Chrome 136 on Windows, macOS, Linux, Android
   

   

• Update ProgressEvent to use double type for loaded and total 

  The ProgressEvent has attributes loaded and total indicating the progress, and their type is unsigned long long now.

  With this feature, the type for these two attributes is changed to double instead, which gives the developer more control over the value. For example, the developers can now create a ProgressEvent with the total of 1 and the loaded increasing from 0 to 1 gradually. This is aligned with the default behavior of the <progress> HTML element if the max attribute is omitted. For more details, see this Web Hypertext Application Technology working group (WHATWG) discussion on GitHub.

  • Chrome 136 on Windows, macOS, Linux
   

   

• New policies in Chrome browser 

  Policy	Description
  OnSecurityEventEnterpriseConnector	Configuration policy for the OnSecurityEvent Chrome Enterprise Connector (now available on Android).
  WebAuthenticationRemoteDesktopAllowedOrigins	Allowed Origins for Proxied WebAuthn Requests from Remote Desktop Applications.
  ReduceAcceptLanguageEnabled	Control Accept-Language Reduction.
  HappyEyeballsV3Enabled	Use the Happy Eyeballs V3 algorithm.
  EnterpriseRealTimeUrlCheckMode	Check Safe Browsing status of URLs in real time (now available on Android).
  ProvisionManagedClientCertificateForBrowser	Enables the provisioning of client certificates for managed browsers.

   

• Removed policies in Chrome browser 

  Policy	Description
  ThirdPartyBlockingEnabled	Enable third party software injection blocking.
  ProfilePickerOnStartupAvailability	Profile picker availability on startup.

   

   

Chrome Enterprise Core changes

   

• WebAuthn support for Remote Desktop Clients on managed devices 

  This change allows users on managed devices to securely access websites on remote hosts using their local security keys or passkeys. With the new WebAuthenticationRemoteDesktopAllowedOrigins enterprise policy, administrators will be able to specify which remote desktop client applications can make WebAuthn requests on behalf of other origins.

  This addresses the challenge of using local authenticators with remote desktops, thereby enhancing both security and user experience. Administrators configure this policy by providing a comma-separated list of allowed remote desktop client app origins.

  • Chrome 136 on Android, ChromeOS, Linux, macOS, Windows

   

Chrome Enterprise Premium changes

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

   

• New reporting connector: CrowdStrike Falcon Next-Gen SIEM   

  Chrome 136 introduces a new Chrome Enterprise reporting connector for Crowdstrike Falcon Next-Gen SIEM. Admins can configure this connector in the Admin console to forward selected Chrome event data to Crowdstrike for enhanced security monitoring and analysis. This provides more flexibility in SIEM choices and helps improve threat detection.

  • Chrome 136 on ChromeOS, Linux,  macOS, Windows
   

  

   

• URL filtering capabilities on Android   

  WebProtect URL filtering is now extended to Android for Chrome Enterprise Premium customers. This allows admins to apply URL block, warn, or audit rules on managed Android devices via the EnterpriseRealTimeUrlCheckMode policy, providing consistent web content control across platforms. Filter events are reported via the Reporting Connector, and configuration is done in the Admin console.

   
  • Chrome 136 on Android
   

  

   

Upcoming Chrome browser changes

    

• 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 (Github) 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 immediately. 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.

  • 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. This is dependent on a not-yet-defined replacement policy to enable PNA 2.0 being available.

    

• Remove --load-extension command line switch 

  To enhance the security and stability of the Chrome browser for our users, official Chrome branded builds will begin to deprecate the ability to load extensions using the --load-extension command-line flag, starting in Chrome 137. This change aims to mitigate the risks associated with harmful and unwanted extensions. 

  Unpacked extensions can be loaded with the Load unpacked button on the Extensions management page (chrome://extensions/) with Developer mode enabled.

  Developers can still use the --load-extension switch in non-branded builds such as Chromium and Chrome For Testing.

  • Chrome 137 on ChromeOS, Linux, macOS, 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. It is important to test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user. A temporary enterprise policy will be available to revert the change. 

  • Chrome 137 on Linux, macOS: Swiftshader will be disabled on macOS and Linux as early as Chrome 137. Users on machines without a GPU will not be able to use WebGL.
  • Chrome 137 on Windows: SwiftShader will be disabled and replaced with another software WebGL fallback, WARP. Tests depending on the exact pixel values generated by SwiftShader may start failing.

    

• Align error type thrown for payment WebAuthn credential creation: SecurityError => NotAllowedError 

  This change corrects the error type thrown during WebAuthn credential creation for payment credentials. Due to a historic specification mismatch, creating a payment credential in a cross-origin iframe without a user activation would throw a SecurityError instead of a NotAllowedError, which is what is thrown for non-payment credentials. Code that previously detected the type of error thrown, for example, e instanceof SecurityError, would be affected. Code that just generally handles errors during credential creation, for example, catch (e), will continue to function correctly.

  • Chrome 137 on Windows, macOS, Linux, Android

    

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

    

• Web serial over Bluetooth on Android 

  This feature allows web pages and web apps to connect to serial ports over Bluetooth on Android devices. Chrome on Android now supports Web Serial API over Bluetooth RFCOMM. Existing enterprise policies (DefaultSerialGuardSetting, SerialAllowAllPortsForUrls, SerialAllowUsbDevicesForUrls, SerialAskForUrls, and SerialBlockedForUrls) on other platforms are enabled in future_on states for Android. All policies except SerialAllowUsbDevicesForUrls will be enabled after the feature is enabled. SerialAllowUsbDevicesForUrls will be enabled in a future launch after Android provides system level support of wired serial ports.

  • Chrome 137 on Android

    

• Happy Eyeballs V3 

  This launch is an internal optimization in Chrome that implements Happy Eyeballs V3 to achieve better network connection concurrency. Happy Eyeballs V3 performs DNS resolutions asynchronously and staggers connection attempts with preferable protocols (H3/H2/H1) and address families (IPv6/IPv4) to reduce user-visible network connection delay. This feature is gated by a temporary policy HappyEyeballsV3Enabled.

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

    

• Strict Same Origin policy for Storage Access API 

  This feature updates the Storage Access API semantics to strictly follow the Same Origin policy, to enhance security. This means using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default. Note: the CookiesAllowedForUrls policy or Storage Access Headers might still be used to unblock cross-site cookies.

  • Chrome 138 on Windows, macOS, Linux, Android

    

• Web App Manifest: update_token and update eligibility 

  Introduces an update_token field and updates the eligibility algorithm to the manifest spec. This makes the update process more deterministic and predictable, giving the dev more control over whether (and when) updates should apply to existing installations, and allowing removal of the update check throttle that user agents currently need to implement to avoid wasting network resources.

  • Chrome 138 on Windows, macOS, Linux
  • Chrome 139 on Android

    

• Migrate extensions to Manifest V3 before June 2025 

  Extensions must be updated to leverage Manifest V3. Chrome extensions are transitioning to a new manifest version, Manifest V3. This will bring improved privacy for your users—for example, by moving to a model where extensions modify requests declaratively, without the ability to see individual requests. This also improves extension security, as remotely hosted code will be disallowed on Manifest V3. 

  Beginning June 2024, Chrome will gradually disable Manifest V2 extensions running in the browser. An enterprise policy, ExtensionManifestV2Availability, can be used to test Manifest V3 in your organization ahead of the migration. Additionally, machines on which the policy is enabled will not be subject to the disabling of Manifest V2 extensions until the following year - June 2025 - at which point the policy will be removed.

  You can see which Manifest version is being used by all Chrome extensions running on your fleet using the Apps & extensions usage page in Chrome Enterprise Core. 

  • Chrome 127 on ChromeOS, LaCrOS, Linux,  macOS, Windows: Chrome will gradually disable Manifest V2 extensions on user devices. Only those with the ExtensionManifestV2Availability enterprise policy enabled would be able to continue using Manifest V2 extensions in their organization.
  • Chrome 139 on ChromeOS, Linux, macOS, Windows: Removal of ExtensionManifestV2Availability policy.

    

• Chrome will remove support for macOS 11 

  Chrome 138 will be the last release to support macOS 11; Chrome 139+ will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

  On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome be updated, they need to update their computer to a support version of macOS.

  For new installations of Chrome 139+, macOS 12+ will be required.

  • Chrome 139 on Windows, macOS, Linux

    

• 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 that 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 the Isolated Web Apps explainer on GitHub.

  In this initial release, IWAs will only be installable through an admin 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.

    

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

  According to the URL Standard specification, 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 (Github).

  Thus this status entry tracks the work to bring Chromium closer to spec compliance by forbidding spaces for non-file URLs only.

  • Chrome 141 on Android, ChromeOS, LaCrOS, Linux, macOS, Windows, Fuchsia

    

• SafeBrowsing API v4 → 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. For more details, see Migration From V4 - Safe Browsing. 

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

    

• 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 can use the UiAutomationProviderEnabled enterprise policy starting in 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 146, and will be removed in Chrome 147. 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 146.
  • Chrome 147 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

    

• IP Address logging and reporting 

  Chrome Enterprise will enhance security monitoring and incident response capabilities by collecting and reporting local and remote IP addresses and sending those IP addresses to the Security Investigation Tool (SIT) logs. In addition, Chrome Enterprise will allow admins to optionally send the IP addresses to first-party and third-party security information and event management (SIEM) providers via the Chrome Enterprise reporting connector. For more details, see Manage Chrome Enterprise reporting connectors. This will be available for Chrome Enterprise Core and Chrome Enterprise Premium customers. 

  • Chrome 137 on Windows, macOS, Linux

    

• Inactive profile deletion in Chrome Enterprise Core 

  In April 2025, the inactive period for profile deletion policy starts rolling out. In June 2025 (Chrome 138), the policy will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. When releasing the policy, the inactivity period of time has a default value of 90 days. Meaning that by default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this policy. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If you lower the set policy value, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is reactivated on a device, that profile will reappear in the console.

  • Chrome 138 on Android, ChromeOS, Linux, macOS, Windows: Policy will roll out in April. Deletion will start in June and the initial wave of deletion will complete by the end of July. After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.

    

• Multiple identity support on iOS 

  Chrome on iOS is introducing support for multiple accounts, particularly for managed (work/school) accounts. This update introduces separate browser profiles for each managed account, ensuring strict data separation between work and personal browsing. Regular accounts will continue to share a single profile. This change aims to improve Chrome's enterprise offering and provide a more secure and organized browsing experience, especially for end users with both personal and work accounts on their device. Users will experience a one-time onboarding flow when adding a managed account to the device. They will be able to switch between accounts by tapping on the account particle disk on the New tab page. 

  Admins can continue to use the following existing policies to manage iOS accounts: 

  • Chrome on iOS: Allows admins to apply policies to signed in users on iOS. For more information, see Turn on Chrome browser management (Android and iOS).
  • ProfileSeparationDataMigrationSettings: This policy affects the onboarding experience and how prior browsing data is handled when a user adds a work profile. 
  • BrowserSignin: It allows you to specify if the user can sign in to Google Chrome. 
  • RestrictAccountsToPatterns: Controls which accounts are visible on the device.

   

  • Chrome 138 on iOS

  

   

• Google Agentspace recommendations in the Chrome omnibox 

  To help enterprise users with their internal information needs, Admins will soon be able to add  enterprise search results, such as people, file, or query suggestions, from Google Agentspace to the Chrome address bar. Results can be shown by default in Chrome's address bar recommendations or only when triggered by a custom keyword. Users can also use keyword mode to trigger actions through Agentspace, such as help me write an email that summarizes the current project status. 

  The enterprise search provider will be shown when the user types @ in the address bar. The organization will be able to customize a keyword or shortcut and the icon shown. 

  This can be configured via the policy called EnterpriseSearchAggregatorSettings. 

  • Chrome 139 on ChromeOS, Linux, macOS, Windows

  

   

Upcoming Chrome Enterprise Premium changes

   

• URL filtering capabilities on iOS 

  The current WebProtect URL filtering capabilities on Desktop are being extended to mobile so that organizations can audit, warn, or block certain URLs or categories of URLs from loading on managed Chrome browsers or managed user profiles on mobile devices. This feature is part of Chrome Enterprise Premium and aims to provide secure and safe internet access for enterprise users on any device. Admins will be able to create URL filtering rules to ensure that employees can only access safe and authorized URLs on iOS devices. Chrome will report URL filtering events and unsafe site events via the Reporting Connector on mobile.

   
  • Chrome 137 on iOS: In this milestone, the URL Filtering feature will be launched on iOS for Chrome Enterprise Premium customers. This will enable administrators to manage which URLs can be accessed on managed Chrome browsers or profiles on company-owned or BYOD iOS devices.

    Key changes include:

    - Admins can block, warn, or audit users when accessing certain sites or categories.

    - End users will see interstitial pages when attempting to visit blocked or warned URLs.

    - Chrome will report URL filtering events.

    - Updates to the chrome://management page will reflect the new functionality.

  
  
  

ChromeOS 136 release summary

 

ChromeOS updates	Security/ Privacy	User productivity/ Apps	Management
Quick Share enhancements		✓
Admin initiated Chrome Remote Desktop (CRD) sessions			✓
Upcoming ChromeOS changes	Security/ Privacy	User productivity/ Apps	Management
Event-based device log collection for troubleshooting (Admin console)			✓
Face control policy 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 Share enhancements 

  As early as ChromeOS 136, Quick Share extends Visible to everyone mode duration to a maximum of 10 minutes from 5. This feature allows your device to share files with and receive files from Android devices and other Chromebooks. Users can set device visibility, enter Visible to everyone mode, toggle Quick Share, and go to the Quick Share settings page, all from quick settings. This setting can be managed with the NearbyShareAllowed policy.

  

   

• Admin initiated Chrome Remote Desktop (CRD) sessions 

  Starting in ChromeOS 136, auto-approved Chrome Remote Desktop (CRD) connections allow IT teams to better support their ChromeOS users.

  In previous releases, users had to manually accept remote CRD connections via a notification to allow for remote connections. The new feature automatically accepts remote connections after 30 seconds (if the user does not decline) while ensuring user privacy through a combination of measures, for example, requirement of connection to managed network and end user activity in the last 5 minutes. Auto-accepted CRD connections are expected to significantly streamline support workflows by removing the need for additional end user intervention.

  

Upcoming ChromeOS changes

   

• Event-based device log collection for troubleshooting (Admin console) 

  To help troubleshoot device issues (like crashes or failed OS updates), ChromeOS automatically collects and uploads device logs. This happens when these specific settings are turned on:

  • Enable device system log upload: turns on the overall log collection
  • Report device OS information -> OS update status: collects data about OS updates
  • Report device telemetry -> Crash information: gathers fatal crash information

  As early as ChromeOS 137, when a problem occurs, IT admins will see a notification with a direct link to the uploaded logs on the ChromeOS device's details page in the Admin console. You can also see a history of device events. Log uploads happen a maximum of two times a day, and each file is typically 400KB to 1MB in size.

  For details, see these articles in the Chrome Enterprise and Education Help Center: 

  • Remote log collection for ChromeOS devices
  • View ChromeOS Device List and Details 

   

• Face control policy on ChromeOS 

  With ChromeOS 137, we will introduce a new policy to allow admins to have more control over access to face control on an organisational level. 

  For more details, see Use facial gestures & head movements to control your Chromebook with face control.

Chrome 135 release summary

 

Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
3P profile enrollment migrates to OIDC auth code flow	✓
Auto-deletion of downloads for Chrome on iOS	✓
Better password form detection with ML	✓
Client’s LLM assistance in mitigating scams	✓
Deprecate mutation events	✓
Download file type extension-based warnings - documentation correction	✓
Extensions improvements on Chrome Desktop	✓	✓
Generic Device Trust Connector	✓
Remove 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	✓
Create service worker client and inherit service worker controller for srcdoc iframe	✓
HSTS tracking prevention	✓
Remove deprecated navigator.xr.supportsSession method	✓
Remove --load-extension Command Line switch in Google Chrome	✓
New policies in Chrome browser			✓
Removed policies in Chrome browser			✓
Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Apple extensible SSO support for Chrome on macOS		✓	✓
New content on the Chrome Web Store Discover page for managed users		✓	✓
Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
No updates in Chrome 135.
Upcoming Chrome browser changes	Security/ Privacy	User productivity/ Apps	Management
Remote debugging port custom data directory requirement	✓
Blob URL Partitioning: Fetching/Navigation	✓
Deprecate getters of Intl Locale Info API	✓
FedCM updates			✓
Partitioning :visited links history	✓
Strict Same Origin Policy for Storage Access API	✓
Remove SwiftShader fallback	✓
Disallow spaces in non-file:// URL host	✓
Chrome will remove support for macOS 11			✓
Isolated Web Apps	✓
SafeBrowsing API v4 to v5 migration	✓
UI Automation accessibility framework provider on Windows		✓
Upcoming Chrome Enterprise Core changes	Security/ Privacy	User productivity/ Apps	Management
Improved Admin console reporting performance and scalability			✓
New remote commands and CSV export for the Managed Profile List			✓
New Overview landing page for Chrome Enterprise Core			✓
IP Address logging and reporting	✓
Inactive profile deletion in Chrome Enterprise Core	✓		✓
Upcoming Chrome Enterprise Premium changes	Security/ Privacy	User productivity/ Apps	Management
URL filtering on iOS and Android	✓
Refactor DLP rules user experience	✓
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

 

   

• 3P profile enrollment migrates to OIDC auth code flow 

  Chrome 135 migrates the landing page for profile registration from the marketing website to a dynamic website. This update also migrates the OpenID Connect (OIDC) implicit flow to an auth code flow. This aims to improve both the security and the user experience for third party (3P) managed profiles.

  • Chrome 135 on Windows

   

• Auto-deletion of downloads for Chrome on iOS 

  Users of Chrome browser on iOS can now choose to automatically delete their browser downloads on a scheduled basis.

  This feature is likely to both improve device performance related to storage capacity, and to improve privacy by automating the deletion of files that users might otherwise forget to on their own.

  • Chrome 135 on iOS
    Initial experiment at 1% in 135 for Chrome for iOS only. No planned rollout for other platforms.
   

   

• Better password form detection with ML 

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

   

• Client’s LLM assistance in mitigating scams 

  Users on the web are facing significant amounts and varieties of scams on a daily basis. To combat these scams, Chrome 135 uses on-device Large Language Models (LLMs) to identify scam websites for Enhanced protection users. Chrome sends the page content to an on-device LLM to infer security-related signals for that page. Chrome then sends these signals to Safe Browsing server side for a final verdict. When turned on, Chrome might consume more bandwidth to download the LLM.

  • 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.
  • Chrome 135 on Linux, macOS, Windows
    Show the warnings to the user based on the server verdict which uses the brand and intent summary of the page that requested keyboard lock API.
   

   

• 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 135, ending March 25, 2025.
  • A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 135.
  • Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.

   

• Download file type extension-based warnings - documentation correction 

  We’ve updated the policy documentation for ExemptDomainFileTypePairsFromFileTypeDownloadWarnings to correctly reflect its interaction with the DownloadRestrictions policy. The behavior in Chrome has not changed.

  The behavior is: ExemptDomainFileTypePairsFromFileTypeDownloadWarnings can specify exemptions that override DownloadRestrictions settings for blocking dangerous file types. Other types of security measures specified by DownloadRestrictions, such as blocking malicious downloads, cannot be overridden by ExemptDomainFileTypePairsFromFileTypeDownloadWarnings.

   
  • Chrome 135 on ChromeOS, Linux, macOS, Windows

    No Chrome changes - documentation change only.

   

• Extensions 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, 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. For more details, see Sign in and sync in Chrome.

  • Chrome 135 on Linux, macOS, Windows

   

• Generic Device Trust Connector 

  Integrations created through the Device Trust Connector allow customers to implement granular controls for authentication into enterprise resources, for example, SaaS apps or your corporation intranet, based on the properties of the end user’s device and browser instance sent by Chrome. For more details, see Manage Chrome Enterprise device trust connectors. 

  • Chrome 135 on Windows

   

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

  Chrome 135 removes the InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed policies, which loosen PNA 1.0 restrictions. 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, we plan to remove the ThirdPartyBlockingEnabled policy 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. For more details, see Manage who can sync browser settings.

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

  • 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 have 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 applies to regular mode only when set to false, not Incognito mode. There are no changes when the policy is true or unset. There are also no changes to the CookieAllowedForUrls policy, which continues 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

   

• Create service worker client and inherit service worker controller for srcdoc iframe 

  Srcdoc context documents were previously not service worker clients and were not covered by their parent page’s service worker. This resulted in some discrepancies (for example, Resource Timing reports the URLs that these documents load, but the service worker doesn’t intercept them). 

  To fix these discrepancies, Chrome 135 creates service worker clients for srcdoc iframes and makes them inherit the parent page's service worker controller.

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

  In Chrome 135, HSTS tracking prevention mitigates 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 prevents 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 

  Chrome 135 removes the navigator.xr.supportsSession method, which 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

   

• Remove --load-extension command line switch in Google Chrome 

  Starting in Chrome 137, to enhance the security and stability of the Chrome browser for our users, official Chrome branded builds will be deprecating the ability to load extensions via the --load-extension command-line flag. This change aims to mitigate the risks associated with harmful and unwanted extensions. 

  With developer mode enabled, you can load unpacked extensions using the Load Unpacked button on the extension management page (chrome://extensions/). Developers can still use the --load-extension switch in non-branded builds such as Chromium and Chrome For Testing. 

  • Chrome 135 on Windows, macOS, Linux, ChromeOS

   

• New policies in Chrome browser 

  Policy	Description
  DownloadRestrictions	Blocks malicious downloads and dangerous file types
  PartitionedBlobUrlUsage	Choose whether Blob URLs are partitioned during fetching and navigations
  ExtensibleEnterpriseSSOBlocklist	Blocklist of identity providers that cannot use Extensible Enterprise SSO for the browser
  EnterpriseSearchAggregatorSettings	Enterprise search aggregator settings (Beta)
  ProfilePickerOnStartupAvailability	Profile picker availability on startup

   

   

• Removed policies in Chrome browser 

  Policy	Description
  ThirdPartyBlockingEnabled	Enable third party software injection blocking
  KeyboardFocusableScrollersEnabled	Enable keyboard focusable scrollers

   

   

Chrome Enterprise Core changes

   

• Apple extensible SSO support for Chrome on macOS 

  Chrome 135 on macOS enables seamless authentication for identity providers that are enabled via an OS-configured Enterprise Single Sign On (SSO) extension. For this initial release, Chrome allows 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. For more details, see Use Apple Extensible Single Sign-on support in Chrome.

   
  • As early as Chrome 135 on macOS
   

   

• New content on the Chrome Web Store Discover page for managed users 

  The Chrome Web Store now displays new curated collections related to productivity, project management and collaboration on the Discover page for managed users. The goal is to help end-users find useful and more relevant work-related extensions faster.

  As an Administrator, you can control the display of the Chrome Web Store for your managed users using the Chrome Web Store settings (previously announced in Chrome 132).

   

  • Chrome 135: Gradual release as early as April 1, 2025.

 

Chrome Enterprise Premium changes

 

There are no updates for Chrome Enterprise Premium in Chrome 135.

 

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

Upcoming Chrome browser changes

 

    

• Remote debugging port custom data directory requirement 

  Remote debugging via a TCP port or a pipe will no longer be possible in Google Chrome with the default data directory on Windows, Linux and macOS.

  A custom data directory must be specified to remotely debug Google Chrome using the --user-data-dir switch, when using the --remote-debugging-pipe or --remote-debugging-port switches.

  The motivation for this change is because these remote debugging switches are being abused by infostealers and malware to extract data from Google Chrome. A custom user data directory uses a different encryption key and so it becomes no longer possible for malware to steal encrypted data such as cookies.

  This change does not affect Chrome for Testing and Chromium.

   
  • Chrome 136 on 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 136 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 plan to remove the deprecated getters and relaunch the renamed functions.

  • Chrome 136 on Windows, macOS, Linux, Android

    

• FedCM updates 

  As early as Chrome 136, Federated Credential Management API (FedCM) will be able to show multiple identity providers in the same dialog. This will provide developers with a convenient way to present all supported identity providers to users. We are planning to first tackle the simple case of having all providers in the same get() call.

  We plan to remove support for adding another account in FedCM passive mode. This feature allows showing a Use another account button alongside other IdP accounts in the chooser. The feature is currently unused, and UX conversations indicate that supporting this leads to a more complicated flow without much benefit. This feature will still work in FedCM active mode.

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

    

• Strict Same Origin Policy for Storage Access API 

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

    

• 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

 

    

• Chrome will remove support for macOS 11 

  Chrome 138 will be the last release to support macOS 11; Chrome 139+ will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security.

  On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome be updated, they need to update their computer to a support version of macOS.

  For new installations of Chrome 139+, macOS 12+ will be required.

  • Chrome 139 on Windows, 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.

    

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

    

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

    

• Improved Admin console reporting performance and scalability for large customers 

  Chrome Enterprise Core will roll out software infrastructure changes that aim to improve the performance, accuracy and scalability of many pages and reports in the Admin console. The pages and reports impacted in the Admin console include (but are not limited to): 

  • Versions report
  • Apps & Extension Usage report
  • Extension Details page
  • Chrome Insights page for browsers
   

  The changes are planned to gradually roll out between April and July 2025.

  • As early as April 2025, until July 2025

    

• New remote commands and CSV export for the Managed Profile List 

  We plan to add a CSV export action and Clear cache and Clear cookies remote commands on the Managed profile list. You will be able to select one or multiple profiles and perform a remote command.

  • CSV Export: As early as Chrome 135 on Android, Linux, macOS, Windows
  • Remote Commands: As early as Chrome 136 on Linux, macOS, Windows

    

• New Overview landing page for Chrome Enterprise Core 

  This new overview page will be located in the Chrome browser section of the Admin console and it will display insightful information about your deployment, such as a summary of your browser and profiles deployment, a summary of Chrome versions reported and extensions installed. For example, those insights will allow you to quickly identify inactive browsers and browsers with a pending update. You will also be able to quickly see your queue of extension requests and review extensions that have been configured.

  • As early as Chrome 135 for early Trusted Testers access

    

• IP Address logging and reporting 

  Chrome Enterprise is enhancing its security monitoring and incident response capabilities by collecting and reporting local and remote IP addresses and sending those IP addresses to the Security Investigation Logs (SIT). In addition, Chrome Enterprise will allow admins to optionally send the IP addresses to both in-house and third-party Security and Information Event Management (SIEM) providers via the Chrome Enterprise Reporting connector.

  This will be available for Chrome Enterprise Core customers. 

  • Chrome 136 on Windows, macOS, Linux

    

• Inactive profile deletion in Chrome Enterprise Core 

  In April 2025 (Chrome 136), the inactive period for profile deletion policy will start rolling out. In June 2025 (Chrome 138), the policy will begin to automatically delete managed profiles in the Admin console that have been inactive for more than the defined inactivity period. When releasing the policy, the inactivity period of time has a default value of 90 days. Meaning that by default, all managed profiles that have been inactive for more than 90 days are deleted from your account. Administrators can change the inactive period value using this policy. The maximum value to determine the profile inactivity period is 730 days and the minimum value is 28 days.

  If you lower the set policy value, it might have a global impact on any currently managed profiles. All impacted profiles will be considered inactive and, therefore, be deleted. This does not delete the user account. If an inactive profile is re-activated on a device, that profile will reappear in the console.

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

    Policy will roll out in April (Chrome 136). Deletion will start in June (Chrome 138) and the initial wave of deletion will complete by the end of July (Chrome 139). After the initial deletion rollout, inactive profiles will continue to be deleted once they have reached their inactivity period.