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.

Reply via email to