Hypothetical question regarding overcoming the cross-realm identity barrier

Natively implemented platform APIs exhibit a set of behaviors which are presently unachievable in ES: they have object-associated private state which can be recognized and retrieved by multiple instances of the same API.

Date_fromRealmB.prototype.valueOf.call(new Date_fromRealmA);
// Does not throw; all Date.prototype.valueOf functions work with objects created by all Date functions

Both the private field proposal and hand-wired WeakMaps allow implementing ‘slots’ in ES. These are effectively equivalent to the slot concept used in the specification of internals. Strictly speaking, the cross-realm limitation that emerges with private fields and WeakMap is not a limitation of either, but rather a consequence of the fact that a module source text is associated with no persistent, common state that is reachable from ES code. Each time a module source text is evaluated, any ‘slot names’, regardless of how they are achieved, are uniquely created.

The agent has a means of determining if two specifiers resolve to the same module instance within a single realm, so there is already a concept of source text identity more sophisticated than ‘a particular sequence of bytes’. Hypothetically, an agent could share state between ‘instances of that module’ regardless of what realm they are evaluated in. The import.meta API could provide a hook for provisioning access to it. But what could be added there that would enable ES code to exhibit native cross-realm branding behavior?

Naively we could imagine an extensible null-prototype object, say import.meta.ohNo, reused for all module instances, acting as an open-ended bucket. Although this would work, it would never be acceptable since it would represent a side channel. If any approach were acceptable, it would need to be realized with a much narrower API.

I think such a narrow API might be possible, but it would depend on the existence of reified private names of some kind. Assuming these took the form of private symbols, we can imagine import.meta.privateSymbolFor, a function that behaves like Symbol.for. The difference would only need to be the scope of the registry: ‘all instances of this module’ rather than ‘all realms’.

This could also probably be realized as e.g. Symbol.for(import.meta, 'str'). The particulars of the API don’t matter.

I’m not really looking for feedback on this as a proposal (it’s not one). I doubt enough interest exists and there’s no such thing as a private symbol or equivalent presently — previous proposals for them have been rejected. My question is just: would such an API be sound, or would it still represent a side channel?

I think it would still amount to a side channel: if A and B are not intended to be able to pass data between them (and this is enforced by a membrane), they could get around this by both importing the same module, acquiring the same private symbol from it, and installing it on an object which they pass through the membrane. Since the symbol is private, the membrane would not be able to properly sanitize it.

(This problem is avoided currently because A and B get different copies of the class which holds the private state, and one can't pass its copy of the class to the other without the class itself going through the membrane.)

Mark Miller would be the right person to answer this more confidently, but I'm not sure if he's on the discourse yet.

Thanks. I hadn’t considered the case of the module in question exporting/otherwise exposing a private name value from its module-scoped registry to other modules. Assuming there’s no way this could be prevented, I think you’re right.