Since this trial didn't actually start in 156, which branched for Stable while this Intent was still open, I think we can treat 157-168 as the initial range of milestones for the trial. Note this technically is different from an extension which would require a new thread. LGTM to experiment instead in 157-168 inclusive. Please update the OT milestone fields in https://chromestatus.com/feature/5657801797009408 to 157-168.
On Thursday, October 8, 2026 at 1:18:21 PM UTC-7 Giovanni Del Valle wrote: > Requesting to extend from the initial 156-159 to experiment in 157-168 to > utilize 24 weeks. Thanks > > On Wednesday, October 7, 2026 at 3:49:57 PM UTC-7 Dan Clark wrote: > >> Thanks for clarifying that. LGTM to experiment in 156-159 inclusive. >> >> On Wednesday, October 7, 2026 at 3:37:00 PM UTC-7 Giovanni Del Valle >> wrote: >> >>> Only the embedded page will need to opt into the trial. So, there won't >>> be a need to try to control both sides for the origin trial. >>> The base connection allowlist feature origin trial would apply to the >>> embedding page, however that origin trial has finished. >>> >>> On Monday, September 28, 2026 at 5:01:51 PM UTC-7 Dan Clark wrote: >>> >>>> Will both the embedding page and the page embedded in the <iframe> need >>>> to opt in to the trial for this to work? What happens if one opts-in but >>>> not the other? >>>> I'm wondering if partners might have trouble working with the trial if >>>> they don't control both sides. Or is expected that devs opting into this >>>> experiment will control both the embedder and embedee pages and can opt in >>>> both? >>>> >>>> -- Dan >>>> >>>> On Friday, September 25, 2026 at 2:16:01 PM UTC-7 Giovanni Del Valle >>>> wrote: >>>> >>>>> We've gone ahead and kicked off assessments for security, privacy, and >>>>> debuggability. Debuggability has been approved, so now we just waiting on >>>>> security and privacy. >>>>> ------------------------------ >>>>> *From:* Alex Russell <[email protected]> >>>>> *Sent:* Monday, September 21, 2026 11:40 AM >>>>> *To:* blink-dev <[email protected]> >>>>> *Cc:* Giovanni Del Valle <[email protected]>; Brandon Maslen < >>>>> [email protected]> >>>>> *Subject:* Re: Intent to Experiment: Connection Allowlists Embedded >>>>> Enforcement >>>>> >>>>> You don't often get email from [email protected]. Learn why this >>>>> is important <https://aka.ms/LearnAboutSenderIdentification> >>>>> This feature looks great; I'd like to see an addition to it for >>>>> restricting resource loading to a web package that provides content for >>>>> the >>>>> source document. Will let other API OWNERs digest and perhaps LGTM, but >>>>> in >>>>> the mean time, perhaps we can also submit assesments for Security, >>>>> Privacy, >>>>> and Debuggability in the tool? >>>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Wednesday, September 16, 2026 at 4:50:48 PM UTC-7 Giovanni Del >>>>> Valle wrote: >>>>> >>>>> *Intent to Experiment: Connection Allowlists - Embedded Enforcement* >>>>> >>>>> *Contact emails* >>>>> >>>>> *[email protected]*, *[email protected]* >>>>> >>>>> *Explainer* >>>>> >>>>> https://github.com/WICG/connection-allowlists (embedded enforcement: >>>>> issues/1) >>>>> >>>>> *Specification* >>>>> >>>>> *https://wicg.github.io/connection-allowlists/* >>>>> <https://wicg.github.io/connection-allowlists/> >>>>> >>>>> *Design doc* >>>>> >>>>> >>>>> https://docs.google.com/document/d/1k7vcy3tPIYpD01DyuLEvEPYydOMAZRd8ASdIHX-uZi0 >>>>> >>>>> Base feature design doc: >>>>> https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA >>>>> >>>>> Implementation design (in-tree): >>>>> *https://chromium.googlesource.com/chromium/src/+/main/docs/connection_allowlist_design.md* >>>>> >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/connection_allowlist_design.md> >>>>> >>>>> *Summary* >>>>> >>>>> Connection Allowlists restrict the endpoints a document or worker may >>>>> connect to. This extension lets a parent document require an allowlist of >>>>> the content it embeds, via a connectionallowlist attribute on the iframe. >>>>> The embedded document either satisfies the requirement - by opting in >>>>> with >>>>> Allow-Connection-Allowlist-From, by delivering an at least as strict >>>>> Connection-Allowlist of its own, or implicitly if it is a local-scheme >>>>> document such as srcdoc or data: - or it is not loaded. The requirement >>>>> is >>>>> inherited by descendants and workers and re-checked on every navigation, >>>>> so >>>>> embedded content cannot escape it by nesting or redirecting. >>>>> >>>>> *Motivation* >>>>> >>>>> Embedders increasingly need to run embedded content in a sandboxed >>>>> environment. The sandbox attribute already constrains what such content >>>>> may >>>>> do: run script, submit forms, open popups, act with an origin. It says >>>>> nothing about where that content may connect. A fully sandboxed frame can >>>>> still reach any endpoint and send it whatever it can read, so the >>>>> dimension >>>>> that matters most for exfiltration is the one the platform cannot >>>>> currently >>>>> constrain. >>>>> >>>>> Connection Allowlists constrain exactly that, but only for the context >>>>> that delivers the header. An embedder cannot hold what it embeds to a >>>>> comparable restriction, so embedded content becomes the bypass. >>>>> Local-scheme frames cannot set response headers at all, so they cannot >>>>> participate even voluntarily. Embedded enforcement supplies the missing >>>>> network dimension of the sandbox, guaranteed to only tighten as it is >>>>> inherited, and mirrors CSP Embedded Enforcement (the csp attribute, >>>>> Sec-Required-CSP, Allow-CSP-From) so embedded policy enforcement stays a >>>>> single mechanism. >>>>> >>>>> *User-facing problem* >>>>> >>>>> A user cannot tell host content from embedded content; trust given to >>>>> the site covers the whole page. A site can promise not to send user data >>>>> to >>>>> arbitrary endpoints, but cannot make that promise on behalf of what it >>>>> embeds. The only containment tool available today, sandbox, cannot >>>>> restrict >>>>> connections. This means that one overly permissive widget, or one >>>>> injected >>>>> snippet in a srcdoc frame, breaks the promise invisibly. Embedded >>>>> enforcement lets the site extend the promise to everything it embeds, >>>>> however deeply content nests. >>>>> >>>>> *Use cases* >>>>> >>>>> - A privacy- or compliance-sensitive application embedding >>>>> third-party UI that must not reach arbitrary endpoints. >>>>> - A page rendering untrusted content in a srcdoc or data: frame - >>>>> newly possible, since local-scheme frames cannot set response headers >>>>> and >>>>> so could not participate before. >>>>> - A constrained document needing its guarantee to extend >>>>> transitively to embedded frames and the workers they spawn. >>>>> >>>>> *Accessibility, Privacy, and Security Considerations* >>>>> >>>>> Accessibility: no impact. The feature affects only whether connections >>>>> are permitted and whether a frame commits; it does not change rendering, >>>>> focus, or assistive technology behavior. >>>>> >>>>> Security: a defense-in-depth feature, fail-closed - an unsatisfied >>>>> requirement blocks the frame rather than loading it unenforced. An >>>>> embedder >>>>> cannot silently impose policy on unwilling cross-origin content (the >>>>> embedded document must opt in), and the requirement can only tighten as >>>>> it >>>>> is inherited. >>>>> >>>>> Privacy: no new cross-origin information about the user is exposed. An >>>>> embedded document can observe that it is subject to a requirement, since >>>>> that requirement is sent to it directly as >>>>> Sec-Required-Connection-Allowlist - information the embedder deliberately >>>>> discloses, analogous to Sec-Required-CSP. A blocked document never loads >>>>> and observes nothing. >>>>> >>>>> *Blink component* >>>>> >>>>> Blink>SecurityFeature>ConnectionAllowlist >>>>> >>>>> *Search tags* >>>>> >>>>> connection allowlist, iframe, embedded enforcement, CSP, security >>>>> >>>>> *TAG review / status* >>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/1173 >>>>> >>>>> Status: Resolved, satisfied (closed 9 Jul 2026). >>>>> >>>>> *Risks* >>>>> >>>>> *Interoperability and Compatibility* >>>>> >>>>> Still incubating in the WICG, so shape and functionality may not be >>>>> final. Enforcement can block a frame from loading, but only where an >>>>> embedder explicitly sets the attribute, so existing content is unaffected. >>>>> >>>>> - Gecko: Positive - >>>>> https://github.com/mozilla/standards-positions/issues/1322 >>>>> (position: positive, closed 7 Aug 2026). >>>>> - WebKit: No signal - >>>>> https://github.com/WebKit/standards-positions/issues/583 (open, no >>>>> formal reply as of this draft). >>>>> - Web developers: Positive - >>>>> https://github.com/WICG/connection-allowlists/issues/1 >>>>> >>>>> *Ergonomics* >>>>> >>>>> Follows the CSP embedded enforcement pattern developers already know. >>>>> A framed document that already ships a compatible Connection-Allowlist >>>>> needs no changes, and local-scheme documents opt in implicitly. >>>>> >>>>> *Activation* >>>>> >>>>> <iframe src="https://example.com/widget"; >>>>> connectionallowlist="(response-origin)"></iframe> >>>>> >>>>> The framed document then opts in via Allow-Connection-Allowlist-From, >>>>> delivers a subsuming Connection-Allowlist, or qualifies implicitly as a >>>>> local-scheme document. >>>>> >>>>> *WebView application risks* >>>>> >>>>> None. The feature is inert unless an embedder sets the attribute, so >>>>> no existing content changes behavior. >>>>> >>>>> *Goals for experimentation* >>>>> >>>>> - Validate the implementation in real deployments and confirm it >>>>> unblocks the motivating partner. >>>>> - Confirm the three satisfaction paths match how embedders and >>>>> embedded parties actually coordinate, and that subsumption ("at least >>>>> as >>>>> strict as") behaves as expected for realistic allowlists. >>>>> - Measure how often each outcome occurs via the four UseCounters — >>>>> in particular whether blocking is rare and whether one satisfaction >>>>> path >>>>> dominates. >>>>> - Evaluate inheritance ergonomics through nested documents and >>>>> workers, and confirm the never-loosen rule causes no unexpected >>>>> breakage. >>>>> >>>>> *Ongoing technical constraints* >>>>> >>>>> None >>>>> >>>>> *Debuggability* >>>>> >>>>> Blocked responses raise a DevTools issue >>>>> (ConnectionAllowlistEmbeddedEnforcementIssue); a separate issue covers an >>>>> invalid Allow-Connection-Allowlist-From header. Blocked requests appear >>>>> in >>>>> the Network panel, the handshake headers are inspectable there, and the >>>>> connectionAllowlist IDL attribute is readable from the console. >>>>> >>>>> *Will this feature be supported on all six Blink platforms?* >>>>> >>>>> Yes. >>>>> >>>>> *Is this feature fully tested by web-platform-tests?* >>>>> >>>>> Yes >>>>> >>>>> *Flag name on about://flags* >>>>> >>>>> Experimental Web Platform features >>>>> (about://flags#enable-experimental-web-platform-features). There is no >>>>> dedicated about://flags entry for embedded enforcement; the separate >>>>> "Connection allowlists" entry toggles only the base network feature, >>>>> which >>>>> is already enabled by default. >>>>> >>>>> *Finch feature name* >>>>> >>>>> ConnectionAllowlistEmbeddedEnforcement >>>>> >>>>> *Origin trial feature name* >>>>> >>>>> ConnectionAllowlistEmbeddedEnforcement >>>>> >>>>> *Requires code in //chrome?* >>>>> >>>>> False >>>>> >>>>> *Tracking bug* >>>>> >>>>> *https://issues.chromium.org/issues/522111613* >>>>> <https://issues.chromium.org/issues/522111613> >>>>> >>>>> *Estimated milestones* >>>>> >>>>> >>>>> Origin trial desktop first >>>>> >>>>> 156 >>>>> >>>>> Origin trial desktop last >>>>> >>>>> 159 >>>>> >>>>> Origin trial Android first >>>>> >>>>> 156 >>>>> >>>>> Origin trial Android last >>>>> >>>>> 159 >>>>> >>>>> Origin trial WebView first >>>>> >>>>> 156 >>>>> >>>>> Origin trial WebView last >>>>> >>>>> 159 >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> >>>>> https://chromestatus.com/feature/5657801797009408 >>>>> >>>>> Feedback submission: >>>>> *https://github.com/WICG/connection-allowlists/issues* >>>>> <https://github.com/WICG/connection-allowlists/issues> >>>>> >>>>> *Links to previous Intent discussions* >>>>> >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/QHhBWQ0oUrA >>>>> >>>>> Base feature ChromeStatus entry: >>>>> https://chromestatus.com/feature/5175745573945344 >>>>> >>>>> Base feature Intent to Experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/lRMJ8iwaKbM >>>>> >>>>> Base feature Intent to Ship: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3d7aca.54d5f168.18adb4.00dd.GAE%40google.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/dbca2010-dca8-4392-a38b-e485b764a5e0n%40chromium.org.
