Intent to Ship: Connection Allowlists

[Chromestatus]

Contact emails

shiva...@chromium.org, mk...@chromium.org, skman...@chromium.org

Explainer

https://github.com/WICG/connection-allowlists

Specification

https://wicg.github.io/connection-allowlists

Summary

Connection Allowlists is a feature designed to provide explicit control over external endpoints by restricting connections initiated via the Fetch API or other web platform APIs from a document or worker. The proposed implementation involves the distribution of an authorized endpoint list from the server through an HTTP response header. Prior to the establishment of any connection by the user agent on behalf of a page, the agent will evaluate the destination against this allowlist; connections to verified endpoints will be permitted, while those failing to match the entries in the list will be blocked. More details on the proposal can be found here: https://github.com/WICG/connection-allowlists Design doc: https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA/edit?usp=sharing Implementation Design: https://source.chromium.org/chromium/chromium/src/+/main:docs/connection_allowlist_design.md

Blink component

Blink>SecurityFeature>ConnectionAllowlist

Web Feature ID

Missing feature

Motivation

Developers wish to have control over the resources loaded into their pages' contexts and the endpoints to which their pages can make requests. This control is necessary for several purposes, including limiting the ways in which users' data can flow through the user agent (mitigating exfiltration attacks) and ensuring control over a site’s architecture and dependencies. Content Security Policy addresses some of this need, but does so in a way that is more granular than necessary for the most critical use cases, and with a syntax and grammar that’s complicated by the other protections CSP is used to deploy. `Connection-Allowlist` steps back from CSP, and focuses on the single use case of controlling the explicit requests a page may initiate through Fetch and other web platform APIs (Navigations, preload, DNS Prefetch, WebRTC, Web Transport, etc) in a way that aims to be straightforward and comprehensive. Example: Connection-Allowlist: (response-origin "https://cdn.example" "https://*.example.:tld" \ "https://api.example:*"); report-to=ReportingAPIEndpoint

Initial public proposal

https://github.com/WICG/proposals/issues/235

Search tags

Connection Allowlists

TAG review

https://github.com/w3ctag/design-reviews/issues/1173

TAG review status

Pending

Origin Trial Name

Connection Allowlists

Goals for experimentation

Origin Trial's goal was to gain insights on websites' usage of Connection Allowlist header and receive feedback from developers on whether there are any updates that would be useful. As was mentioned in the I2E, at the start of OT, the following network endpoints were implemented: Subresources fetch, Navigations, Redirects, fetches from local scheme navigations (via connection allowlists inherited from the navigation's initiator), history.back/forward navigations, rel=prefetch, rel=preconnect, rel=preload, rel=modulepreload, , rel=dns-prefetch, and their link header equivalents. As OT progressed, support was added for remaining known network endpoints including webRTC, WebTransport, WebSocket and others. Connection allowlists support documents, dedicated workers, shared workers and service workers.

Chromium Trial Name

ConnectionAllowlist

Origin Trial documentation link

https://developer.chrome.com/blog/connection-allowlists-origin-trial

WebFeature UseCounter name

kConnectionAllowlist

Risks

Interoperability and Compatibility

This is a new feature. We are interacting with other browsers via discussions on GitHub and in the Community Group. However, there is no official signal yet from any other browser vendors about their implementation plans.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1322) We think there's agreement on the value of this functionality, but differences of opinion on what the header looks like. There has been good interaction on some of the issues in the repo and in the WebAppSec meetings.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/583) No official position, but there has been good interaction on some of the issues in the repo and in the WebAppSec meetings.

Web developers: Positive (https://github.com/WICG/proposals/issues/235#issuecomment-3463775783) We have had multiple developers using Connection Allowlists through the Origin Trial and are planning to continue to use it. Microsoft is also collaborating on enhancements like https://github.com/WICG/connection-allowlists/issues/1

Other signals: Edge: Positive (https://github.com/WICG/proposals/issues/235#issuecomment-3463775783)

Ergonomics

This feature will be frequently used in tandem with existing Web Platform Security mechanisms like Content Security Policy, Sandbox etc. We expect no impact on Chrome's performance.

Activation

No challenges for developers to take advantage of this feature immediately.

Security

This feature should be beneficial for security because it allows documents and workers to restrict network communication that could exfiltrate sensitive data.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No. This is a new feature.

Debuggability

To assist developers in debugging malformed headers, parsing errors are reported directly to the DevTools Issues tab. Additionally, the reporting infrastructure for Connection-Allowlist was introduced to support both enforced violation reporting and a "report-only" mode, allowing developers to monitor potential breakages without interrupting service.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://github.com/web-platform-tests/wpt/tree/master/connection-allowlist/tentative

Flag name on about://flags

connection-allowlists

Finch feature name

ConnectionAllowlists

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/447954811

Measurement

UseCounter has been added for measuring the usage of the feature

Availability expectation

Feature is available only in Chromium browsers for the foreseeable future.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome.

Adoption plan

Some of the partners are already participating in the Origin Trial and they are expected to adopt the feature as it ships in Chrome. The use counter can be seen here: https://chromestatus.com/metrics/feature/timeline/popularity/5867

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None

Estimated milestones

Shipping on desktop	152
Origin trial desktop first	148
Origin trial desktop last	151
Shipping on Android	152
Origin trial Android first	148
Origin trial Android last	151
Shipping on WebView	152
Origin trial WebView first	148
Origin trial WebView last	151

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/WICG/connection-allowlists/issues Note that issues marked as enhancement, like https://github.com/WICG/connection-allowlists/issues/1, https://github.com/WICG/connection-allowlists/issues/28 are not included in this entry and will be launched via a separate I2S, but are additive and backward-compatible.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175745573945344?gate=6083622706741248

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a779c1.050a0220.1426e8.0068.GAE%40google.com

This intent message was generated by Chrome Platform Status.