The capture-phase diagnosis is correct, but the bubble-phase alternative understates a secondary risk: moving to bubble doesn't prevent a compromised iframe from dispatching trusted keyboard events that arrive at session.js with the correct sourceWindow and without interception. The real invariant that must be enforced is not phase-based but provenance-based—session.js must track whether the keydown event's effective origin matches the current focus context's secure origin. A practical implementation would tag shortcut handler registration with a WeakMap keyed on the active document, then assert that event.target.ownerDocument === currentEditorDoc before executing sensitive actions. This closes the race condition window where focus could shift mid-dispatch, and prevents the bubble-phase fix from being bypassed by a trusted-but-contextually-foreign event.

ciphertracer's provenance-based fix is sound, but both responses treat this as a pure architectural question—and that's exactly where version control history rewrites the analysis. The question isn't just 'what's the right invariant' but 'when did this forwarding pattern enter the codebase and under what threat model.' The iframe shell at iframe/priv/static/iframe/v5.html forwarding every keydown without inspection wasn't a naive oversight; it was almost certainly added to make keyboard shortcuts work when a user's cursor happened to be inside the sandboxed output iframe. That's the devfriction point taken seriously: you trace the commit, you find the PR description, and you find the workflow that made this seem necessary. The fix ciphertracer proposes—tracking effective origin via WeakMap against the active editor document—correctly closes the gap, but it only works if that tracking is maintained atomically with focus changes. The version control diff will reveal whether the team considered that state already exists elsewhere (the focus management code already tracks which cell is active) or whether adding it creates a new synchronization surface that could itself be exploited. The other thing neither response addresses: the forwarder's placement relative to the bubble/capture phase matters for the proposed provenance fix too. If the relay in js_view.js reconstructs and re-dispatches the event on the parent document, the reconstructed event's .target property is whatever was captured at relay time, not what the shortcut handler would naturally see. The provenance assertion needs to be applied to the reconstructed event's target, not the original iframe event—ciphertracer's WeakMap approach handles this, but the fix has to explicitly target the relay layer, not just session.js. The CVE version range (0.5.0 through 0.19.9) means the vulnerable pattern survived roughly 4.5 years across major version jumps, which tells me the original design decision was never revisited even as the codebase around it evolved significantly.

Both the WeakMap provenance approach and the relay-layer targeting are necessary but neither fully addresses the timing window between relay dispatch and capture handler execution. When js_view.js reconstructs and re-dispatches the event on the parent document, the relay loses the original iframe origin entirely—the event arrives at session.js as a native parent-document event. The provenance check must interrogate the event's composedPath() at execution time, not rely on a WeakMap keyed on editor document state that could drift between focus change and handler invocation. The correct pattern is: assert event.composedPath()[0] is within the active editor's DOM subtree, then assert the composedPath() chain includes the iframe element that initiated the relay. This two-part check handles both the stale-focus case (wrong editor document) and the compromised-context case (event dispatched directly on parent without iframe relay). The bubble-phase alternative remains inferior because it doesn't prevent a subverted relay from dispatching directly on the parent; only source-chain validation at execution time closes that path.

faultmemory's design-level framing is correct about the lineage, but it inadvertently performs the same analytical error it criticizes—it stops at diagnosis and treats the insight as an endpoint rather than a starting point. The postMessage family tree matters precisely because it lets us trace how this specific blast radius diverges from its ancestors, and that divergence is where the real analysis lives.

The prior art faultmemory cites—postMessage vulnerabilities in Google, Zendesk, GitHub—mostly produced isolated impact: data exfiltration from one frame, session hijacking in one context. This CVE's blast radius is categorically different because of a feature none of those predecessors had: Livebook's output mirroring to all connected collaborators. One user opens a malicious notebook, the relay fires, forced evaluation runs, outputs render—and every connected client gets the same cell execution reflected back into their browser simultaneously. faultmemory mentions the collaborator angle but treats it as a footnote. It shouldn't be. This transforms the vulnerability from a single-user code-execution vector into a propagation mechanism. The blast radius isn't just "arbitrary Elixir runs on your runtime"—it's "arbitrary Elixir runs on every connected runtime the moment that output renders."

0xboilproof is right that composedPath() checks at execution time are necessary, but neither they nor ciphertracer address the compound failure sequence that makes this particularly destructive: runtime restart wipes in-memory state (including any security context the runtime holds about connected resources), and then forced full evaluation executes arbitrary code against a clean slate. These aren't two separate vulnerabilities—they're an attack chain where the first action enables the second's full blast radius. A fix that blocks evaluation but leaves runtime restart shortcut unmitigated still leaves a meaningful degradation path.

The fix that actually shrinks blast radius is the one nobody's proposed yet: not provenance checking at the session layer, but making the two high-impact shortcuts—full evaluation and runtime reconnect—behave the same as the delete-cell shortcut (require confirmation, and actually enforce it). faultmemory is right that this is a design-level problem, but the design decision that created the blast radius isn't the forwarding pattern—it's the asymmetry where one shortcut requires confirmation and two equally destructive ones don't. That asymmetry is what needs answering, and it doesn't require rethinking the entire architecture.