Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 102 is beta as of April 28, 2022. You can download the latest on Google.com for desktop or on Google Play Store on Android.

Window Controls Overlay for Installed Desktop Web Apps

Window controls overlay extends an app's client area to cover the entire window, including the title bar, and the window control buttons (close, maximize/restore, minimize). The web app developer is responsible for drawing and input handling for the entire window except for the window controls overlay. Developers can use this feature to make their installed desktop web apps look like operating system apps. For more information, see Customize the window controls overlay of your PWA's title bar.

Completed Origin Trials

The following features, previously in a Chrome origin trial, are now enabled by default. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.

Capture Handle

A new mechanism allows an application to opt-in to exposing information to applications that are video-capturing it. This allows collaboration between capturing and captured applications. For example, a video conference application that's video-capturing a presentation, could expose user-facing controls in the video conference tab for navigating the presentation in the captured tab.

Network State Partitioning

Network state is now partitioned by the network partition key (which consists of top frame site and possibly frame site), to protect against cross-site tracking through the use of side channels. "Network State" here includes connections (H1, H2, H3, websocket), the DNS cache, ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL configuration and uploads, and Expect-CT information. Cross-site tracking is a major privacy concern for users. This is a necessary part of addressing the problem.

Speculation Rules

Speculation rules provides a flexible syntax for defining what outgoing links are eligible to be prefetched before navigation. It also enables additional enhancements, such as use of a private prefetch proxy, where applicable.

Subresource loading with Web Bundles

This feature provides a new approach to loading a large number of resources efficiently using a format that allows multiple resources to be bundled, e.g. Web Bundles.

Other Features in this Release

File Handlers Web App Manifest Member

File Handling provides a way for web applications to declare the ability to handle files with given MIME types and extensions. The web application will receive an event when the user intends to open a file with that web application.

To define a PWA as a file handler, add the file_handlers member to the Web App Manifest. You can read about its members in the spec.

inert Attribute

The new inert attribute lets you mark parts of the DOM tree as inert. When a node is inert:

