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

> @domenic I'd be curious if there's a summary somewhere of your current set of concerns with the proposal. Seems like you had a clear list of concerns back in March, but it's not clear how many of them are current. Is it still the last one there that's the major issue?

Thanks for the ping. Currently my concerns, in order of largest to smallest, are:

1. Realms encourage buggy and insecure application architecture.

   Realms allow code to run in a "sandbox", but that sandbox is insecure. I mean this in the sense that it has no Spectre protections, or protections against the various arbitrary-write memory safety bugs that every browser continues to exhibit on a frequent basis. Many people (e.g. on the realms issue tracker) have the impression that realms can be used for cases like running non-audited third-party plugin code in the same process as user data, which is a _bad idea_. To the extent realms enable such folly, they should not be added to the platform.
   
   And even if you're just looking for integrity protections (of the sort given by weak maps/private fields/closures), not security ones, it's extremely hard to use realms to gain those protections in a non-buggy way. (Example: https://github.com/tc39/proposal-realms/issues/277.) Experts can successfully achieve integrity in this way, by using complicated systems that go by names like "SES" and "near-membranes". But experts can already achieve these protections with realms polyfills and similar technologies. We should not incorporate something that is a footgun-by-default into the platform, because it allows those experts to ship a little less code; those experts should instead just continue doing what they're doing currently.

1. The availability of realms nudges applications away from isolated architectures.

   The overarching trend of web architecture has been toward more isolation where possible:

   - Process-level isolation via site isolation, origin isolation, and cross-origin isolation (necessary for security)
   - Thread-level isolation via workers and worklets (very helpful for performance)
   - Isolation of even same-origin iframes from each other via [disallowdocumentaccess](https://github.com/whatwg/html/pull/4606)
   - Ensuring that new features like [portals](https://github.com/WICG/portals) or [prerendering](https://github.com/jeremyroman/alternate-loading-modes/) are always isolated.
   
   Indeed, if we had designed the web from scratch, we would have made synchronous cross-realm access impossible. See @annevk's comment in https://github.com/tc39/proposal-realms/issues/238#issuecomment-597005198 for more.
   
   To the extent that application developers use realms in preference to workers/worklets/isolated iframes/etc., they are moving the web in the wrong direction. And to the extent that browser vendors invest in realms technology instead of improving the former technologies to meet more use cases, they are doing the same.
   
   I am especially worried about this in the sense of realms being an attractive footgun, e.g. some authors believe (https://github.com/tc39/proposal-realms/issues/219#issuecomment-652549073) that realms will give parallelism, despite that not being the case.

1. Realms segregate "JS" and the "web platform".

   Realms segregate the "primordials", which are globals from the JS spec such as `Array`, `Map`, `Promise`, and `encodeURIComponent`, from web platform globals such as `Document`, `URL`, `TextEncoder`, `AbortController`, and `setTimeout`. For the first time, they directly expose this difference to web developers, by allowing them to create new realms with only JS-spec primordials.
   
   This division is something we've tried hard to avoid exposing to web developers, as part of the idea that the web platform is unified, and not segregated by which standard body does the work.

1. Realms encourage code injection

   Realms are fundamentally designed around encouraging code injection via `realm.eval()`. In an ideal web, eval and eval-like structures would not be present, so introducing a major new code evaluation vector as the primary entry point into an API is not great.
   
   Realms also allow loading of scripts from URLs, but this brings us to our last point...

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

   Realms change the very oldest of web platform/JavaScript engine integration points, namely the realm and global object relationship. Many web platform behaviors key off of realms. See e.g. some discussion in https://github.com/whatwg/html/pull/5339#issuecomment-723272584.
   
   The majority of these are fixable, e.g. https://github.com/whatwg/html/pull/6137 looks to be in the right direction of being less intrusive. (Yet, HTML is only one of many web specs that would need updating.)
   
   However a major point of contention remains around the integration with the web platform's module system (tc39/proposal-realms#261). In current implementations the module map is tied to "real" realms, which come with associated security principals, fetch clients, HTTP cache partitions, etc. These "synthetic" realms want to create their own module maps, which will require significant rearchitecting, in both spec and implementation.
   
   Finally, I don't know whether the very-high specification complexity of realms will also transfer over into a very-high implementation complexity. However, I suspect that the implementation changes will be more security-sensitive, given how often realms are used in security decisions in the Chromium codebase at least.

-- 
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-728276606