LGTM, but see my question below about OT length.

On 3/3/26 7:19 p.m., Shivani Sharma wrote:



On Tue, Mar 3, 2026 at 7:16 PM Chromestatus <[email protected]> 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


    *Blink component*
    Blink>SecurityFeature>ConnectionAllowlist
    
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EConnectionAllowlist%22>

    *Web Feature ID*
    Missing feature

    *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 documentation link*
    https://github.com/WICG/connection-allowlists

    *Risks*


    *Interoperability and Compatibility*
    This is a new feature. We are actively evolving the design via
    discussions on GitHub and in the Community Group. However, there
    is no signal yet from any other browser vendors about their
    implementation plans.

    /Gecko/: No
    signal (https://github.com/mozilla/standards-positions/issues/1322)

    /WebKit/: No
    signal (https://github.com/WebKit/standards-positions/issues/583)

    /Web developers/:
    Positive 
(https://github.com/WICG/proposals/issues/235#issuecomment-3463775783)

    /Other signals/:

    *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
    frames to restrict network communication that could exfiltrate
    sensitive data. Please note that we are continuing to add more
    network endpoints that prevent exfiltration via connection
    allowlists as OT will progress.

    *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.


    *Goals for experimentation*
    /No information provided/


Due to GoogleChrome/chromium-dashboard#4155 <https://github.com/GoogleChrome/chromium-dashboard/issues/4155> this wasn't filled in. It should read:

We are looking to gain insights on websites' usage of the Connection Allowlist header and would like to receive feedback from developers on any useful updates. At the start of OT, the following network endpoints are addressed: Subresources fetch, Navigations, Redirects, fetches from local scheme navigations are subjected to the connection allowlist restrictions from the initiator, history.back/forward navigations, rel=prefetch, rel=preconnect, rel=preload, rel=modulepreload, , rel=dns-prefetch, and their link header equivalents. Remaining network endpoints like webRTC, WebTransport, WebSocket, speculative preconnect and other known network endpoints will continue to be added as OT progresses. Additionally at the start of OT, the contexts that support connection allowlist are documents, dedicated workers and shared workers. Shortly, we will also add support for service workers.
You've requested 4 milestones for this OT  (which is fine - you can have up to 6 up front). Is that enough time to land support for the remaining network endpoints and get feedback?



    *Ongoing technical constraints*
    None

    *Debuggability*
    To assist developers in debugging blocked requests or malformed
    headers, parsing errors and enforcement issues 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

    *Requires code in //chrome?*
    True

    *Tracking bug*
    https://issues.chromium.org/issues/447954811

    *Measurement*
    We will be adding metrics for the usage of the feature

    *Estimated milestones*
    Origin trial desktop first  147
    Origin trial desktop last   150
    Origin trial Android first  147
    Origin trial Android last   150
    Origin trial WebView first  147
    Origin trial WebView last   150



    *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

    *Link to entry on the Chrome Platform Status*
    https://chromestatus.com/feature/5175745573945344?gate=5415518666358784

    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/CADAcp09i5WF7sji8mTpixKR7BAho4hs8roCcqafEOGwbcrtuZA%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp09i5WF7sji8mTpixKR7BAho4hs8roCcqafEOGwbcrtuZA%40mail.gmail.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/ebba43e5-10ed-4995-b000-300672c37f36%40chromium.org.

Reply via email to