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/b8d89ae2-266f-467a-97dd-187274c6ba9cn%40chromium.org.
