Support passable immutable ArrayBuffer as copy-data

[kriskowal]

2024-10-18:

The plan of record for passable immutable binary data is an immutable ArrayBuffer per our proposal to TC39.

---

2022-10-18:

Our current best solution for carrying bytes is a Uint8Array, which we use pervasively for hardened streams. This is one of the reasons that we treat Typed Arrays like Map for the purposes of hardening. The content is mutable but the API surface is tamper-proof. However, the content is readable and writable by both the sender and receiver over time, so like a Map, TypedArrays are not passable. That makes them a poor foundation for remote streams in an ocap discipline.

I propose that we need an analogous solution to the CopyMap and MapStore for transmission of immutable byte strings, tentatively CopyBytes and BytesStore, which would be passable and provide a firmer foundation for streams (async iterators of byte strings). CopyBytes should mesh well with TypedArrays, particularly Uint8Array and ArrayBuffer. To that end, it may be necessary for them to be Proxies, such that uint8Array.set(copyBytes) is sensible. Constructing an immutable copy of the content of an array-like should be possible, like copyBytes(uint8Array) or makeCopyBytes([0, 1, 2, …, 127]). CopyBytes would be backed by a TypedArray but would attenuate mutability. Slicing CopyBytes should be trivial. As with glyph strings, ropes are a possible optimization in the fullness of time.

As a critical optimization, we often use ring buffers for byte streams. We could conceivably also support another type for revocable copy bytes, that would permit a stream to reclaim the underlying byte range when the consumer signals it’s ready for another subrange.

[kriskowal]

attn @erights @gibson042 @mhofman

[mhofman]

I'm extremely concerned by the performance overhead of such a user-land abstraction. We should pursue a standard approach which allows engines to avoid array buffer copies, and minimal overhead on read access.

One such proposal at stage 1 is @Jack-Works's Limited ArrayBuffer

[kriskowal]

Shimming a standards track solution would be good.

Ah, memories. (My abandoned hobbies include a decade old fantasy of JavaScript having byte strings.)

[erights]

Attn @phoddie

[phoddie]

If you'd like an efficient read-only ArrayBuffer, that code is already in xst as part of our Secure ECMAScript / Hardened JavaScript work . This fragment...

const bytes = Uint8Array.of(1, 2, 3);
petrify(bytes.buffer);
bytes[2] = 1;

...throws TypeError: ?: read-only buffer.

Yes, a fully standard solution would be welcome.

[kriskowal]

A petrified buffer would certainly be eligible for passing over a CapTP.

Shimming petrify I think would require us to replace the TypedArray constructors and presenting all typed arrays as proxies, such that we could emulate petrification of a TypedArray with an ArrayBuffer shared by other TypedArrays.

[phoddie]

This may be what you mean, but... I wouldn't suggest shimming petrify as it is extremely broad & general. Instead, have a focused way to make an ArrayBuffer read-only. The implementation of that when running on XS will petrify instead of Proxy and such and so avoid oodles of runtime overhead.

[erights]

To shim making an ArrayBuffer itself read-only, we'd need a way to actually make an ArrayBuffer read-only in place. The only thing we know how to shim would be something that returns what seems to be a new read-only ArrayBuffer.

Same for a TypedArray.

[kriskowal]

Aye, I lay it out like this because oodles of runtime overhead might not be acceptable, even in an intermediate step toward a standard. But if petrify had standards ambitions, we could shim the intersection of petrify and TypedArrays, throwing for anything we can’t petrify. Or we could anticipate and shim a world where TypedArray can be frozen. Either of these strategies would require us to replace the TypedArray and ArrayBuffer constructors such that they return proxies and deny all programs thereafter direct access to TypedArray and ArrayBuffer instances, such that freezing one façade of an ArrayBuffer would freeze all the façades of the same ArrayBuffer.

The web platform’s solution to this problem is opaque Blob objects. If you want to see the contents, you have to copy them into a TypedArray. We could certainly harden and make blobs passable too without doing anything to TypedArrays.

[phoddie]

To shim making an ArrayBuffer itself read-only, we'd need a way to actually make an ArrayBuffer read-only in place. The only thing we know how to shim would be something that returns what seems to be a new read-only ArrayBuffer.

Y'all are the experts in patching things into a web-ish runtime. My goal is to avoid an ugly optimization problem around Proxy in XS when it already supports read-only buffers efficiently. If it is a problem that petrify does too much here, the functionality can easily be repackaged in a call that is focused on the needs of this particular problem.

Maybe side-stepping the problem with Blob is pragmatic, though there's more data copying. Perhaps implementing Blob with a petrified ArrayBuffer would allow Blob.prototype.arrayBuffer() to be almost free?

[erights]

replace the TypedArray and ArrayBuffer constructors

Doh! I'm embarrassed that I didn't think of this. Thanks!

Ok, I just read about Blobs at https://developer.mozilla.org/en-US/docs/Web/API/Blob . Aside from their non-JS stream() method, which we can omit from our whitelist, they seem like perfectly fine forms of CopyBytes. When we do add CopyBytes to our system, we could call it CopyBlob instead, and have passStyleOf certify that a Blob is a CopyBytes when it is hardened and has no surprising properties.

This would take the pressure off of needing to shim making an ArrayBuffer or TypedArray read-only in place.

[erights]

Maybe side-stepping the problem with Blob is pragmatic, though there's more data copying. Perhaps implementing Blob with a petrified ArrayBuffer would allow Blob.prototype.arrayBuffer() to be almost free?

I like that!

[kriskowal]

Maybe side-stepping the problem with Blob is pragmatic, though there's more data copying. Perhaps implementing Blob with a petrified ArrayBuffer would allow Blob.prototype.arrayBuffer() to be almost free?

I think the expectation of Blob.prototype.arrayBuffer() is that it would produce a mutable array buffer. It could be nearly-free if ArrayBuffers have a copy-on-write optimization.

[phoddie]

Yea, I had the same thought walking back from coffee just now. Alas.