Re: [w3ctag/design-reviews] Realms API ECMAScript Proposal (#542)

hey @domenic thanks for reinstating your concerns, I will try to do my best to address them:

> 1. Realms encourage buggy and insecure application architecture.

We (the champions) have been very clear about this for a long time, Realms are not a security boundary. If you want a security boundary, you go async, where Realms can be complementary if you decide to slice and dice the evaluation of code inside that process. We have addressed this concern to make sure that when we use the term "3rd party code" we say "trusted code".

This proposal is simply trying to formalize something that is available across all platforms that are implementing the language. Which in many of them, it is extremely difficult. Let me list them here yet one more time:

* Browsers (partially supported via same domain iframes)
* Node (fully supported via VM module)
* iOS/JSCore (fully supported via [JSContextGroupCreate](https://developer.apple.com/documentation/javascriptcore/1451632-jscontextgroupcreate)
* Android/V8 (fully supported via [v8::Context::New](https://docs.google.com/document/d/1jpQQX0piaxcHJPWakp_Kr_03g5Gnma5h5-Kdlqu7jVQ/edit#heading=h.k6iklq6rvd30) -- where you can read why Google this it in the first place)

In each of them, it is harder and harder to achieve the same, for no particular reason. This proposal attempts to normalize this across the board, and fix the drawbacks of using the same domain iframe. For these reasons, I will disregard this concern as subjective.

> 2. The availability of realms nudges applications away from isolated architectures.

As we have debated in the past, going async is not an option for an architecture that attempt to provide any virtualization between trusted sides in a language that is primarily sync (a good example here is Google AMP DOM virtualization project). As I mentioned above, we see Realms as a complement of the architectures that you listed above.

> 3. Realms segregate "JS" and the "web platform".

This concern is a solid concern, it is not our place at TC39 to dictate what the web platform should do, or not. My personal opinion is that this ship has sailed a long time ago with the surge of nodejs, and the respective native platforms exposing V8 and JSCore to developers. The de-facto distribution model for JS code via NPM already highlight this issue extensibly, and developers, and more important, the tools available for developers, have helped to mitigate this in some extend.

> 4. Realms encourage code injection

This is not accurate, you do not have to enable eval to use Realms, nor it will encourage to do so. How will a program (running on the web) evaluates another piece of code? what are the available mechanisms to do so? You have script injection (considered legacy at this point), dynamic import, and eval. In a Realm, you will have a subset of that, you have dynamic import (via `realmObj.import()`) or eval (via `realmObj.globalThis.eval()`). Basically, this proposal will not require the developer to change their application configuration to evaluate code, it will seat on top of the existing application settings.

> 5. Realms bring significant technical and specification complexity. (Last concern becuase of priority of constituencies.)

I'm not an expert on this subject, but this has been extensibly debated by other folks, and as far as I can tell, they believe this is not as complex as you think it is. I will let others to counter this argument.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/542#issuecomment-728326217