LGTM3

On Friday, June 26, 2026 at 12:30:06 PM UTC-7 Yoav Weiss wrote:

> 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/1ed26fb0-9b20-4eed-9823-c2183dabea11n%40chromium.org.

Reply via email to