Contact emails [email protected], [email protected], [email protected]
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 (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, 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. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3d7aca.54d5f168.18adb4.00dd.GAE%40google.com.
