Broadcast Channel API
The Broadcast Channel API lets same-origin browser contexts exchange named messages, making cross-tab coordination a governance surface for browser agents.
Definition
The Broadcast Channel API is a browser messaging primitive for same-origin coordination. MDN describes it as allowing basic communication between browsing contexts such as windows, tabs, frames, iframes, and workers on the same origin. The HTML Standard defines the BroadcastChannel interface in its web messaging chapter, with a constructor, name, postMessage(), close(), onmessage, and onmessageerror.
The origin boundary is not the whole story. MDN notes that communication is allowed between contexts using the same storage partition, because storage is partitioned by top-level site before origin is considered. For agent governance, this means a channel is not simply "all same-origin pages everywhere." It is a same-origin, partition-aware browser communication lane.
Mechanism
A script joins a channel by constructing new BroadcastChannel(name). Other same-origin, same-partition contexts that construct a channel with the same name can receive messages without holding references to each other. Calling postMessage(message) sends the value to other listening BroadcastChannel objects on that channel. MDN states that the sender does not receive its own broadcast through that same object.
Messages arrive as message events, while messageerror is used when a message cannot be deserialized. MDN documents InvalidStateError when postMessage() is called after a channel has been closed, and DataCloneError when the input is not serializable. Calling close() disconnects the object from the underlying channel and allows cleanup.
Agent Context
For AI Browsers and Computer Use, Broadcast Channel is a small but important coordination path. One visible tab can tell another tab that a user logged out, a draft changed, a background sync completed, or a local queue is ready. A worker can broadcast state that several windows consume. A browser agent can use the same mechanism to coordinate multi-tab tasks without a server round trip.
That convenience creates an invisible message bus. A user may approve an action in one tab while another same-origin context receives the update and continues the workflow. A malicious or compromised same-origin page can listen for channel traffic that was meant for cooperative code. A generated agent message can change local state in several contexts at once, even when the user is looking at only one surface.
Governance Use
Governance should treat Broadcast Channel as local inter-context signaling. A review record should preserve origin, top-level site or partition context where known, channel name, sender context, receiver class, event type, schema version, payload class, generated versus user-supplied fields, and whether the message triggered local storage, network, clipboard, file, payment, or identity actions.
Channel names and payloads should be designed as public-to-the-origin, not private-to-a-tab. They should not carry raw credentials, medical notes, private prompts, secret document titles, or unredacted user identifiers unless a clear same-origin data policy covers every context that can subscribe. For agents, the safer pattern is typed messages, low-sensitivity payloads, explicit task IDs, and audit records that explain why a broadcast was sent.
Limits
Broadcast Channel is not cross-origin messaging, a secure enclave, a permission prompt, a server coordination protocol, or a guarantee that every intended receiver is alive. It is also not a substitute for Web Locks API when the problem is mutual exclusion rather than notification. A message can announce that work happened; it does not prove that two contexts cannot race.
Because the API is simple, the social risk is usually in application design. If every tab treats a broadcast as command authority, then any eligible sender can become a local control plane. Agent runtimes should separate notification from authorization, validate message schemas, ignore unknown channel names, and make consequential cross-context actions visible in logs.
Review Record
- Channel: origin, top-level site, storage partition context, channel name, sender, receiver class, and creation time.
- Message: event type, schema version, payload class, size class, generated fields, user-supplied fields, and serialization errors.
- Agent role: workflow ID, model instruction, human approval state, visible tab, worker context, and follow-on action.
- Risk control: schema validation, sensitive-field redaction, authorization check, retention period, and incident link if misuse is suspected.
Source Discipline
Claims about the interface, postMessage(), close(), message, messageerror, eligibility, storage-key matching, and dispatch behavior should cite the HTML Standard. Claims about same-origin contexts, workers, storage partition notes, subscription by shared channel name, cleanup, exceptions, and browser-facing examples should cite MDN. Claims about agent coordination, hidden local buses, audit records, and misuse are governance inferences from the API's technical role.
Spiralist Reading
Spiralism reads the channel as a whisper corridor inside the browser. Nothing supernatural is happening: one context posts, other eligible contexts hear. But in agentic software, whispers can become decisions. The humane rule is to make local coordination legible when it changes state, authority, or responsibility.
Related Pages
- AI Browsers and Computer Use
- Web Locks API
- Storage Partitioning
- Storage Access API
- Cross-Origin Opener Policy
- Cross-Origin Embedder Policy
- AI Agent Observability
- AI Audit Trails
- Contextual Integrity
- The Operating System Becomes the AI Gatekeeper
Sources
- WHATWG, HTML Standard: Broadcasting to other browsing contexts.
- MDN Web Docs, Broadcast Channel API.
- MDN Web Docs, BroadcastChannel.
- MDN Web Docs, BroadcastChannel: postMessage() method.