LGTM2 On Fri, Jun 26, 2026 at 8:59 PM Mike Taylor <[email protected]> wrote:
> I think this is a great addition to the platform - LGTM1 > On 6/25/26 3:00 p.m., Chromestatus wrote: > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EConnectionAllowlist%22> > > *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://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 <http:///features#tags:Connection%20Allowlists> > > *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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > -- > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3d7aca.54d5f168.18adb4.00dd.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- > 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/5643d1cf-b41b-4217-a168-1a563a394938%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5643d1cf-b41b-4217-a168-1a563a394938%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOmohS%2B36kzm1QC-eF3KEC2ixwXGAbCtB1YBSWXW04-rr0%2B%3DNQ%40mail.gmail.com.
