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/2ca5a60d-6c5d-4bb7-ad4d-5e599b81291bn%40chromium.org.
