concern about multiple set of intrinsics synchronously accesible

[caridy]

@domenic raised this concern during a conversation today. From what I gathered:

1. one issue will be that some web semantics that were designed to rely on a ref's associated realm to carry on certain operation. The example used was Function.prototype.bind, which creates a new function from another realm, that in conjunction with APIs like postMessage, could cause issues.

TBH, I still don't fully understand the problem, mostly because the flip side of this is what the associated realm is used for when post messaging? and whether or not the "forwarding" mechanism that @littledan has been working on helps with this? considering that the window and the newly created realm acted as a group "sharing" the settings.

2. another issue that he mentioned here is the potential hazard of having multiple Object.prototype, Function.prototype, etc.

We have thought about this issue a lot, it is what we call "identity discontinuity hazard", and it is a real hazard for developers, but we have learned to deal with it. In nodejs, this problem is very common. In the web, same domain iframes exhibit the same issue as well. It is something that can be solved with a "near membrane". But I do acknowledge that adding yet one more way to have this issue in the web is concerning.

@domenic also suggested some other areas of explorations here, if the main goal is to have a new set of mutable intrinsics. Something more aligned with a powerful evaluator that can give you the controls to resolve what reference to use during evaluation of code or modules. This sounds a lot like the parameterized evaluator that we have discussed extensibly, and somehow has mutated into the container's proposal. I am up for experimenting in this area.

[littledan]

Thanks for raising these concerns, @caridy and @domenic .

1. It sounds like we're talking about how the backup incumbent Realm would be determined in conjunction with the Realms API. The HTML spec cares about the incumbent settings object, but it doesn't seem to use the incumbent Realm for much--it seems like it'd be fine to consider that to be the Realm of the enclosing window, worker, etc. So I believe the "forwarding" logic that's been generally articulated would work here, though there's clearly some editorial work to do.

2. This problem has been well understood and analyzed by the champions. It does not seem to be a web-specific issue, but rather a general JS issue. Overall, I like how the current Realms proposal leaves parameterized evaluators for a future proposal (e.g., compartments). I'd like to start with something minimal and scoped, though. I'm glad that our positive experience in Node.js with this minimal solution can give us extra confidence with going this way in the language.

[domenic]

My suggestion is to explore a way of addressing the use cases that does not involve creating new realms, but instead allows new copies of the intrinsics to be created within the same realm. (And then, introduce some modified version of eval(), or perhaps use eval() + with, to evaluate code in the context of those new intrinsics.)

The extensive problems with this proposal all stem from trying to introduce new realms, which has knock-on effects across the ecosystem due to realms being extremely tightly integrated with hosts. (They were the very first host integration point in ECMAScript history.) If you can instead address the use cases entirely inside the ECMAScript machinery, without crossing over into host machinery like realms, that would avoid a huge class of problems.

[littledan]

I don't understand what it would mean to allocate a new copy of intrinsics in the same Realm. Would they point to each other, or to the original one?

[domenic]

That'd be up to TC39 to define. The main point is that their [[Realm]] would be the same as the existing ones.

[littledan]

Overall, does this mean that the observable semantics within in JS would be the same, just that hosts would be unable to see what is the "current" intrinsics set? Aside from that, I'm having trouble understanding what the difference in semantics is.

[domenic]

I mean, anything keyed off of [[Realm]] would be observably different.

[littledan]

From what I can see, uses of [[Realm]] in the JS spec that are observable from pure JS lead to the right intrinsics being chosen. So, if there's a form of eval which runs using a particular intrinsics set, then it seems like that intrinsics set would have to be propagated to everywhere the Realm is propagated, if we want the new intrinsics set to actually consistently be used.

• Most explicit mentions of Realms in the JS spec are to propagate it.
• There are lots of references to intrinsics, which implicitly reference the current Realm. If we're adding a form of eval which works with respect to a set of intrinsics, maybe there's a parallel mechanism to keep track of which intrinsics set we're working in, which is implicitly referenced when referring to an intrinsic (???)
• Some operations use Realms in a way that seems like it would be replaced by the intrinsics set concept
  • GetPrototypeFromConstructor indirects through the Realm's intrinsics table, but presumably we'd return the original prototype of that particular constructor from the same intrinsics set
  • ArraySpeciesCreate checks whether C is some other Realm's Array constructor; presumably, this would be generalized to any intrinsic Array constructor
• Promise reaction jobs tell the host what the entry Realm is (nothing visible on the pure-JS side)
• The Realm is used to get to the global object
  • Indirect eval gets the global object from the Realm of the eval function
  • Sloppy mode functions called with undefined as the receiver use the global object as the this value, which is retrieved from the Realm of the function.
  • A mismatch between the intrinsics set and the global object seems pretty unfortunate, since the global object is a path to reach the intrinsics. I'm not sure whether you meant for this to actually be included.
• (Am I missing anything?)

Overall, I'm having trouble understanding what the observable effects would be of the change you're proposing.

[domenic]

Overall, I'm having trouble understanding what the observable effects would be of the change you're proposing.

It would affect all web platform specs and APIs which key off of realms. This includes both directly script-observable ones, some (but probably not all) of which are mentioned in whatwg/html#5339 (comment), and also specification machinery such as the hierarchy of user agent -> agent clusters -> agents -> realms and how realms are always assumed to either be windows, workers, and worklets.

It would also ensure realm-scoped things like base URLs / module maps / cross-origin isolated and other security states / origins are not mucked with by the new thing, since the new thing is only a set of intrinsics, and is not a full realm which brings along all of those.

[leobalter]

I believe this issue has now the same challenge I pointed out at #261.

The new Callable Boundary API would not provide access to the different set of intrinsics, as long a separate module graph is preserved.

[caridy]

No, I believe this can now be closed. There is no more access to a new set of intrinsics.