• Hit-testing must act as if the pointer-events CSS property were set to 'none'.
• Text selection functionality must act as if the user-select CSS property were set to 'none'.
• If it is editable, the node behaves as if it were non-editable.
• The user agent may ignore the node for the purposes of find-in-page.

  For more information, see Introducing inert.

  Local Font Access

  Web applications can now enumerate local fonts and metadata about each. The new API also gives web applications access to table data stored within local fonts, allowing those fonts to be rendered within their applications using custom text stacks.

  Notes: This feature actually shipped in 103 instead of 102 as originally reported.

  Navigation API

  The new Navigation interface (accessible on window) lets apps intercept and initiate navigations, and introspect an application's history entries. This provides a more useful alternative to window.history and window.location specifically aimed at the needs of single-page web applications.

  New until-found Value for the hidden Attribute

  Chrome adds a new value, until-found, for the hidden attribute, which makes an element searchable by find-in-page, scroll to text fragment, and fragment navigation. When these search/navigation features want to scroll to something inside a hidden=until-found element, the browser removes the hidden attribute from the element and fires the beforematch event on it so that the newly revealed content can be scrolled into view. For more information, see Making collapsed content accessible with hidden=until-found - Chrome Developers.

  Origin Private File System extension: AccessHandle

  The Origin Private File System (part of the File System Access API) is augmented with a new surface that improves the performance of data access. This new surface differs from existing ones by offering in-place and exclusive write access to a file's content. This change, along with the ability to consistently read unflushed modifications and the availability of a synchronous variant on dedicated workers, significantly improves performance and unblocks new use cases.

  Private Network Access Preflight Requests for Subresources

  A CORS preflight request is now sent ahead of schedule for private network requests for subresources, requesting explicit permission from the target server. If the preflight fails, a warning is displayed in DevTools but the request proceeds as before. This is not expected to be a breaking change. Websites whose servers ignore or fail the new preflight request will continue to work as before.

  A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.

  Secure Payment Confirmation API Changes

  This release contains three changes to the Secure Payment Confirmation API, specifically to the data passed to the PaymentMethod() constructor.

  • A new required property, data.rpId, which should contain the relying party ID. Implementations that don't currently specify this will need to be updated.
  • A new optional property, data.instrument.iconMustBeShown, allows a placeholder icon to be used when the card art icon cannot be downloaded. Setting this field to false allows a payment to proceed when the icon can be downloaded. The default is true.
  • A new optional property, data.payeeName, allows callers to display a natural name for the payee instead of or alongside the existing data.payeeOrigin.

    WebHID exclusionFilters Option in requestDevice()

    The options object passed HID.requestDevice() now includes an exclusionFilters property. (HID is accessed via navigator.hid.) This property lets you exclude some devices from the browser picker. You can use it to exclude devices that are known to be malfunctioning. Previously, developers had to test a selected device with custom code, then ask the user to pick another if the selected device did not work. The exclusionFilters property (you will need to search for that term in the text) is an array of objects with the same members as the existing options.

    Here's an example of how to use the requestDevice() options argument. The example first requests access to a device with vendor ID 0xABCD. The device must also have a collection with usage page Consumer (0x000C) and usage ID Consumer Control (0x0001). The device with product ID 0x1234 is malfunctioning.

    const [device] = await navigator.hid.requestDevice({
     filters: [{ vendorId: 0xabcd, usagePage: 0x000c, usage: 0x0001 }],
     exclusionFilters: [{ vendorId: 0xabcd, productId: 0x1234 }],
    });
    
    
    Deprecations, and Removals
    This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations  and previous removals.
    
    Deprecate PaymentRequest.show() without User Activation
    Sites can no longer call PaymentRequest.show() without a user activation. Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation. To avoid a broken purchase experience, calls to this method should now be inside a user event such as click.
    
    Firefox has not shipped PaymentRequest at all, while Safari's implementation already requires user activation for calling show().
    
    Remove SDP Plan B
    The Session Description Protocol (SDP) used to establish a session in WebRTC has been implemented with two different dialects in Chromium: Unified Plan and Plan B. Plan B is not cross-browser compatible and is hereby removed. 
    
    In this version of Chrome an exception will be thrown when Plan B is used. Developers needing to avoid the exception can participate in a deprecation trial until May 25, 2022. If you participated in the previous deprecation trial that ended in December, and want to participate in the current trial, you will need to request a new token.
    
        
    
                            
    Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 102 is beta as of April 28, 2022. You can download the latest on Google.com for desktop or on Google Play Store on Android. 
    
    Window Controls Overlay for Installed Desktop Web Apps
    Window controls overlay extends an app's client area to cover the entire window, including the title bar, and the window control buttons (close, maximize/restore, minimize). The web app developer is responsible for drawing and input handling for the entire window except for the window controls overlay. Developers can use this feature to make their installed desktop web apps look like operating system apps. For more information, see Customize the window controls overlay of your PWA's title bar.
    
    
    
    Completed Origin Trials
    The following features, previously in a Chrome origin trial, are now enabled by default. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.
    
    Capture Handle
    A new mechanism allows an application to opt-in to exposing information to applications that are video-capturing it. This allows collaboration between capturing and captured applications. For example, a video conference application that's video-capturing a presentation, could expose user-facing controls in the video conference tab for navigating the presentation in the captured tab.
    
    Network State Partitioning
    Network state is now partitioned by the network partition key (which consists of top frame site and possibly frame site), to protect against cross-site tracking through the use of side channels. "Network State" here includes connections (H1, H2, H3, websocket), the DNS cache, ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL configuration and uploads, and Expect-CT information. Cross-site tracking is a major privacy concern for users. This is a necessary part of addressing the problem.
    
    Speculation Rules
    Speculation rules provides a flexible syntax for defining what outgoing links are eligible to be prefetched before navigation. It also enables additional enhancements, such as use of a private prefetch proxy, where applicable.
    
    Subresource loading with Web Bundles
    This feature provides a new approach to loading a large number of resources efficiently using a format that allows multiple resources to be bundled, e.g. Web Bundles.
    
    Other Features in this Release
    
    File Handlers Web App Manifest Member
    File Handling provides a way for web applications to declare the ability to handle files with given MIME types and extensions. The web application will receive an event when the user intends to open a file with that web application.
    
    To define a PWA as a file handler, add the file_handlers member to the Web App Manifest. You can read about its members in the spec.
    
    inert Attribute
    The new inert attribute lets you mark parts of the DOM tree as inert. When a node is inert:
    
    
    Hit-testing must act as if the pointer-events CSS property were set to 'none'.
    Text selection functionality must act as if the user-select CSS property were set to 'none'.
    If it is editable, the node behaves as if it were non-editable.
    The user agent may ignore the node for the purposes of find-in-page.
    
    
    For more information, see Introducing inert.
    
    Local Font Access
    Web applications can now enumerate local fonts and metadata about each. The new API also gives web applications access to table data stored within local fonts, allowing those fonts to be rendered within their applications using custom text stacks.
    Notes: This feature actually shipped in 103 instead of 102 as originally reported.
    
    Navigation API
    The new Navigation interface (accessible on window) lets apps intercept and initiate navigations, and introspect an application's history entries. This provides a more useful alternative to window.history and window.location specifically aimed at the needs of single-page web applications.
    
    New until-found Value for the hidden Attribute
    Chrome adds a new value, until-found, for the hidden attribute, which makes an element searchable by find-in-page, scroll to text fragment, and fragment navigation. When these search/navigation features want to scroll to something inside a hidden=until-found element, the browser removes the hidden attribute from the element and fires the beforematch event on it so that the newly revealed content can be scrolled into view. For more information, see Making collapsed content accessible with hidden=until-found - Chrome Developers.
    
    Origin Private File System extension: AccessHandle
    The Origin Private File System (part of the File System Access API) is augmented with a new surface that improves the performance of data access. This new surface differs from existing ones by offering in-place and exclusive write access to a file's content. This change, along with the ability to consistently read unflushed modifications and the availability of a synchronous variant on dedicated workers, significantly improves performance and unblocks new use cases.
    
    Private Network Access Preflight Requests for Subresources
    A CORS preflight request is now sent ahead of schedule for private network requests for subresources, requesting explicit permission from the target server. If the preflight fails, a warning is displayed in DevTools but the request proceeds as before. This is not expected to be a breaking change. Websites whose servers ignore or fail the new preflight request will continue to work as before.
    
    A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.
    
    Secure Payment Confirmation API Changes
    This release contains three changes to the Secure Payment Confirmation API, specifically to the data passed to the PaymentMethod() constructor. 
    
    A new required property, data.rpId, which should contain the relying party ID. Implementations that don't currently specify this will need to be updated.
    A new optional property, data.instrument.iconMustBeShown, allows a placeholder icon to be used when the card art icon cannot be downloaded. Setting this field to false allows a payment to proceed when the icon can be downloaded. The default is true.
    A new optional property, data.payeeName, allows callers to display a natural name for the payee instead of or alongside the existing data.payeeOrigin.
    
    
    WebHID exclusionFilters Option in requestDevice()
    The options object passed HID.requestDevice() now includes an exclusionFilters property. (HID is accessed via navigator.hid.) This property lets you exclude some devices from the browser picker. You can use it to exclude devices that are known to be malfunctioning. Previously, developers had to test a selected device with custom code, then ask the user to pick another if the selected device did not work. The exclusionFilters property (you will need to search for that term in the text) is an array of objects with the same members as the existing options. 
    
    Here's an example of how to use the requestDevice() options argument. The example first requests access to a device with vendor ID 0xABCD. The device must also have a collection with usage page Consumer (0x000C) and usage ID Consumer Control (0x0001). The device with product ID 0x1234 is malfunctioning.
    
    const [device] = await navigator.hid.requestDevice({
     filters: [{ vendorId: 0xabcd, usagePage: 0x000c, usage: 0x0001 }],
     exclusionFilters: [{ vendorId: 0xabcd, productId: 0x1234 }],
    });
    
    
    Deprecations, and Removals
    This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations  and previous removals.
    
    Deprecate PaymentRequest.show() without User Activation
    Sites can no longer call PaymentRequest.show() without a user activation. Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation. To avoid a broken purchase experience, calls to this method should now be inside a user event such as click.
    
    Firefox has not shipped PaymentRequest at all, while Safari's implementation already requires user activation for calling show().
    
    Remove SDP Plan B
    The Session Description Protocol (SDP) used to establish a session in WebRTC has been implemented with two different dialects in Chromium: Unified Plan and Plan B. Plan B is not cross-browser compatible and is hereby removed. 
    
    In this version of Chrome an exception will be thrown when Plan B is used. Developers needing to avoid the exception can participate in a deprecation trial until May 25, 2022. If you participated in the previous deprecation trial that ended in December, and want to participate in the current trial, you will need to request a new token.
    
    
    
    
    

