Intent to Experiment: Connection Allowlists

[Chromestatus]

Contact emails

shiva...@chromium.org, mk...@chromium.org, skman...@chromium.org

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

Web Feature ID

Missing feature

Search tags

Connection Allowlists

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

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?

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.

[Shivani Sharma]

Due to GoogleChrome/chromium-dashboard#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.

[Mike Taylor]

LGTM, but see my question below about OT length.

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? 

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp09i5WF7sji8mTpixKR7BAho4hs8roCcqafEOGwbcrtuZA%40mail.gmail.com.