Bind widget messages to an origin, window and current view

Choose a separate widget surface

A fictional AI console deliberately embeds a note-drafting widget. Its host displays workspace WS-A, then the user switches to WS-B while an older draft is still being prepared. The receiver needs a transport-specific answer: which widget context and host view may supply this proposal?

This is a new, deliberately reviewed embedding surface. It does not relax the support-answer rendering contract, which excludes frames. The design below uses native Window messages only, with no transferred ports, shared memory, account credentials or final tool commands. Every worksheet case is PROPOSED_UNRUN.

Separate three kinds of association

MDN’s postMessage reference describes event.origin as the sender’s origin when the call occurred, not necessarily that window’s current or future origin. Compare it with one configured serialized HTTPS origin, including the effective port. Our proposed profile uses an ASCII hostname and no origin aliases, suffix matching, payload-selected origins or document.domain relaxation.

MessageEvent.source can represent different emitter types. This receiver expects only its stored child WindowProxy reference. Another frame at the same trusted origin is not the expected source.

MDN’s WindowProxy definition explains that navigation changes the Window wrapped by the proxy. Therefore reference equality does not establish that the original document is still loaded. Add a host-owned view association for stale-work routing, while keeping that association separate from document authentication.

Create an inert host ledger and a readiness protocol

Trusted host setup, rather than a received payload, defines the origin, child reference, workspace and active view. G-A below is a symbolic correlation label, not a generated secret or an authentication mechanism.

PROPOSED_UNRUN — no browser objects constructed
Host view:       G-A / workspace WS-A / active
Expected child:  W-REF-A / configured origin O-W
Allowed input:   draft.propose / version 1
Allowed fields:  version, kind, view_ref, text
Text ceiling:    2,000 JavaScript UTF-16 code units
Result:          untrusted draft preview only

The HTML Standard’s Window messaging section advises waiting for a new child to announce readiness before sending messages. For this proposed protocol, the child first installs its receiver and announces readiness. The host checks origin and source, sends a minimal initialization for G-A, and requires a matching acknowledgement before enabling proposals. The child independently checks its configured parent origin and expected parent reference. Initialization contains no prompts, tokens, private documents or customer records.

Readiness only coordinates cooperating implementations. It does not prove a code release, authenticate a particular document or make the widget’s content trustworthy. Missing readiness, acknowledgement or required association leaves the view disabled.

Invalidate the view before replacement

On a host-controlled workspace switch, close or widget replacement, first mark G-A inactive and clear its pending proposal. Then detach its receiver registration and discard its stored child association. Create a fresh child context and new view association for WS-B; do not simply relabel W-REF-A as the new workspace. Every receiver invocation must consult the current active ledger, including a handler retained accidentally by old interface code.

For a host-controlled navigation, invalidate before initiating it. For an observed unexpected child reload or navigation, disable association and require a new explicit setup; a load indication alone is not readiness. This does not establish immediate detection of arbitrary child navigation. A proposal queued by an earlier document may still present the expected origin, reference and G-A before the host learns anything changed. Keep that residual uncertainty visible: this protocol does not prove the document is current.

A compromised document at O-W can also learn and echo the correlation label. The narrow consequence is a bounded untrusted preview, with visible workspace identity and separate user review. Applications requiring authenticated document identity or confidential messaging need a separately supported design; this worksheet supplies neither.

Review eight proposal-admission cards

The positive row assumes the declared setup completed; it is not an observed browser result. The receiver rejects extra fields, other versions, non-string text and unsupported message kinds before displaying anything.

Constrain outbound messages and describe their limits

The HTML algorithm serializes the message and queues delivery. Its delivery step compares the target document’s origin with the specified targetOrigin. Configure that origin explicitly from trusted setup; do not infer it from an inbound message’s destination field. A URL path is not a document-identity restriction: the algorithm derives an origin. A matching origin also does not prove the recipient is the intended document at that origin.

This profile excludes opaque-origin embeddings and fails compatibility instead of using “*”. It sends no confidential data. A successful postMessage call is not an acknowledgement that the application accepted a proposal; retain an explicit protocol disposition without treating silence as success. Rendering accepted text remains subject to the separate text-safe display policy. Any later save or external operation must independently authenticate the user and authorize the exact current object.

Keep the evidence claim narrow

A future application review would inspect setup, view replacement, retained listeners and queued-message cases against its actual browser build. Nothing here constructs an iframe, sends a message, runs a receiver or tests a navigation race. No browser, session, account, API or model experiment occurred.

Boundary is a prelaunch model request router and does not ship this widget receiver. Its synthetic action exercise and mock policy evidence are separate from these proposed browser checks.