the obvious shadowrealm proposal is just designed for trusted code?

[LongTengDao]

https://github.com/tc39/proposal-shadowrealm/blob/main/explainer.md#trusted-third-party-scripts

why? just used to prevent global/proto api collision? non-modular lib will die in the future, and old libs most likely not be able to directly run in the isolation environment without any rewritten.

does this proposal consider to prevent any side effect like import(), to make the shadowrealm as a good way (and only possible way, which even iframe can't do that, because net io could leak user input) to run third party unsafe plugins, which will force to be a pure function when run in the shadowrealm? (of cause we can never prevent cpu malicious block, but that's special, which can easily be found, and no one will use that plugin any more.)

except import(), is there still any other factor that may make shadowrealm not easy to "prevention over non-Trusted Third Party Scripts like malicious code or xss injections"? maybe I thought too less, didn't realize the difficulty to design a proposal matching needs above.

thank you!

[erights]

The phrasing of this statement in the explainer is driven more by politics than technical accuracy. As it says, Shadow Realms (as well as compartments) does protect integrity. As explained at https://agoric.com/blog/all/taxonomy-of-security-issues/ , neither shadow realms nor compartments are in a position to defend availability, since all parties share one thread of control. Unlike compartments, shadow realms by themselves are not in a position to defend confidentiality, since they provide no means to suppress the measurement of duration.

No code is "trusted" or "untrusted". All code is partially trusted, to different degrees and kinds. Better is to talk about the vulnerability we have to the possible misbehavior of code. Shadow realms are thus good for code that is "untrusted" on integrity but "trusted" on availability and confidentiality.

Put another way, Shadow Realms is great for protection against untrusted code, given clarity on what threats it does and does not protect against.

Attn @caridy @leobalter

[Jack-Works]

You may want to know https://github.com/tc39/proposal-compartments this proposal.

And even it cannot prevent a while (true); to block the whole thread.

[LongTengDao]

Thank you! @erights @Jack-Works

It seems that, shadowrealm has a different aim with compartments (which I don't know before, thank you).

After rethinking, I want to know, if it's possible to add a feature which belong to shadowrealm's aim, at stage 3:

• give an api to handle any inside net io behaviour (like import), like new ShadowRealm(function onImport (uri) {})?

Because if a lib is not designed well-modular (which shadowrealm designed for), it most likely not work well without dependency rehandling. And that would help for case that need to prevent any net io. (of cause while (true) ; will never be prevented, but that's special, as said above, that's almost no benefit and easy to find by even most careless user.)

[erights]

The groups working on Realms and Compartments largely overlap. After extensive discussion, the Realms work decided to delegate to the Compartment work, and the Compartment abstraction, all abilities to virtualize the import namespace. Compartments indeed provide an import-manipulating API that may serve your needs.

[LongTengDao]

Thank you! It seems that I need to wait for the stage 1 proposal...

The last question:

I saw the shadowrealm follows the csp of the page. Is it possible to make shadowrealm has it's own csp?

Because user may import third-party module in page, but want to only allow import same-origin even 'none' module in shadowrealm.

That could be an api on ShadowRealm, or in CSP, like shadowrealm-src (like worker-src for Worker).

If I can custom the CSP setting for shadowrealm, then I think I will get a nice change to prevent any net io in that.

@erights

[erights]

I have not followed the CSP issues with ShadowRealm. attn @caridy @leobalter

[leobalter]

We have no intention to change the API as it still fits our use cases as currently designed. Anything further should be a follow up proposal, including discussion over extended CSP policies and/or api.

There are ways the imports can be captured through user land code, mostly with membranes. It's complex and of course we can consider expansion, but not to the cost of the current stage of this proposal.