Today, we've started an origin trial for the Privacy Sandbox ads relevance and measurement proposals (Topics, FLEDGE and Attribution Reporting APIs) for a limited number of Chrome Beta users. Developers can register and begin to set up their origin trial tests. We will continue to provide regular updates as the origin trial progresses.

***

We’re excited to share that Chrome is starting the next stage of testing for the Privacy Sandbox ads relevance and measurement proposals.

Starting today, developers can begin testing globally the Topics, FLEDGE, and Attribution Reporting APIs in the Canary version of Chrome. We’ll progress to a limited number of Chrome Beta users as soon as possible. Once things are working smoothly in Beta, we’ll make API testing available in the stable version of Chrome to expand testing to more Chrome users.

We recognize that developers will need some time to use the APIs, validate the data flows, and measure performance. We are looking forward to companies providing feedback as they move through the different testing phases, which will allow us to continually improve the APIs. Once we’re confident that the APIs are working as designed, we’ll make them broadly available in Chrome, allowing more developers to integrate, evaluate and provide feedback as we continue to optimize them for their use cases.

Developers can expect support from Chrome in the form of developer guidance, regular updates, and a range of feedback and engagement channels. We strongly encourage developers to share feedback publicly and with Chrome, and we’ll closely monitor progress along the way. We also welcome the role industry associations can play in this process, from facilitating collaborative industry tests to aggregating feedback themes.

Chrome will also begin testing updated Privacy Sandbox settings and controls that allow users to see and manage the interests associated with them, or turn off the trials entirely.

Caption: Chrome will be testing updated Privacy Sandbox settings and controls.

The Privacy Sandbox proposals have already benefited substantially from the thoughtful feedback of early testers, and we’re eager to open up testing for more of our proposals. We’ll continue to gather feedback from the ecosystem and to engage with regulators globally, including through our work with the UK’s Competition and Markets Authority in line with our commitments for the Privacy Sandbox on the web. If you’re interested in learning more about the APIs and how you can participate, please see our detailed developer guidance.

Posted by Vinay Goel, Product Director, Privacy Sandbox, Chrome