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://*.example.:tld"; \ "https://api.example:*";);
report-to=ReportingAPIEndpoint
*Initial public proposal*
https://github.com/WICG/proposals/issues/235
*Search tags*
Connection Allowlists </features#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
<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.
