Limit a worker buffer transfer to approved backing bytes

Ask which resource the worker would actually receive

A fictional preprocessing view needs two already approved bytes for a trusted local worker W-A. The producer represents them with a small typed-array view. A review that records only “two-byte input accepted” can miss a different question: how much backing storage is the proposed handoff making reachable?

This guide selects one dedicated worker, job J-A, and an ordinary fixed-length ArrayBuffer with a plain Uint8Array view. Shared, resizable and growable storage, custom accessors, subclasses, arbitrary worker setup and pooled storage are excluded. This is a proposed admission profile, not an allocation or copying implementation.

All eight cards are PROPOSED_UNRUN. No buffer, view, transfer list, worker, message graph or binary payload has been constructed for them. Symbols identify invented resources rather than inspected browser objects.

Separate the visible view from its backing object

MDN’s TypedArray.buffer reference says the property returns the backing ArrayBuffer or SharedArrayBuffer referenced at construction. The backing buffer may be longer than the view; its sliced-view example explicitly shows different view and backing byte lengths.

Invent B-X with eight backing bytes, and V-X with byte offset two and visible length two. Only the two bytes in V-X are approved for J-A; the other six are outside the task. These are numeric labels, not allocated memory or actual content. Do not reinterpret a view-length field as authorization for those six bytes.

The property is read-only as a property. That does not establish that the underlying contents are immutable. This profile selects ordinary ArrayBuffer storage and makes no assumptions about other backing kinds merely because the same accessor can return them.

Review the transferred resource and the message together

The transferable-objects guide distinguishes serializable typed arrays from their transferable backing buffers. Transferring an ArrayBuffer moves its associated memory resource to the other context and detaches the sender’s original buffer. A transfer list specifies handling; it is not itself the data delivered. A listed resource absent from the sent data can be detached without becoming available to the receiver.

Combined with the backing-property contract, transferring B-X with V-X does not confine the worker to V-X’s two-byte range: the received view provides access to its complete backing buffer. This is an inference from the documented object relationship, not an observed browser result. Reject that proposed handoff when all eight bytes are not authorized.

Review both associations: which backing resource is selected for transfer, and how the intended message makes that resource available. Neither a familiar buffer label nor an unrelated two-byte field establishes the relationship.

Make the useful positive a complete resource decision

For the small conditional positive, B-A contains exactly two approved bytes and V-A spans its entire range: byte offset zero, visible byte length two, backing byte length two. The intended message data is that plain view; the selected transferable resource is its same backing B-A. No extra object graph, unrelated resource or credential belongs to this plan.

PROPOSED_UNRUN — byte-admission ledger only
Job: J-A | trusted dedicated worker: W-A
Backing resource: B-A | complete byte length: 2
View: V-A | byte offset: 0 | byte length: 2
Approved data scope: all B-A contents for this purpose
Message association: V-A references selected backing B-A
Disposition: conditional handoff eligibility, not processing

Actual full-content classification, object identity, exclusive producer ownership through admission, supported worker setup and present job rights are unimplemented prerequisites. Unknown evidence holds the plan. This worksheet deliberately supplies no procedure for copying a subview into a new buffer, verifying a codec or repairing an unexpected backing object.

Walk eight inert handoff cards

Separate queued work from an accepted result

Worker.postMessage documentation identifies the first argument as message data and describes adding a task to the receiving event loop. Its return value is undefined. The transfer argument changes resource ownership; it does not authenticate the selected worker or constitute an application result.

Keep admission, attempted handoff, supported receive disposition and validated processing result as separate evidence. A future receiver protocol would need its own reviewed implementation and bounded output contract. None is supplied here, and silence is not successful completion. Do not blindly replay a detached-input plan when outcome or ownership is unresolved.

Any later model request or publication requires separate data-route and current-rights decisions. A worker being local to the browser is not permission to disclose unrelated bytes to it or to forward its output elsewhere.

Keep ownership smaller than isolation or erasure

This boundary differs from sealing a Linux input object: the selected transfer does not establish frozen contents. It also differs from the text-only widget receiver, whose profile excludes transferred resources. No existing frame policy or process-inheritance allowlist is broadened here.

The three maintained MDN pages were read on 30 October 2026, with displayed modification dates 18 September 2025, 13 April 2026 and 10 July 2025. They establish no tested browser build or actual worker support. No candidate browser, transfer, detachment, copying, codec, parser, runtime fixture, API or model operation occurred.

Boundary is prelaunch and does not ship this worker admission service. Its synthetic policy evidence concerns different behavior. Full backing approval remains a useful data-minimization decision, not a sandbox, complete resource limit, physical-memory wiping guarantee or exactly-once processing mechanism.