Browser API Integrity Across Realms

BotBrowser can repeat an authorized Window, Worker, and iframe API journey in a declared controlled context and compare visible outcomes. It cannot make realm APIs identical, grant cross-origin access, or certify production privacy; the application remains responsible for ownership, origin policy, accessibility, and data minimization.

API ownership is realm-scoped

WHATWG describes a realm as an execution environment with its own global object and intrinsics. The top-level Window, a dedicated Worker, and an iframe document therefore own separate API objects. A value such as Array or fetch must be interpreted in the realm that exposes it, not as a universal browser object.

MDN's JavaScript execution model also separates execution contexts, jobs, and agents. A Worker has no document DOM, while an iframe has its own document and policy context. A supported operation in one realm can be unavailable or intentionally restricted in another. The useful product contract is to name the owner, required capability, and fallback.

Messages preserve explicit boundaries

Window and iframe code can use postMessage, and a Worker can exchange messages with its owner. Structured clone creates receiver-owned values; it does not preserve the sender's object identity. Transferables such as ArrayBuffer move ownership and leave the sender unable to use the original resource.

For every message, define a version, operation, bounded data record, and expected response. Validate event.origin and the schema before using data. An origin check identifies a web origin; it is not business authorization. After an iframe navigation, re-check the origin and protocol before accepting a reply.

Reflection has a bounded meaning

Reflection can answer a narrow question such as whether an API property is exposed or whether a value has a callable shape in this realm. It cannot prove that an implementation is complete, that another realm behaves the same way, or that a browser, device, or person has a particular identity. Constructors, property names, and exception text can vary by release and policy.

Use reflection only for the operation the application needs, then exercise the supported path with synthetic input. A property being present is not proof that permissions, user activation, network access, rendering, or accessibility will succeed. Record the declared browser context and visible result, not an unnecessary inventory of the global object.

Accessible and privacy-safe fallback

When a Worker or iframe capability is unavailable, expose a readable status, preserve keyboard focus, and offer a safe local or server-rendered alternative. A timeout or rejected message should have a visible recovery action and bounded retry behavior. Accessibility belongs to the application contract, not to a browser classification.

Send the smallest record needed for the operation. Avoid copying page state, account records, tokens, or diagnostic inventories across realms. Delete synthetic diagnostics after review and document retention. A realm label or reflection result must not become a hidden analytics dimension or persistent identifier.

API integrity checklist

• Name the owning realm: Window, Worker, or iframe document.
• State the required API operation and its supported fallback.
• Define a versioned message schema, origin check, timeout, and cleanup owner.
• Treat cloned values as receiver-owned and transferred resources as moved.
• Test with synthetic data, visible recovery, keyboard access, and minimal retention.
• Record the declared context and outcome without inferring identity or universal parity.

BotBrowser capability and limitation

BotBrowser controlled contexts can repeat this authorized API journey with a declared profile and compare visible results across isolated contexts. They cannot make Window, Worker, and iframe APIs identical, grant cross-origin access, authenticate messages, or turn reflection into proof of privacy, anonymity, device identity, or production security.

A practical review record. For a release review, record the page origin, owner realm, API operation, protocol version, expected visible state, fallback state, and cleanup result. Keep the request synthetic and small enough to understand from the report. Note whether the iframe stayed on the expected origin and whether the Worker ended after success, timeout, or cancellation. These fields help a team reproduce an application issue without retaining account data or a complete global-object inventory. The record should distinguish an exposed property from a completed operation: a callable method may still reject because permission is missing, user activation expired, the frame policy disallows it, or the host cannot provide the resource. Treat each outcome as a product branch with an accessible message, and name untested branches instead of turning one successful call into a universal guarantee. When a result changes, compare one declared variable at a time: application bundle, frame origin, policy header, browser release, or profile. Avoid broad collection while investigating. A short, synthetic fixture and a visible fallback usually provide enough evidence to adjust the application contract or document a supported limitation.

