Jamesernator
commented
3 years ago My thoughts are that this is a bit weak by itself due to the lack of cross-realm references. However it does make me wonder if something like a sync version of what Puppeteer/Playwright do with JSHandles + ability to structure clone a handle would work.
e.g. For example:
const realm = new Realm();
const arrayHandle = realm.evaluateHandle(`[1,2,3]`);
// Push an item into the array in the realm, non-handles are structured cloned
realm.evaluate(`array.push(value)`, { array: arrayHandle, value: 4 });
// We can also ask for a handle to be structured cloned back to us
const arrayClone = arrayHandle.cloneIntoThisRealm();
console.log(arrayClone); // [1,2,3,4]For things like callback patterns, the ability to have handles works naturally, for example suppose we wanted to expose something like setTimeout in the realm:
const realm = new Realm();
const realmSetTimeout = realm.createFunction(
function setTimeout(delayHandle, callbackHandle, ...callbackArgumentHandles) {
const delay = delayHandle.cloneIntoThisRealm();
setTimeout(delay, () => {
realm.evaluate(`callback(...args)`, {
callback: callbackHandle,
args: callbackArgumentHandles,
});
});
}
);
realm.globalThisHandle.setPropertyDescriptor('setTimeout', {
value: realmSetTimeout,
enumerable: true,
configurable: true,
writable: true,
});A rough API would be something like this:
type StructuredClonable = ...;
class RealmHandle {
// Clone the value from the realm into this Realm using structured clone
cloneIntoThisRealm(): StructuredClonable;
// Object meta operations, same as Reflect.* except
// accept RealmHandles and return RealmHandles
apply(
target: RealmHandle,
thisArgument: RealmHandle | StructuredClonable,
argumentsList: RealmHandle | Array<RealmHandle | StructuredClonable> | StructuredClonable>;
): RealmHandle;
construct(...) ...
...
}
class Realm {
// A RealmHandle for the global object
get globalThisHandle(): RealmHandle;
// Evaluate and clone the return value, this is basically a shortcut for
// .evaluateHandle().cloneIntoThisRealm();
evaluate(
code: string,
scope: Record<string, RealmHandle | StructuredClonable>,
): StructuredClonable;
evaluateHandle(
code: string,
scope: Record<string, RealmHandle | StructuredClonable>,
): RealmHandle;
// Creates a function in the Realm that calls the given function with RealmHandles
// for all arguments passed to it
createFunction(
func: (...args: any[]) => StructuredClonable,
scope: Record<string, RealmHandle | StructuredClonable>,
): RealmHandle;
}
leobalter
Jack-Works
caridy
domenic
jridgewell
erights
ByteEater-pl
littledan
annevk
ljharb
koto
Hi realms champions,
@syg and I have been considering a modification to the current realms proposal which trades some expressivity, to give better isolation guarantees. Essentially, instead of allowing direct bidirectional access between the parent realm and the constructed realm, all such communication would go through structured cloning. This ensures that the child realm never gets access to objects from the parent realm, thus making "sandbox escapes" such as those in #277 or https://github.com/nodejs/node/issues/15673 impossible by construction.
Sample code and API
We don't have strong feelings on the API for this; we'd like it to be as ergonomic as possible. But here is an initial idea.
For pulling values out of the constructed realm, into the parent realm: introduce
realm.eval().For getting values into the constructed realm, from the parent realm, a bare minimum might look like this:
but you could imagine something slightly more complicated, and more useful, such as
(Compared to async realm boundaries on the web, this solves similar use cases to
webRealm.postMessage().)Finally, for pushing values out of the constructed realm into the parent realm, you'd need something like this:
(Compared to async realm boundaries on the web, this solves similar use cases to
webRealm.onmessage.)And, of course, we'd remove
realm.globalThis.Use case analysis
This proposal is arguably better than the current one for many sandboxing use cases. In particular, for cases such as templating or computation where the goal is to have a (conceptually) pure function execute inside the realm, this architecture is ideal, especially in how it automatically prevents "impurities" from cross-realm contamination. In such cases, the values passed are often primitives, or if not, they're within the realm of structured clone: plain objects, arrays, maybe some Maps and Sets and Errors and Dates and typed arrays/ArrayBuffers.
For cases such as a virtualized environment, it requires more work, but probably on about the same level membrane-based approaches. That is, to perform operations inside the realm while interfacing with a same-realm object API, you would have to create proxies (either literal
Proxys or just wrappers) which perform the appropriate calls torealm.eval()andrealm.call(). And similarly for the reverse: if code inside the realm wants to operate on a inside-realm object while really doing work in the outside realm, the outside realm would need to do some setup, usingrealm.eval()to inject some proxies which callglobalThis.callParent(). (Probably that setup code would then also dorealm.eval("delete globalThis.callParent")at the end.) This is equivalent to what is being done today in the AMP WorkerDOM example that the explainer cites, but by using synchronousrealm.call()etc. instead of asynchronousworker.postMessage(), it would overcome the challenges you discuss there.Other use cases like running tests in the realm fall in between. You'd need to inject a small shim into the realm which provides globals that the test library depends on (such as
console), proxied to the creator realm. But then you'd just run the test library inside the global. I.e. instead of the explainer's current sample code, you'd writeThis also gives you a stronger guarantee that tests don't mess with the test framework, or with the outer realm, or with other tests, all of which are possible in the current explainer's sample code.
This proposal does lose some expressivity though. In particular, it is not able to create reference cycles between cross-realm objects. Because all communication is via cloned messages, there's no way to communicate to the garbage collector that an object in the outer realm depends on an object in the inner realm, and vice versa, so that the cycle can take part in liveness detection. To some extent this is a good thing, as cycles are an easy way to leak an entire realm. But from what I understand it does cut off some use cases that go beyond the ones mentioned in the current realms explainer.
Performance
Adding a structured clone step for all boundary-crossing operations could come at a performance cost. But, less so than you'd imagine.
In particular, since primitives are trivially cloneable, any operation which returns them would suffer virtually no overhead vs. the current realms proposal, when communicating across the boundaries. This can account for a large number of use cases: e.g., most computation use cases, or the test framework use case (where it's just passing console.log strings across), or many of the interesting virtualization cases. Other cases will be covered by small objects or arrays, for which the structured clone overhead is quite small (less than JSON serialization and parsing). It's only the case of needing to return a large, nested object graph where there might be a noticeable performance disadvantage.
It's also worth noting that although this proposal does have a lower theoretical performance ceiling than the current realms proposal, it's probably comparable to the current realms proposal plus the associated membrane machinery that's needed to preserve encapsulation. There might be interesting tradeoffs in the large nested object graph case. There, structured cloning across the boundary means a larger up-front cost, but after that initial cost is paid, subsequent accesses throughout the large object graph are fast and well-optimized. Whereas membrane use means every access throughout the wrapped object graph incurs membrane-related overhead.
Finally, I haven't thought much about this, but you could probably get ultimate performance™ by passing in a SharedArrayBuffer and doing all communication through that.
Conclusion
I'm optimistic that this proposal removes the most dangerous feature of realms, which is that they advertise themselves as an encapsulation mechanism, but it is extremely easy to shoot oneself in the foot and break encapsulation. This encapsulated-by-default proposal would bring realms onto the same footing as other encapsulation proposals such as trusted types or private fields, and thus make it more congruent with web platform goals.
There still remains a danger with people over-using realms when they need security or performance isolation, beyond just encapsulation. This still weighs heavily on me, and its conflict with the direction the web is going (per #238) makes me still prefer not providing a realms API at all, in order to avoid such abuse. But I recognize there are cases where synchronous access to another computation environment is valuable, and I think if we curtailed the footgun-by-default nature of realms by prohibiting direct cross-realm object access, I could make peace with the proposal.
I look forward to hearing your thoughts, and hope we can meet on this "middle ground" between no realms on the web, and the current proposal.