Breaking Changes & Deprecations Timeline

Deprecate and remove WebRTC peer connection method Deprecated Enterprise: Low

Starting in Chrome 160, Chrome will remove support for the `RTCPeerConnection.createDTMFSender()` method on Windows, macOS, Linux, ChromeOS, and Android. This is a legacy, non-standard method that is obsolete and no longer conforms to the official _Real-time communication for the web_([WebRTC](https://webrtc.org/)) standard. Removing it ensures better compatibility and security across different web browsers. **Before Chrome 160** is deployed, admins should test any internal or third-party web communication applications that rely on WebRTC.

Intent stage: None

This is a legacy and obsolete method that does not exist in the WebRTC spec and the only major engine implementing it is Blink. Removing it is part of Interop 2026.

More specific protocol filtering in Digital Credential API Deprecated Enterprise: Low

Chrome 151 began deprecating support for unspecified presentation and issuance protocols in the **Digital Credentials API**; final removal is scheduled for Chrome 160. The Digital Credentials API was originally designed to be an opaque pipeline for arbitrary exchange protocols. In November 2025, the [FedID WG resolved](https://github.com/w3c-fedid/digital-credentials/issues/396) to change this so that the spec normatively referenced only a specific set of exchange protocols. The removal of support for arbitrary, opaque pipelines ensures that only verified protocols are used, enabling a more robust privacy and security threat model for identity verification. This change aligns Chromium with updated industry specifications that normatively reference only a specific set of exchange protocols.

Intent stage: None

When arbitrary protocols were supported in the spec it made security and privacy analyses less precise since there was more ambiguity about how the API could be used in practice. In order to get more broad browser industry alignment on the privacy and security properties of the API, the specification was changed to normatively reference specific exchange protocols (which themselves have privacy and security threat models associated with them). Chromium is updating to reflect this specification change because of the reduction in potential for confusion and compatibility issues by matching other browser engines, and because (contrary to original expectations) this extra flexibility was not actually being used by anyone in production.

Remove FencedFrame element and window.fence APIs Deprecated

Fenced frames are nested frames that embed content onto a page without the ability to share data between the fenced frame and its embedder. window.fence APIs include Fenced frames Ads reporting (FFAR) JS APIs that were created for privacy-safe ads reporting from FFs created using Protected Audience and SelectURL and getNestedConfigs() to support PA component ads. This intent is for removing both of these. Fenced frames element removal will be two step as detailed below. With the removal (or stub API replacement) of PA and selectURL, FFs can no longer be navigated and thus it is safe to remove them. Fenced frames are only able to be navigated using the urn:uuid in a FencedFrameConfig[1], which can only be created using the return values from runAdAuction and selectURL. These APIs are being deprecated and removed in M152 as per the following Intent threads: Protected Audience[2], Shared Storage[3]. Plan: Given that the fenced frames element can no longer be navigated, we propose removing the element from the code in the following phases: 1. M156: Keep the fenced frame element and its associated IDL dependencies as stubs. This is to ensure no JS call throws, e.g.calling fenced-frame-element.config.setSharedStorageContext(). 2. M156: In the same milestone we will also stub the window.fence APIs completely. Since there is no FF document navigation, these APIs cannot be invoked anymore, so it will be a no-op. 3. M157 Canary/Beta: Begin a controlled rollout of the stub FF HTML element removal via a field trial. Note that removing the element will resolve it to HTMLUnknownElement. At this point we are requesting approvals for all of the above steps. 4. M157 Stable: Assuming there are no regressions or breakage after reaching 1% stable, we will request additional approval for full removal of the FF element. [1]https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/fenced_frame/fenced_frame_config.idl [2]https://groups.google.com/a/chromium.org/g/blink-dev/c/k_nubsMb97g/m/awPD4IGLBAAJ [3]https://groups.google.com/a/chromium.org/g/blink-dev/c/uh5Ke6qyegc/m/WFTFnhyJBAAJ

Deprecate and Remove: document.requestStorageAccessFor Deprecated

The requestStorageAccessFor (rSAFor) API is an extension to the Storage Access API that allows a top-level site to request access to unpartitioned ("first-party") cookies on behalf of embedded sites. Browsers will have discretion to grant or deny access, with mechanisms like Related Website Sets (RWS) membership as a potential signal. This allows for use of the Storage Access API by top-level sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove rSAFor, as it is only usable in Chrome to request storage access between RWS sites. Related Website Sets will also be deprecated via a separate intent.

Deprecate and Remove: Related Website Sets (RWS) Deprecated

Related Website Sets (RWS), formerly known as First Party Sets, provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the Storage Access API (SAA) and requestStorageAccessFor (rSAFor). RWS was designed for use in a browser without third-party cookies. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove Related Website Sets (RWS). Once RWS is deprecated; existing usage of SAA across contexts within a set will fall back to the API’s behavior outside of RWS as specified here. The difference in SAA behavior outside of RWS is well illustrated in our developer blogpost here. The companion rSAFor API will also be deprecated via a separate intent. We also intend to deprecate RWS-related Chrome Enterprise policies, as well as the chrome.privacy.relatedWebsiteSetsEnabled extension API; and will follow the relevant processes.

Deprecate and Remove Protected Audience Deprecated

The Protected Audience API provides a method of interest-group advertising without third-party cookies or user tracking across sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Protected Audience API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page).

Deprecate and Remove: Shared Storage API Deprecated

The Shared Storage API is a privacy-preserving web API to enable storage that is not partitioned by first-party site. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Shared Storage API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page). [0]: https://privacysandbox.com/news/privacy-sandbox-next-steps/

Deprecate and remove: Attribution Reporting API Deprecated

The Attribution Reporting API is a privacy-preserving web API designed to measure ad conversions without third-party cookies or user tracking across sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Attribution Reporting API (along with other Privacy Sandbox APIs). [0]: https://privacysandbox.com/news/privacy-sandbox-next-steps/

Remove non-standard navigations targeted at _current Deprecated

Blink currently supports navigations targeted at "_current", this feature should be removed as it is non-standard. Usage of this feature is minimal (less than ~0.00009%), see https://chromestatus.com/metrics/feature/timeline/popularity/2835.

Deprecate and remove: Private Aggregation API Deprecated

The Private Aggregation API is a generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. It was originally designed for a future without third-party cookies. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove the Private Aggregation API (along with certain other Privacy Sandbox APIs, as outlined on the Privacy Sandbox feature status page[0]). This API is only exposed via the Shared Storage and Protected Audience APIs, which are also planned to be deprecated and removed. So, no additional work will be required for Private Aggregation. [0]: https://privacysandbox.google.com/overview/status

Chrome 151 removes support for macOS 12 Deprecated Enterprise: High

Chrome 150 is the last release to support macOS 12; Chrome 151+ will no longer support macOS 12, which is outside of its support window with Apple. To maintain security, it is essential to run Chrome browser on a supported operating system. On Macs running macOS 12, Chrome continues to work, showing a warning infobar, but it will not update any further. If users wish to have Chrome updated, they need to update their computer to a supported version of macOS. For new installations of Chrome 151+, macOS 13+ is required.

Remove Inline XSLT for production of SVG Deprecated

A specially crafted XML file may contain an XSL stylesheet that transforms generic XML data into an SVG file. Example: https://gist.github.com/drott/1fc70b3c7f0ac314d1fe2e5beecc5490?short_path=1c60adf This is a special case of XSLT processing that according to recently introduced use counters XSLPIInSVGImage (UseCounter id 5777), XSLPIInSVGStandaloneDoc (UseCounterId 5778) we consider virtually non-existant on the web and which we want to deprecated and remove before fully phasing out XSLT. This is rolled out in sync with experimental testing of the Rust based XML parser. This will not be immediately rolled out to 100% in the marked shipping release version. Update: https://crrev.com/c/7502375 introduced metrics that measure this feature, and it was found that this feature was not used. Which enables us to proceed with launching the Rust XML parser for SVG scenarios, too, which is https://chromestatus.com/feature/5309598397497344 .

Intent stage: None

Support for this feature is spotty. It seems hard to find a reason why the image resource could not be static and completed on the server side instead of requiring client side processing. Firefox and Chrome allow inline XSLT to generate SVG for a standalone SVG doc (top level navigated to example.svg), but do not process the XSLT when the image is referenced as an external image. (Safari does support this use case.) Continuing to allow usage of this feature blocks transitioning to secure XML parsing through Rust. We previously disallowed use of XSLT as an external resource loaded from an image in https://chromium-review.googlesource.com/c/chromium/src/+/6943450 - this is the next step. (without I2D/I2R) Newly introduced use counters show that usage of this functionality on the web is virtually non-existent. In Dev and Canary, the use counters show the value of 0. XSLPIInSVGImage (UseCounter id 5777), XSLPIInSVGStandaloneDoc (UseCounterId 5778) I propose to remove this functionality immediately in M147. Removing the functionality allows us to proceed with experimentation of the Rust XML parser for SVG scenarios as well, increasing robustness and improving confidence in our performance and compatibility data on the new parser.

Chrome removes support for obsolete virtual cameras on macOS Deprecated Enterprise: Low

As early as Chrome 145, Chrome will remove support for obsolete virtual cameras for all macOS releases that it supports. On macOS, modern virtual cameras are built using the [Core Media IO](https://developer.apple.com/documentation/coremediaio) framework, which has been available since macOS 12.3. Apple has performed outreach, and all modern virtual camera software has been migrated to use this [Core Media IO framework](https://developer.apple.com/videos/play/wwdc2022/10022/). Obsolete virtual cameras, built as DAL plugins, have been blocked by macOS itself starting with macOS 14.1 (2023), and have been unsupported in Safari since 2018, if not earlier. Chrome will remove support for obsolete virtual cameras for all macOS releases that it supports. This allows Chrome to improve security by fully disallowing loading of third-party libraries into Chrome processes.

Intent stage: None

Remove BMP Extension for Embedding JPEG-or-PNG-in-BMP Deprecated

Chrome will remove BMP extension for embedding JPEG-or-PNG-in-BMP for the following reasons: Security ======== We have compelling evidence that surprising and rarely-used support for nesting formats is a path to security bugs. Such a possibility is especially worrying for BMP, which is otherwise considered a pretty simple format. Interoperability ================ * Today only Chrome supports this BMP extension. (Tested with Chrome 141.0.7390.134, Firefox 143.0.4 and 144.0.2, Safari 18.6) * There is no official spec. * Mozilla Developer Network advises against using BMP in general, and this BMP extension specifically (calling it only “theoretically supported”) No usage ======== No usage has been registered via UMA data (see https://crbug.com/452667935). Not just minimal usage, but no usage whatsoever. Viable alternatives =================== If our research data missed an existing usage of JPEG-or-PNG-embedded-in-BMP then we kindly ask web developers to use PNG and/or JPEG images **directly** rather than embedding them inside a BMP format.

Intent stage: None

We plan to: * Have no deprecation period (because UMA registered no usage). * Ship the removal behind a Finch kill switch / behind an enabled-by-default `base::Feature`.

Externally loaded entities in XML parsing Deprecated

Chrome synchronously fetches external XML entities/DTDs and incorporates them into parsing under specific circumstances. I propose to remove this functionality. http/tests/security/contentTypeOptions/xml-external-entity.xml gives an example: External entities can be defined in the trailing part of the DOCTYPE statement - and then refer to resources that are to be synchronously loaded and included as context when parsing XML. Another syntax example would be a DOCTYPE that, using the SYSTEM keyword followed by a URL pointing to a DTD which contains additional entity definitions. Such external load requests are passed up from the parser. According to https://www.w3.org/TR/xml/#proc-types non-validating processor are not required to read external entities. We plan to deprecate loading of external entity definitions in XML documents that do not use XSLT.

Intent stage: None

The usage has continuously decreased and is at an extremely low level of 0.000015, compare: https://chromestatus.com/metrics/feature/timeline/popularity/529 We intend to improve the security of XML parsing in Chrome. (See internal go/chrome_x_mitigation). In this effort, we intend to replace libxml2 as the XML parser with an XML parser written in Rust (crate "xml"). The Rust-based XML parser we intend to migrate to, does not support external entities and we don't think it's necessary or desirable to implement this feature. Synchronous loads during parsing are considered inefficient, and can be avoided by inlining the needed entity definitions. As usage is so low, Firefox never supported this, I propose to deprecate in 144, and remove in 145.

Deprecate savedTabGroups as individual value in SyncTypesListDisabled Deprecated Enterprise: Low

To align desktop and ChromeOS behavior with mobile and to simplify sync management, the individual `savedTabGroups` datatype is now deprecated and is no longer an individually customizable value within the [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) policy. Previously, the [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) enterprise policy allowed administrators to disable the synchronization of `savedTabGroups` datatype on desktop and ChromeOS platforms. On mobile platforms, however, tab group synchronization is already managed by the `tabs` datatype. Starting with Chrome 144, if your [SyncTypesListDisabled](https://chromeenterprise.google/policies/#SyncTypesListDisabled) policy disables either `tabs` or `savedTabGroups`, both data types are now considered disabled. This means that disabling tabs also disables saved tab groups, and the other way around. The `savedTabGroups` value is entirely removed from the list of supported datatypes for this policy. For admins who have saved tab groups disabled, and intend to keep this behavior, make sure to explicitly disable the `tabs` datatype. This guarantees the desired behavior before the `savedTabGroups` value is fully removed.

Intent stage: None

Deprecate getters of Intl Locale Info Deprecated

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, minimun day in the first week), and text direction hour cycle used in the locale. https://github.com/tc39/proposal-intl-locale-info We ship our implementation in m99 (https://chromestatus.com/feature/5566859262820352 ) . But later on the propose made some change in Stage 3 and move several getters to functions. We need to remove the deprecated getters and relaunch the renamed functions

Intent stage: None

Intl Locale Info API advanced to Stage 3 in Stage 3 in 2021-04 TC39 and v8 ship with that in m99 But in 2022-11 TC39 meeting , TC39 decide to change getters to functions and the spec change merged in Jan 31, 2023 https://github.com/tc39/proposal-intl-locale-info/pull/67 Since Mozilla have not yet launched any thing of this spec yet and Safari update their implementation in September 18, 2023 in Version 17. We believe this deprecation should be safe. The new functions is already launched in m130 as in https://chromestatus.com/feature/5122839207477248

Deprecate special font size rules for H1 within some elements Deprecated Enterprise: Low

The HTML spec contains a list of [special rules for H1 tags](https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings) 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.

Intent stage: None

The current behavior is an accessibility problem: the font size is reduced as if an <h2> is being used, but the a11y tree still shows the item as an <h1>. By removing these special rules, we'll nudge developers to do the "better" thing of actually using an <h2>.

Chrome removes support for macOS 11 Deprecated Enterprise: High

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.

Intent stage: None

Remove auto-detection of ISO-2022-JP charset in HTML Deprecated

There are known[1] security issues around charset auto-detection for ISO-2022-JP. Given that the usage is very low, and Safari does not support auto-detection of ISO-2022-JP, we will remove support for it to eliminate the security issues. [1]: https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/

Intent stage: None

There are known[1] security issues around charset auto-detection for ISO-2022-JP. The use counter[2] shows that the auto-detection of ISO-2022-JP charset only happens around 0.000002% of page load. Given that usage is very low, and Safari does not support auto-detection of ISO-2022-JP, we will remove support for it to eliminate the security issues. [1]: https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/ [2]: https://chromestatus.com/metrics/feature/timeline/popularity/5244

Remove SwiftShader fallback Deprecated Enterprise: Low

Allowing automatic fallback to WebGL backed by the software renderer 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. Please test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user.

Intent stage: None

https://chromium.googlesource.com/chromium/src/+/main/docs/gpu/swiftshader.md#automatic-swiftshader-webgl-fallback-is-deprecated

Deprecate asynchronous range removal for Media Source Extensions Deprecated Enterprise: Low

The Media Source standard long ago changed 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 will be 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. Primarily small Russian sites. 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.

Intent stage: None

Chromium should comply with the spec and shipping behavior in Firefox and Safari to avoid future interop issues while usage remains low.

WebGPU: Deprecate GPUAdapter isFallbackAdapter attribute Deprecated

Deprecates the GPUAdapter isFallbackAdapter boolean attribute from WebGPU, which is redundant with the GPUAdapterInfo isFallbackAdapter boolean attribute. This upcoming removal is a minor breaking change as support for fallback adapters has not yet been implemented in any browser, thereby resulting in both isFallbackAdapter attributes consistently returning a falsy value.

Intent stage: None

Removing GPUAdapter isFallbackAdapter boolean attribute eliminates unnecessary complexity and potential confusion by consolidating the functionality within the existing GPUAdapterInfo isFallbackAdapter boolean attribute. This change promotes cleaner code and a more intuitive development experience. A search for the string "isFallbackAdapter" in HTTPArchive yielded no results. As of Apr 30, 2025, usage of the GPUAdapter isFallbackAdapter boolean attribute reached a peak of 0.000338% of page loads according to the ChromeStatus dashboard https://chromestatus.com/metrics/feature/timeline/popularity/5460.

Remove HTMLFencedFrameElement.canLoadOpaqueURL(). Deprecated

canLoadOpaqueURL() was replaced with navigator.canLoadAdAuctionFencedFrame() in 2023, and calling it has resulted in a deprecation console warning ever since pointing developers to the new API. It does not make sense to have the function attached to `HTMLFencedFrameElement` and instead should be attached to the `navigator` object (which contains other fenced frame + ad auction methods).

Intent stage: None

This can already be done with its replacement: `navigator.canLoadAdAuctionFencedFrame()`. Because the `navigator` object contains other fenced frame and ad auction related functions, it is better to have this API live there.

Remove deprecated navigator.xr.supportsSession method Deprecated Enterprise: Low

navigator.xr.supportsSession was replaced in the WebXR spec by the navigator.xr.isSessionSupported method in September of 2019 after receiving feedback on the API shape from the TAG. It has been marked as deprecated in Chromium since then, producing a console warning redirecting developers to the updated API. Usage of the call is very low, as shown here: https://chromestatus.com/metrics/feature/timeline/popularity/2416 Additionally, all major frameworks that are used to build WebXR content have been confirmed to have been updated to use the newer call.

Intent stage: None

API was updated in 2019 after TAG feedback and the older version of the function has been marked deprecated ever since.

Remove WebGPU limit maxInterStageShaderComponents Deprecated

The maxInterStageShaderComponents limit is being removed due to a combination of factors: - Redundancy with maxInterStageShaderVariables: This limit already serves a similar purpose, controlling the amount of data passed between shader stages. - Minor Discrepancies: While there are slight differences in how the two limits are calculated, these differences are minor and can be effectively managed within the maxInterStageShaderVariables limit. - Simplification: Removing maxInterStageShaderComponents streamlines the shader interface and reduces complexity for developers. Instead of managing two separate limits (that both apply simultaneously but with subtle differences), they can focus on the more appropriately named and comprehensive maxInterStageShaderVariables. https://github.com/gpuweb/gpuweb/pull/4783

Intent stage: None

Removing maxInterStageShaderComponents eliminates unnecessary complexity and potential confusion by consolidating the functionality within the existing maxInterStageShaderVariables limit. This change promotes cleaner code and a more intuitive development experience. A search for the string "maxInterStageShaderComponents" in HTTPArchive yielded no results. As of November 16th, 2024, usage of the maxInterStageShaderComponents limit within GPUAdapter and GPUDevice reached a peak of 0.3163% of page loads. Additionally, its usage in requiredLimits when called through requestDevice reached 0.0004% on the same day. These metrics are tracked in the ChromeStatus dashboard through https://chromestatus.com/metrics/feature/timeline/popularity/5110 and https://chromestatus.com/metrics/feature/timeline/popularity/5111.

Remove nonstandard getUserMedia audio constraints Deprecated Enterprise: Low

Blink supports a number of nonstandard goog-prefixed constraints for getUserMedia from some time before constraints were properly standardized. Usage has gone down significantly ~0.000001% to 0.0009% (depending on the constraint) and some of them do not even have an effect due to changes in the Chromium audio-capture stack. Soon none of them will have any effect due to other upcoming changes. We do not expect any major regressions due to this change. Applications using these constraints will continue to work, but will get audio with default settings (as if no constraints were passed). They can easily migrate to standard constraints.

Intent stage: None

These goog-prefixed constraints are a relic from the pre-standard getUserMedia times and should not be used by anyone. Usage is now low enough that they can be removed without causing significant regressions.

Remove Chrome Welcome page triggering via initial prefs first run tabs Deprecated Enterprise: Low

Including "chrome://welcome" in the "first_run_tabs" property of the "initial_preferences" file will now have no effect. This is removed because that page is redundant with the First Run Experience that triggers on desktop platforms. See https://www.chromium.org/administrators/configuring-other-preferences for more context on the "initial_preferences" file.

Intent stage: None

Remove <link rel=prefetch> five-minute rule Deprecated

Previously, when a resource was prefetched using <link rel=prefetch>, we ignored its cache semantics (namely max-age and no-cache) for the first use within 5 minutes, to avoid refetching. Now, we remove this special case and use normal HTTP cache semantics. This means web developers need to include appropriate caching headers (i.e. Cache-Control or Expires) to see benefits from <link rel=prefetch>. This also affects the nonstandard <link rel=prerender>. This fixes a bug with speculation rules prefetch, where non-2xx responses were cached. However, it does not start requiring caching headers for speculation rules prefetch, since they are intended for navigational prefetching and thus have different caching needs than the normal HTTP cache.

Intent stage: Start prototyping

The 5-minute rule was never standardized, not implemented by other browsers, and now as part of an effort to make prefetch interoperable across browsers I would like to align on a behavior that doesn't include this. Data to support this: 1. A UMA histogram (https://uma.googleplex.com/p/chrome/timeline_v2?sid=5f237b8589cdf9f292c40b976fbfe69c) shows that 0.05% of prefetch reuses actually benefit from this. About 85% of prefetches are reused regardless (e.g. inside the max-age anyway), and about 15% are not reused (e.g. 5 minutes have passed, not the first reuse). 2. Developers who rely on this can opt-in to this behavior, by setting a 5-minute max-age on prefetch requests (requests with a [Sec-]Purpose: prefetch header).

Remove Prefixed HTMLVideoElement Fullscreen APIs Deprecated Enterprise: Medium

The prefixed HTMLVideoElement-specific fullscreen APIs have been deprecated since approximately M38. They were replaced by the Element.requestFullscreen() API, which first shipped un-prefixed in M71, in 2018. As of 2024, most browsers have had support for the un-prefixed APIs for a few years now. This feature tracks removing the following APIs from HTMLVideoElement: - readonly attribute boolean webkitSupportsFullscreen; - readonly attribute boolean webkitDisplayingFullscreen; - void webkitEnterFullscreen(); - void webkitExitFullscreen(); // Note the different capitalization of the "S" in FullScreen. - void webkitEnterFullScreen(); - void webkitExitFullScreen(); These methods are now only aliases for the modern API. Their use has declined steadily over the years.

Intent stage: None

The 'webkit' prefixed HTMLVideoElement-specific fullscreen APIs were marked as deprecated in 2014. The un-prefixed standard fullscreen API shipped in 2018, in M71. As of 2024, usage of the prefixed APIs has dropped enough that removing them may no longer be as disruptive for the web, and should encourage use of standardized APIs.

Remove non-standard GPUAdapter requestAdapterInfo() method Deprecated Enterprise: Low

The WebGPU WG decided it was impractical for requestAdapterInfo() to trigger a permission prompt so they’ve removed that option and replaced it with the GPUAdapter info attribute so that web developers can get the same GPUAdapterInfo value synchronously this time. See the previous Intent to Ship: WebGPU: GPUAdapter info attribute at https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ

Intent stage: None

The requestAdapterInfo() asynchronous method in WebGPU is redundant because developers can already get GPUAdapterInfo synchronously using the GPUAdapter info attribute. Hence, it should be removed. A search for the string "requestAdapterInfo" in HTTPArchive yielded no results. According to https://chromestatus.com/metrics/feature/timeline/popularity/4977, the requestAdapterInfo() method accounted for approximately 0.41% of page loads in September 2024. Chrome UKMs helped us in identifying the most popular websites using the WebGPU requestAdapterInfo() method: - Twitch: The team has been contacted and has indicated that they will update their code. - Dynatrace: Used by the great majority of the websites for analytics, they have been made aware of this deprecation.a

Deprecation of CSS Anchor Positioning property `inset-area` Deprecated Enterprise: Low

The CSSWG resolved to rename the `inset-area` property to `position-area`. See the CSSWG discussion here: https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001. The new property name, `position-area`, as a synonym for `inset-area` shipped via https://chromestatus.com/feature/6567965055778816. This entry is for deprecation and removal of the `inset-area` property.

Intent stage: None

With the CSSWG resolution on renaming the property to `position-area`, this deprecation will clean up the implementation in Chromium for a standards compliant feature.

Remove expectedImprovement in DelegatedInkTrailPresenter Deprecated

The attribute tells web developers how much improvement the DelegatedInkTrails API will provide to their current ink latency. However, this attribute is not worth increases to fingerprinting entropy.

Intent stage: None

expectedImprovement tells web developers how much improvement the DelegatedInkTrails API will provide to their current ink latency. However, this attribute is not worth increases to fingerprinting entropy. The difference in cost to the web developer between using the expectedImprovement attribute and actually delegating the "wet" ink trail to the OS/Browser is minimal, and upon additional discussion, there was no good reason found for the web developer not delegating the ink trail after receiving some value from the expectedImprovement attribute (all improvement is good improvement). The removal of this attribute should have minimal impact to web compatibility as it was never implemented in Blink in the first place. This is the intent to remove the attribute from the web exposed DelegatedInkTrailPresenter interface. There is no usage of this attribute according to blink use counters.

Remove PointerEvent.getCoalescedEvents() from insecure contexts Deprecated Enterprise: Low

The Pointer Events Working Group made PointerEvent.getCoalescedEvents() restricted to secure contexts 4+ years ago, which removed the API from insecure contexts. Chrome originally shipped the old behavior and didn't follow the spec change immediately because of compat concerns. We are now removing it from insecure contexts because Chrome usage in insecure contexts turned out to be very low.

Intent stage: None

Deprecate the includeShadowRoots argument on DOMParser Deprecated Enterprise: Low

The includeShadowRoots argument was a never-standardized argument to the DOMParser.parseFromString() function, which was there to allow imperative parsing of HTML content that contains declarative shadow DOM. This was shipped in M90 [1] as part of the initial shipment of declarative shadow DOM. Since the standards discussion rematerialized in 2023, the shape of DSD APIs changed, including this feature for imperative parsing. (See [2] for more context on the standards situation and recent changes, and see [3] and [4] for other related deprecations.) Now that a standardized version of this API, in the form of setHTMLUnsafe() and parseHTMLUnsafe() will ship in Chrome 124 ([5]), the non-standard includeShadowRoots argument needs to be deprecated and removed. All usage should shift accordingly: Instead of: (new DOMParser()).parseFromString(html,'text/html',{includeShadowRoots: true}); this can be used instead: document.parseHTMLUnsafe(html); [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/feature/5161240576393216 [3] https://chromestatus.com/feature/5081733588582400 [4] https://chromestatus.com/feature/6239658726391808 [5] https://chromestatus.com/feature/6560361081995264

Intent stage: None

Now that there is a standardized version of this API, it makes sense to remove the non-standard, Chrome-only version of the API.

Deprecation of non-standard declarative shadow DOM serialization Deprecated Enterprise: Low

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the deprecation of the old, shipped `getInnerHTML()` method. The replacement is called `getHTML()`, and it shipped in M125. See https://chromestatus.com/feature/5102952270528512 for that feature.

Intent stage: None

The standardized method, getHTML(), will likely be interoperable (once implemented in other browsers), while this version (getInnerHTML) will not.

Deprecate 0.0.0.0 for Private Network Access Deprecated

We propose to block access to IP address 0.0.0.0 in advance of PNA completely rolling out. Chrome is deprecating direct access to private network endpoints from public websites as part of the Private Network Access (PNA) specification (https://developer.chrome.com/blog/private-network-access-preflight/). Services listening on the localhost (127.0.0.0/8) are considered private according to the specification (https://wicg.github.io/private-network-access/#ip-address-space-heading). Chrome's PNA protection (rolled out as part of https://chromestatus.com/feature/5436853517811712) can be bypassed using the IP address 0.0.0.0 to access services listening on the localhost on macOS and Linux. This can also be abused in DNS rebinding attacks targeting a web application listening on the localhost. Since 0.0.0.0 is not used in practice (and should not be used), but was overlooked during https://chromestatus.com/feature/5436853517811712, we're deprecating it separately from the rest of the private network requests deprecation.

Intent stage: None

Chrome is deprecating direct access to private network endpoints from public websites as part of the Private Network Access (PNA) specification (https://developer.chrome.com/blog/private-network-access-preflight/). Services listening on the localhost (127.0.0.0/8) are considered private according to the specification (https://wicg.github.io/private-network-access/#ip-address-space-heading). Chrome's PNA protection can be bypassed using the IP address 0.0.0.0 to access services listening on the localhost on macOS and Linux. This can also be abused in DNS rebinding attacks targeting a web application listening on the localhost. See more: https://crbug.com/1300021

Deprecate old CSS custom state syntax Deprecated Enterprise: Low

The CSS custom state pseudo-class is being renamed from :--foo to :state(foo). The new syntax, :state(foo), has been enabled by default, and now we have to deprecate and remove the :--foo syntax. Gecko and webkit never implemented the old syntax and they have both shipped the new syntax. We are currently shipping both the new syntax and the old syntax at the same time. There have been console errors and DevTools deprecations for the old syntax for many milestones already. Previous thread on this topic: https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ The UseCounter is currently at 0.04% https://chromestatus.com/metrics/feature/timeline/popularity/3796 For Enterprise customers who need more time, please use the CSSCustomStateDeprecatedSyntaxEnabled policy. This policy will be removed in Chrome 131.

Intent stage: None

The syntax of this feature needs to change in order to get support from the other browsers and eventually have interoperable behavior.

Deprecate Mutation Events Deprecated Enterprise: Medium

Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite bad for page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec (https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete Mutation Events must now be migrated to Mutation Observer. Mutation event support will be disabled by default starting in Chrome 127, around July 30, 2024. Code should be migrated before that date to avoid site breakage. If more time is needed, there are a few options: - The Mutation Events Deprecation trial (https://developer.chrome.com/origintrials/#/view_trial/919297273937002497) can be used to re-enable the feature for a limited time on a given site. This can be used through Chrome 134, ending March 25, 2025. - A MutationEventsEnabled enterprise policy (https://chromeenterprise.google/policies/#MutationEventsEnabled) can also be used for the same purpose, also through Chrome 134. Please see this blog post for more detail: https://developer.chrome.com/blog/mutation-events-deprecation Report bugs here: https://issues.chromium.org/new?component=1456718&template=1948649

Intent stage: None

Mutation Events have been deprecated for over a decade, with the replacement (Mutation Observer) available also for over a decade. The fact that these events are still supported in browsers makes the addition of new features much more difficult, prohibitively so in some cases. For example, these feature requests and projects are all negatively impacted by the existence of Mutation Events: - iFrame reparenting: https://github.com/whatwg/html/issues/5484 and https://github.com/whatwg/dom/issues/891 - Child reordering: https://github.com/whatwg/dom/issues/586 - DOM Parts and batch DOM updates: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md Given that the feature has been spec-deprecated for over a decade, and a replacement available for over a decade, it makes sense to finally disable and remove these APIs from Chrome.

Deprecate and remove import assertion 'assert' syntax Deprecated Enterprise: Low

TC39 has consensus for trying to deprecate and remove the `assert` keyword in favor of the new `with` keyword in import attribute syntax. That is, `import m from 'foo' assert { type: 'json' }` will now throw a SyntaxError, and developers must change to `import m from 'foo' with { type: 'json' }`. https://github.com/tc39/proposal-import-attributes/issues/135

Intent stage: None

The import assertions proposal (now called "import attributes") [1] in TC39 shipped in M91 with the `import mod from 'foo' assert { type: 'json' }` syntax. The original semantics was that additional information following the `assert` keyword cannot cause the module to be reinterpreted or change the semantics of the module in any way, i.e., a pure assertion. Following an HTML integration issue with CSP [2] that required changing Accept headers depending on the requested module type, TC39 reached consensus that the "pure assertion" semantics are to be relaxed to allow reinterpretation, and that the `assert` keyword be changed to `with` to reflect the new semantics. [1] https://github.com/tc39/proposal-import-attributes/ [2] https://github.com/whatwg/html/issues/7233

Remove Discontinuity for (ok)lab/lch colors with lightness of nearly 100% or 0 Deprecated

Before this change, all lab, lch, oklab and oklch colors with a lightness value of 100% were rendered as white, regardless of the other two parameters. All colors in these spaces with a lightness value of 0 were rendered as black. These two mappings caused discontinuities in gradients and were generally surprising to web developers. With this rollback chromium no longer maps these colors artificially and the resulting displayed color will be continuous with nearby colors and will depend on the gamut mapping of the display. See: https://crrev.com/c/5400609

Intent stage: None

Deprecate enterprise policy NewBaseUrlInheritanceBehaviorAllowed Deprecated Enterprise: Low

The underlying code change (enable new base url inheritance behavior) that this enterprise policy overrides has been enabled in stable releases since August 2023 (118.0.5966.0). Since known issues have been dealt with, we intend to remove this enterprise policy by early May 2024 (Chrome 125).

Intent stage: None

Remove window-placement alias for permission and permission policy descriptors Deprecated Enterprise: Medium

Chrome 125 removes the window-placement alias for permission and permission policy descriptors. All instances of window-placement are replaced with window-management, which better describes the related API functionality. This is a follow-up to Window Management API feature enhancements and renaming from "Multi-Screen Window Placement API"; for more details, see https://chromestatus.com/feature/5146352391028736

Intent stage: None

(Copied from https://chromestatus.com/feature/5146352391028736) The existing "Window Placement" terminology only describes one specific component of the API that allows web applications to place browser windows on target displays. It doesn't encompass the entire surface of the API described in the spec, nor will it adequately describe potential future additions to the API.

Deprecate and remove Theora support. Deprecated Enterprise: Medium

Chrome will deprecate and remove support for the Theora video codec in desktop Chrome due to emerging security risks. Theora's low (and now often incorrect) usage no longer justifies support for most users. Notes: - Zero day attacks against media codecs have spiked. - Usage has fallen below measurable levels in UKM. - The sites we manually inspected before levels dropped off were incorrectly preferring Theora over more modern codecs like VP9. - It's never been supported by Safari or Chrome on Android. - An ogv.js polyfill exists for the sites that still need Theora support. - We are not removing support for ogg containers. Our plan is to begin escalating experiments turning down Theora support in M120. During this time users can reactivate Theora support via chrome://flags/#theora-video-codec if needed. The tentative timeline for this is (assuming everything goes smoothly): - ~Oct 23, 2023: begin 50/50 canary dev experiments. - ~Nov 1-6, 2023: begin 50/50 beta experiments. - ~Dec 6, 2023: begin 1% stable experiments. - ~Jan 8, 2024: begin 50% stable experiments. - ~Jan 16th, 2024: launch at 100%. - ~Feb 2024: remove code and chrome://flag in M123. - ~Mar 2024: Chrome 123 will roll to stable.

Intent stage: None

A spike in zero day attacks against media formats has caused us to reevaluate our support for legacy codecs. The Theora video codec was first released in 2004 and had its last official release in 2011. While it was one of the first open codecs on the web, usage has now fallen below detectable levels and was never supported by Safari or Chrome for Android. Given the risks to the wider Chrome population, we'll begin to remove support in M120 and finalizing removal in M123. Prior to usage falling below detectable levels, the sites we did manually inspect were incorrectly preferring Theora over more modern codecs like VP9.

Remove same-origin blanket enforcement in CSPEE Deprecated

Removes a special treatment for same-origin iframes from CSP Embedded Enforcement. This aligns the behavior of enforcing CSP Embedded Enforcement for cross-origin iframes and same-origin iframes.

Intent stage: None

The same-origin blanket enforcement logic specific to same-origin iframes exposes a new way to block certain resources from loading in the iframe. This allowed attacks which were not possible before (example[1]). Additionally, this caused a bug[2] where CSP nonce value enforced by CSPEE from a top frame had to exactly match nonce value served in grand-child frame, if the top frame and child frame are cross-origin, but child frame and grand-child frame are same-origin. Given this part of blanket enforcement is rarely used (~0.000017%[3]), let's remove this logic. [1] https://github.com/google/google-ctf/tree/master/2023/quals/web-biohazard/solution#reviving-xss-auditor-primitive [2] https://github.com/w3c/webappsec-cspee/issues/26 [3] https://chromestatus.com/metrics/feature/timeline/popularity/4599

Remove data: URL in SVGUseElement Deprecated Enterprise: Medium

Assigning a data: URL in SVGUseElement can cause XSS. And this also led to a Trusted Types bypass. Therefore, we plan to deprecate and remove support for it.

Intent stage: Dev trials

Assigning an attacker controlled string to SVGUseElement.href causes XSS and a Trusted Types bypass[1] because of data: URLs. If we fix this bug by requiring TrustedScriptURL assignment to SVGUseElement.href under Trusted Types enforcement, many sites would need to refactor code (even for same-origin URL or Blob URL assignment). Since Webkit does not support data: URLs in SVGUseElement and both Mozilla and Webkit are supportive for the removal, we think that removing support for data: URLs in SVGUseElement is the right way to solve this problem. Additionally, data: URLs can only trigger script execution in script loaders such as HTMLScriptElement.src or dynamic import[2]. However, SVGUseElement is an exception to this, which also caused a bypass[3] in the Sanitizer API. We believe that this also led to several other bugs in sanitizers and linters missing a check for this special case. [1] https://github.com/w3c/trusted-types/issues/357 [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import [3] https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10

Replace dangling markup in target name to `_blank` Deprecated

This change replaces the navigable target name (which is usually set by target attribute) to `_blank`, if it contains a dangling markup (i.e. `\n` and `<`). Which fixes a bypass in the dangling markup injection mitigation.

Intent stage: None

Blink has shipped a mitigation for dangling markup injection attack[1] while back. However, it was discovered that the mitigation can be bypassed through target name[2]. Navigations with such target names are low (~0.000007%)[3]. Therefore, this change removes the limitation discovered in the previous mitigation. [1] https://chromestatus.com/feature/5735596811091968 [2] https://portswigger.net/research/evading-csp-with-dom-based-dangling-markup [3] https://chromestatus.com/metrics/feature/timeline/popularity/4493

Remove Sanitizer API Deprecated

The Sanitizer API (https://chromestatus.com/feature/5786893650231296) aims to build an easy-to-use, always secure, browser-maintained HTML sanitizer into the platform. It is a cross-browser standardization effort starting in Q2/2020. We shipped an initial version of the Sanitizer API in M105, based on the then-current specification draft. However, the discussion has meanwhile moved on and the proposed API shape has changed substantially. In order to prevent the current API from becoming entrenched we would like to remove the current implementation. We expect to re-implement the Sanitizer API when the proposed specification stabilizes again. Use counters: The Sanitizer API is currently used on 0.000000492% of page visits. Old vs new API: * Old explainer, API as implemented in "MVP" since M105: https://github.com/WICG/sanitizer-api/blob/e72b56b361a31b722b4e14491a83e2d25943ba58/explainer.md * New explainer (still in progress): https://github.com/WICG/sanitizer-api/blob/main/explainer.md

Intent stage: None

Since the final version of the standard will look different from our initial implementation, the goal is to prevent an API to become entrenched. According to use counters, the Sanitizer API is currently used on 0.000000492 % of page visits.

Deprecate non-standard `shadowroot` attribute for declarative shadow DOM Deprecated

The standards-track `shadowrootmode` attribute, which enables declarative Shadow DOM, was shipped in Chrome 111 [1]. The older, non-standard `shadowroot` attribute is now deprecated. During the deprecation period, both attributes are functional, however the `shadowroot` attribute does not enable the new streaming behavior, whereas `shadowrootmode` allows streaming of content. There is a straightforward migration path: replace `shadowroot` with `shadowrootmode`. The old `shadowroot` attribute is deprecated as of Chrome M112, and it will be removed (no longer supported) in Chrome M119, which goes to Stable on November 1, 2023. [1] https://chromestatus.com/feature/5161240576393216

Intent stage: None

The new attribute, `shadowrootmode`, is standards-track and will be supported by other browsers. The older `shadowroot` attribute will not. We'd like to migrate existing users to the new attribute, and eventually remove support for `shadowroot`.

Deprecate and Remove WebSQL Deprecated Enterprise: Medium

The Web SQL Database standard was first proposed in April 2009 and abandoned in November 2010. Gecko never implemented this feature and WebKit deprecated this feature in 2019. The W3C encouraged those needing web databases to adopt Web Storage or Indexed Database. Ever since its release, it has made it incredibly difficult to keep our users secure. SQLite was not initially designed to run malicious SQL statements, and yet with WebsQL we have to do exactly this. Having to react to a flow of stability and security issues is an unpredictable cost to the storage team. With SQLite over WASM as its official replacement, we want to remove WebSQL entirely.

Intent stage: Dev trials

WebSQL is a deprecated API. Continuing to support this API is not secure for users, reduces stability in Chrome, and a tax to Chrome Release, Security TPMs and the Chrome Storage Team.

Remove non-standard appearance keywords Deprecated

Since only standard appearance keywords should be supported, we are removing the appearance (and -webkit-appearance) keywords that shouldn't be supported anymore: * inner-spin-button * media-slider * media-sliderthumb * media-volume-slider * media-volume-sliderthumb * push-button * searchfield-cancel-button * slider-horizontal * sliderthumb-horizontal * sliderthumb-vertical * square-button Note that value "slider-vertical" will not be removed as part of this patch it is used for allowing <input type=range> vertical. It will be removed once feature FormControlsVerticalWritingModeSupport is enabled in stable. With the feature enabled, if using any of the above keywords, a console warning will be shown, but the keyword will be recognized as a valid value. With the feature disabled, the appearance property will be ignored. As needed for Web compatibility, we will progressively remove the appearance keywords based on their usage: * --disable-features=NonStandardAppearanceValuesLowUsage * --disable-features=NonStandardAppearanceValuesHighUsage For release 118, we will disable the low usage values, currently at page load usage below 0.001%. * media-slider at 0.000361 * media-sliderthumb at 0.000187% * media-volume-slider at 0.000143% * media-volume-sliderthumb at 0.000109% * sliderthumb-horizontal at 0.000182% * sliderthumb-vertical at 0.000014%

Intent stage: Prepare to ship

We should remove non-standard -webkit-appearance keywords and only support the keywords listed in the standards.

CSS property -webkit-highlight Deprecated

Remove the CSS property -webkit-highlight intended to highlight text, but never standardized. It has no visible effect in chromium (it is parsed but never used in rendering content). The property was removed from WebKit in 2014 (https://bugs.webkit.org/show_bug.cgi?id=128456), has been marked as deprecated on MDN, and has been replaced recently with the CSS Highlight Pseudo spec (https://www.w3.org/TR/css-pseudo-4/#highlight-pseudos).

Intent stage: Prepare to ship

The motivation is to avoid confusion with the new CSS Highlight Pseudo and to clean up the code (removing 1K or so of memory usage).

[WebRTC] Unship callback-based legacy getStats() Deprecated

RTCPeerConnection has two versions of getStats(), one that is spec-compliant returning the report via resolving a promise, and one that is non-standard returning a very different report via a callback as the first argument. The callback-based was removed in M117, with a Deprecation Trial available until M121. As of M122, the API does not anymore, even if you use the Deprecation Trial.

Intent stage: None

Deprecate TLS SHA-1 server signatures Deprecated

Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported. SHA-1 can be temporarily re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled enterprise policy. This policy will be removed in Chrome 123.

Intent stage: Origin Trial

SHA-1 has known collisions and is no longer considered a secure hash function. Removing support ensures these weaknesses cannot be used by an attacker to impersonate a TLS server. Use of SHA-1 signatures in TLS has been deprecated by the IETF in RFC 9155. Though also deprecated in RFC 9155, this change does not affect SHA-1 in client certificates and client signatures. For now, Chrome will continue to send SHA-1 client certificates if provisioned, and generate SHA-1 client signatures if requested by the server. To mitigate the corresponding client impersonation attack, server operators can and should reject SHA-1 from the client when deploying client certificates (sometimes referred to as mTLS).

Remove document.open sandbox inheritance Deprecated

Sandbox flags of the caller are currently applied to the callee when document.open targets a different window. Stop doing it.

Intent stage: Prepare to ship

The removed behavior was not specified. Safari and Firefox do not implement it. It had no security benefits. It makes it difficult for Chrome's implementation to stay in a consistent state.

Remove WebGPU limit maxFragmentCombinedOutputResources Deprecated

Removes the maxFragmentCombinedOutputResources limit from WebGPU, which has been deemed to be unnecessary. This limit applies additional restrictions on use of the WebGPU API, but is being removed from the standard. This removal is a minor breaking change.

Intent stage: Start prototyping

Though this removal lifts restrictions, this limit was removed early, in a *breaking* way, to avoid leaving behind a vestigial limit field that would be confusing to developers. (The specification has not officially reached a stable V1.) https://github.com/gpuweb/gpuweb/pull/4044 The breaking change is to remove maxFragmentCombinedOutputResources from the GPUSupportedLimits interface, and as an accepted key by the GPUDeviceDescriptor.requiredLimits record.

Remove support for Web Push Notifications using FCM Sender IDs Deprecated

* Chrome shipped support for Web Push Notifications using FCM Sender IDs M42 (March 2015), after which we added support for a standardized authentication path in M52 (July 2016). * We have been deprecating support for FCM Sender IDs since, adding console warnings and blocking the list of senders in 2019, and blocking all new subscription requests using sender IDs in 2020. Today we see <1000 unique senders still relying on Chrome to receive such messages in a 7-day window -- this is a tiny portion of full Web Push usage. * Following this prolonged deprecation path, we're now proceeding to remove support for Chrome to receive messages for subscriptions that were once created using FCM Sender IDs. Users who receive such messages will stop receiving them until they re-visit the sender's website, at which time it has the chance to renew the subscription. We unfortunately cannot automatically update such subscriptions. The roll-out will be done server-side.

Intent stage: Prepare to ship

This removes a long-deprecated, now barely-used proprietary addition in our Web Push Notifications implementation.

Secure Payment Confirmation: Rename rp --> rpId in CollectedClientAdditionalPaymentData Deprecated Enterprise: Medium

Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It builds on top of WebAuthn to bring strong authentication to payment flows. In the initial spec and implementation of SPC, the output CollectedClientAdditionalPaymentData dictionary[0] of the cryptogram contained a parameter named 'rp'. This was renamed in the specification[1] to 'rpId' to align with WebAuthn, and Chrome is changing its implementation to match (that is, adding 'rpId' and removing 'rp'). [0]: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary [1]: https://github.com/w3c/secure-payment-confirmation/pull/198

Intent stage: Start prototyping

Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It builds on top of WebAuthn to bring strong authentication to payment flows. In the initial spec and implementation of SPC, the output CollectedClientAdditionalPaymentData dictionary[0] of the cryptogram contained a parameter named 'rp'. This was renamed in the specification[1] to 'rpId' to align with WebAuthn, and Chrome is changing its implementation to match (that is, adding 'rpId' and removing 'rp'). In M107, we added[2] 'rpId' to CollectedClientAdditionalPaymentData as an additional, identical field to 'rp'. We will now be removing the old 'rp' parameter. [0]: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary [1]: https://github.com/w3c/secure-payment-confirmation/pull/198 [2]: https://chromium.googlesource.com/chromium/src/+/3472ddafd924cbffab61b88746c5fe81e71e26a7

Deprecate and remove PaymentInstruments Deprecated

PaymentInstruments is the Web API that backs non-JIT install of payment apps (see https://w3c.github.io/payment-handler/). It was designed with the assumption that the browser would store the actual payment instrument details, which has not turned out to be true, and has some privacy leaks. It also has not shipped on any other browser, not have we seen any interest from other browser vendors. As such, this API has been deprecated and removed.

Intent stage: Start prototyping

The PaymentInstruments.set() method allows an attacker website to store arbitrary data, which can later be retrieved via PaymentInstruments.get() potentially in a third-party context. For example, the user visits https://tracker.example, which generates and stores a UUID for that user via PaymentInstruments.set(key, UUID). Later, the user visits https://site.example, which opens an iframe for https://tracker.example. That iframe calls PaymentInstruments.get(key) and can retrieve the UUID, thus allowing https://tracker.example to know which user it is. Given the lack of uptake in PaymentInstruments.set(), versus the more common JIT-install path, as well as the overly powerful nature of the API, we propose to remove PaymentInstruments entirely. (PaymentInstruments was designed with the belief that the browser would know about individual payment methods (e.g., credit cards) rather than payment apps, hence the need to store/retrieve arbitrary information.)

Deprecate and remove window.defaultStatus and window.defaultstatus Deprecated

These two APIs originally were used to modify/control the "status bar" text at the bottom of browser windows. However, they have never had any actual effect on Chrome's status bar, and they are not standardized attributes. Gecko has not supported these attributes since version 23; WebKit still supports these attributes. The related window.status attribute *is* standardized, but also must never have an impact on the window status bar (https://html.spec.whatwg.org/multipage/window-object.html#dom-window-status). The window.status attribute is not being modified with this launch.

Intent stage: Prepare to ship

These are non-standard APIs that aren't implemented by all browsers and have no effect on browser behavior. This cleans them up, and removes a potential fingerprinting signal.

Deprecate and remove ImageDecoderInit.premultiplyAlpha. Deprecated

Feature has no observable effects in primary use cases, but may constrain implementations in suboptimal ways. See https://github.com/w3c/webcodecs/issues/508 for a more detailed description. Per consensus of WebCodecs spec editors and lack of usage (0.000000339% - 0.00000687% of page loads per use counter in M106), we propose deprecating and removing this feature starting M108.

Intent stage: Removed

Feature has no observable effects in primary use cases, but may constrain implementations in suboptimal ways. See https://github.com/w3c/webcodecs/issues/508 for a more detailed description. Per consensus of WebCodecs spec editors and lack of usage (0.000000339% - 0.00000687% of page loads per use counter in M106), we propose deprecating and removing this feature starting M108.

Removal of navigateEvent.restoreScroll() Deprecated

restoreScroll() is being replaced by navigateEvent.scroll(). scroll() works identically except that it allows the developer to control scroll timing for non-traverse navigations (i.e., scroll() works when the scroll is not a restore, hence the name change along with the behavior change).

Intent stage: Prepare to ship

We want to support developer-controlled timing of a navigation-associated scroll in non-traverse cases (e.g., scrolling to a fragment). It makes sense to have the same fragment drive navigation-related scrolling in both traverse and non-traverse cases, but the name "restoreScroll" is nonsense for push/replace navigations.

Removal of navigateEvent.transitionWhile() Deprecated

transitionWhile() is being replaced by navigateEvent.intercept() due to design flaws reported by developers. intercept() behaves nearly identically to transitionWhile(), but instead of taking a mandatory Promise parameter, it takes an optional handler function that returns a Promise. This allows the browser to control when handler executes, which is later and more intuitive than what transitionWhile() required. Also, the "default" intercept() case with no handler is much shorter and simpler to write than the "default" transitionWhile() boilerplate.

Intent stage: Prepare to ship

transitionWhile() has design issues that have meant developers have found it difficult to use effectively, detailed in https://github.com/WICG/navigation-api/issues/230#issuecomment-1137891972 intercept() is being introduced to provide a more usable API for the same basic functionality of transitionWhile()

[WebRTC] Deprecate and Remove mediaConstraint's googIPv6 Deprecated

"googIPv6: false" can be used (example: new RTCPeerConnection({}, {mandatory:{googIPv6:false}});) to disable IPv6 support in WebRTC. IPv6 has been enabled by default for many years and we should not be able to disable it. Remove this non-standard API.

Intent stage: None

Expect-CT Deprecated

Expect-CT is an HTTP header that allowed websites to opt in to Certificate Transparency enforcement before it was enforced by default. It also has reporting functionality to help developers discover CT misconfigurations.

Intent stage: Start prototyping

Expect-CT was designed to help transition to universal Certificate Transparency (CT) enforcement, by allowing high-value websites to opt in to CT enforcement/reporting for better security before CT enforcement was required (by Chrome) on all public websites. However, Expect-CT has now outlived its usefulness. Chrome requires CT on all public websites now, so there is no security value to Expect-CT anymore. Expect-CT was also designed to help site owners discover CT-related misconfigurations; however, now that CT is universally required, CT is configured in websites' certificates by certificate authorities and virtually never configured by individual site owners, thus Expect-CT has very limited value as a misconfiguration/debugging tool anymore either. No other browser has implemented Expect-CT so removing it is not an interoperability concern.

Deprecate non-ASCII characters in cookie domain attributes Deprecated

To align with the latest specification in RFC 6265bis, Chromium will reject cookies with a "Domain" attribute that contains a non-ASCII character (e.g. Domain=éxample.com).

Intent stage: Prepare to ship

Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari and Firefox all behaving differently. https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by standardizing Firefox's behavior of rejecting cookies with non-ASCII domain attributes. Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.

CSS default keyword is disallowed in custom identifiers Deprecated

The CSS keyword 'default' is not allowed within CSS custom identifiers, which are used for many types of user-defined names in CSS (for example, names created by @keyframes rules, counters, @container names, custom layout or paint names). This adds 'default' to the list of names that are reserved from being used in custom identifiers, which already reserve 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.

Intent stage: Prepare to ship

Keywords that CSS uses (or is likely to use in the future) as values accepted by any CSS property should not be allowed in custom identifiers because many custom identifiers are also values of CSS properties. If they can be custom identifiers, then developers could create content that would be broken by the addition of these keywords as property values either to all CSS properties, or to a particular CSS property that already accepts custom identifiers.

Gesture Scroll DOM events Deprecated

Gesture Scroll DOM events, namely “gesturescrollstart”, “gesturescrollupdate” and “gesturescrollend” are non-standard APIs, which were added to Blink for use in plugins, but it appears they were also exposed to the web unintentionally. Plugins are no longer web-exposed since the deprecation of Google Native Client (NaCl). WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=92281 Changelog: https://bugs.webkit.org/attachment.cgi?id=155046&action=prettypatch

Intent stage: Removed

Currently, this API doesn’t work in all situations. It only works when there is a non-composited scroller. These events are related to compositing state, and compositing state is not meant to have observable behavior impact and in Blink will vary depending on display type and other factors.

Block iframe contexts navigating to filesystem: URLs Deprecated

Render-initiated navigations to filesystem:// URLs are blocked in top-level frames, but for some reason allowed in iframes. As part of the storage partitioning efforts, we propose to remove support for third party contexts, and consistently block navigation to filesystem:// URLs everywhere. See https://chromestatus.com/metrics/feature/timeline/popularity/4077 for usage details (currently extremely low).

Intent stage: Shipped

Render-initiated navigations to filesystem:// URLs are blocked in top-level frames, but for some reason allowed in iframes. As part of the storage partitioning efforts, we propose to remove support for navigation to filesystem:// URLs in third party contexts.