Realm ownership is also useful when an application has several teams. The page team can own the Window contract, a compute team can own the Worker message schema, and an embed team can own the iframe origin and permissions policy. Each owner can publish the fields it accepts and the visible states it returns. This makes a change review concrete: a renamed operation, a new transfer, or a changed frame origin becomes a contract change rather than an unexplained browser difference. The page should own worker startup and shutdown; the worker should return a bounded status rather than echoing the request; and the frame owner should approve origin and policy changes before production. Explicit accepted, rejected, cancelled, expired, complete, unavailable, and failed states let the page render useful status without exposing stack traces, host paths, or user content.

The same discipline applies to failure handling. A Worker may stop because its script failed, the page closed it, or the host suspended work. An iframe may remain loaded while its document changes origin. The page should report a bounded status, stop pending work, and release resources in every branch. A timeout is an application event with a recovery choice, not evidence that a browser is untrustworthy. If a user leaves a page, cancel pending work, clear queues, release transferred resources, and ignore late responses. A WindowProxy can remain usable while an iframe document changes, so check current origin and protocol after navigation. Workers can be delayed or fail while loading, so bounded retries must not duplicate a side effect.

For user-facing features, test the successful path and at least one expected limitation in every supported realm. Check that status text is announced, focus remains usable, and a keyboard-only user can choose the fallback. Do not hide a missing capability behind a silent retry loop. A clear explanation and a safe alternative often preserve more trust than an attempt to make every environment look equivalent. Accessibility review should cover timeouts, stale announcements, focus, keyboard order, reduced motion, and the supported alternative.

Reflection should remain deliberately narrow in production code. Checking one method before invoking it can prevent an avoidable error; enumerating every global property creates a larger privacy and maintenance surface. If diagnostics are needed, use a fixed allowlist of application-relevant fields, keep values synthetic, and remove the record after the support decision. Constructor names and prototypes can differ after cloning, so prefer schema validation and operation tests. The goal is a reliable user journey, not a catalogue of implementation details. When data crosses a boundary, consider its lifetime on both sides. A cloned object may remain in a queue after the original page has moved on. A transferred buffer may be held by a worker until cancellation. Define who clears queues, terminates workers, closes ports, and removes temporary frame state. Support records should use synthetic fixtures, redact URLs and free-form text, and define deletion. These ownership decisions belong in the application documentation and should be visible in the release checklist.

