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/4a529508-ace2-4b01-9af8-55114584475en%40chromium.org.
