undeniable global communication channel

[michaelficarra]

From the README:

All of the import statements in the module graph that address the same module will evaluate to the same mutable Uint8Array object.

Doesn't this introduce an undeniable global communication channel? Is there a way to virtualise or deny this interface?

/cc @erights @kriskowal @mhofman

[bakkot]

No more than json modules being mutable, I should think?

I guess for JSON it's deniable for a particular module because you can freeze it after importing, which you can't do for a Uint8Aray, but in neither case can you deny it without being able to load the module first.

[erights]

Not if Immutable ArrayBuffers go first. Then the result could either be a frozen Immutable ArrayBuffer or a frozen Uint8Array on an Immutable ArrayBuffer

[erights]

Which I would advocate. No reason to introduce another global comm channel that will give security efforts hell to work around.

[nicolo-ribaudo]

This is not more of a global communication channel than export default {} is. Either modules are not considered to be a global communication channel (because there are proposals / host hooks that allow virtualizing module loading), and thus this proposal is also not one; or modules are already a global communication channel, and this proposal does not change it in any way.

This proposal is not adding any new capability, it's just restricting how hosts can interpret a specific import attribute.

[lucacasonato]

I agree with @bakkot and @nicolo-ribaudo that this is not a new type of global communication channel - we already have identical types of channels with json imports, or even just regular JS imports as Nicolò writes.

I do think that we should return immutable ArrayBuffers because this enables memory savings in some implementations: #5.

[styfle]

I'll change this proposal to use immutable arraybuffer 👍