The browser platform intentionally leaves room for implementation variation. Scheduling, exception wording, feature policy, and permission state can differ while an application remains conformant. A standards reference helps explain the expected model, but a product decision still needs a declared browser release, host, route, and fallback. Keep those variables in the review record so a later reader can reproduce the same question without guessing. A small release fixture can cover success, schema rejection, unexpected origin, timeout, and unavailable capability. Finally, separate compatibility evidence from privacy claims. A successful message exchange demonstrates that one declared route worked. It does not show what a remote service stored, whether a user can be identified, or whether every browser exposes the same surface. State the observed result, the untested branches, and the retention decision separately. This vocabulary keeps API integrity useful for engineering while respecting users and other origins. A useful review also explains how the page behaves when a capability is missing. If a feature needs a Worker for a calculation, the page can perform a smaller calculation locally or ask the server for a safe result. If it needs an iframe for a consent step, the page can show a readable explanation and a documented route to continue. The alternative should not silently widen permissions or send the same data through a different channel. Keep the fallback within the same privacy and accessibility expectations as the primary path. Teams often discover ownership problems when a feature moves into a component library, so state which component creates a Worker or iframe, which messages it accepts, and who cleans up when it is removed. Permission and policy layers are part of the contract: a method may be exposed but unavailable because the page is not secure, the user has not activated a control, the frame lacks a delegated policy, or access was denied. These are different product states and should not collapse into a generic unsupported label. A structured-clone boundary is a data boundary, not a security boundary; review fields, size, lifetime, and retention on both sides. Transferables add an ownership transition, so document who can close, release, or recreate the resource. The best evidence is an observable outcome such as a completion status or accessible fallback, not an inventory of every API property. Support needs only the smallest record that separates branches: browser release, declared profile, frame origin, policy headers, protocol version, synthetic request, public status, and cleanup result. Mark untested branches explicitly and avoid turning incomplete observations into claims about a browser, device, or person. A clear record gives product owners a concrete choice: expand support, keep the fallback, or remove an unnecessary dependency. Keep a short change log for the protocol version, origin, permission policy, and fallback copy. Review it after a browser update and after an embedded service changes its document or headers. When the result differs, reproduce the same synthetic request in a fresh controlled context before changing the application. Compare the visible branch and cleanup result, not a broad list of properties. This keeps a compatibility decision proportional to the feature and makes it easier to explain to customers. It also gives accessibility and privacy reviewers a stable artifact: they can see what data crossed the boundary, which user action was required, what happened on cancellation, and when temporary values were deleted. A stable artifact supports maintenance without becoming a record of a person’s browser characteristics. Include a rollback note for each release: identify the last accepted protocol version, the prior fallback copy, and the owner who can restore it. Rollback should remove the changed dependency, not weaken origin checks or expose additional data. After rollback, rerun the visible success and failure branches and record which one changed. This keeps incident response focused on restoring a predictable experience rather than trying to make unrelated realms appear identical. A customer-facing explanation can then remain simple: the feature is supported in the declared context, a documented alternative is available when it is not, and no reflection result is used as an identity claim.

This approach also helps teams that maintain several delivery surfaces. A desktop page, an embedded checkout, and a worker-backed editor can share one public contract while keeping realm-specific owners separate. State which fields are stable, which may be added, and which must never be echoed. Document cancellation, navigation recovery, and deletion of support records. These details turn an abstract boundary into dependable product behavior, reduce accidental coupling between a frame and its parent, and give privacy reviewers a concrete place to ask whether each field is necessary. The result is not identical behavior everywhere; it is an honest, accessible, and maintainable experience in each declared context. It also gives customer support a clear sentence to use: the feature is supported in the declared context, a documented alternative is available when it is not, and reflection is not used to identify a browser or person. When an environment changes, support can ask for the declared context and visible branch instead of requesting broad diagnostics. Engineering can then reproduce the same synthetic route, compare one variable, and decide whether the application contract or its fallback needs an update. This keeps troubleshooting bounded and makes the privacy promise understandable to the people using the feature. For long-lived products, keep the contract review near the release notes. Note the browser range, the frame origin, the Worker bundle version, and the fallback text that users will see. When one of these changes, rerun the small fixture and confirm that cancellation still clears pending work. A stable review habit catches accidental API widening early and gives each owner a chance to confirm that the data crossing a realm is still necessary. It also makes later maintenance less dependent on assumptions about a particular browser release or host image. Keep the public explanation equally precise. Say what was tested, where it was tested, and what the user can do when the operation is unavailable. Do not imply that a local API check speaks for a remote origin or every browser. That clarity is the practical meaning of API integrity.

It also keeps future changes reviewable. A new message field, frame origin, or permission requirement has a named owner and an observable fallback. Teams can approve that change, test the declared route, and remove temporary evidence when the review ends. The same record tells support which public branch a customer saw and tells engineering which contract to inspect, without asking for a broad browser inventory.

The review can therefore remain useful long after the original release: owners, visible states, cleanup, and retention stay explicit, while realm differences remain ordinary compatibility information rather than hidden identity data. This keeps the explanation concise for customers and actionable for maintainers. Keep examples synthetic and never include secrets.

The release owner should review API ownership before every public change.

Sources

Related reading: cross-realm browser consistency and cross-surface browser privacy.

• WHATWG HTML: Realms
• WHATWG HTML: Web messaging
• MDN: JavaScript execution model
• BotBrowser advanced features