Concerns about Realms and Web standard goals

[littledan]

@domenic raised some high level concerns about Realms in whatwg/html#5339 (comment) . Let's continue the conversation here, where we're evaluating Realms overall, and leave the HTML thread to focus on integration details.

[annevk]

FWIW, I share the concern that direct access to other "globals" via frames has been and continues to be problematic. It raises a lot of difficult questions as to where the authority lies as can be seen from HTML's four distinct global concepts and to this day we're still figuring out interoperability here for various APIs (e.g., window.open()): https://html.spec.whatwg.org/#realms-settings-objects-global-objects.

[littledan]

Thanks for explaining, @annevk . I sympathize with difficulties of bringing interoperability and strong definitions to these existing APIs. I was hoping that Realms could consistently defer to their parent Window/Worker for all of this kind of behavior, and that this would mean we wouldn't be increasing the surface area of the issue so much.

[syg]

To recap here, as I've come to learn, there are two categories of concerns:

1. Mechanical concerns about how Realms would work with HTML
2. An existential concern that Realms is counter to the current design principles of the web platform

The second one is the important one we should work through here.

The argument there, AFAIU, is that web APIs have been moving away from sync Realm-creation for a while. New APIs should be async, preferably with process isolation. Even iframes are getting the process isolate treatment via disallowdocumentaccess. I spoke with a few people and have also heard the data point that for the use cases where a simple, synchronous sandbox is sufficient, a new primitive isn't warranted. In the cases where it isn't sufficient, a process boundary is desired anyway.

It seems to come down to how compelling the synchronous use cases are. I admit I'm having difficulty weighing them. The general sentiment seems to be that Workers should be the way to go, but this claim's proposal is that Workers are "nearly impossible to use" for existing use cases. I'd like to better understand:

What is the difficulty that makes them nearly impossible to use? I've heard claims from devs I've talked to that it isn't asynchrony itself that's the challenge, but that the abstractions are wrong and too low-level. You need to build your own communication semantics and other kinds of orchestration yourself.

Edit: Practically my questions boil down to:

• What problems does this solve?
• Is it a net win over the status quo of using iframes? Web devs I spoke to felt "no".

[caridy]

@syg @annevk I'm working on the explainer, collaborating with others on it, which will definitely touch on those concerns, specially the "why" do we need this.

As part of the work that @littledan is helping with, we have agreed that we need to define a new operation that describes where the authority lies when it comes to the web. It is our believe that by finding (recursively) the nearest global object that implements the web semantics (e.g.: window, worker, etc), is sufficient to describe how realms work in the web. That should clarify many concerns related to the mechanics.

As for the particular question about the current design principles of the web platform, and the fact that implementers are favoring separate process, and the specific concern about whether or not Realms is counter to those principles, it is our believe that it is not (and we will try to explain that in the explainer). It will be great if you can also provide more details on what are those concerns.

In the past, there has been some tension around using Realms as a potential foundation for a new security model for the web, that is not the case anymore, and it hasn't been for about 2 years now. And I want to make sure that the concerns from implementers are not based on that principle.

[syg]

It will be great if you can also provide more details on what are those concerns.

What kind of details are you looking for? The high-level concern is: if web APIs as a whole is moving away from synchronous realm-creating APIs, adding a new one via JS sends the wrong signal. Given that, the deciding factor comes down to how compelling the existing use cases are. Both the web developers I've spoken to who work on Google web products and DevRel I've spoken to feel like that the use case Realm seeks to improve does not warrant a new primitive, and in the long run is not a net win over the status quo of using iframes.

Again, I'd love to learn what makes async APIs like Workers "nearly impossible to use". Looking forward to reading the new explainer!

In the past, there has been some tension around using Realms as a potential foundation for a new security model for the web, that is not the case anymore, and it hasn't been for about 2 years now.

I understand. The pushback is a little related though. The question @developit brought up when I chatted with him about the proposal was: where a non-security boundary sync execution sandbox suffices for the use case, do we need a new primitive? Where it is not sufficient, whether due to sync or security reasons, we need to go out of process.

[Jack-Works]

Again, I'd love to learn what makes async APIs like Workers "nearly impossible to use". Looking forward to reading the new explainer!

I think the point is, the Worker cannot share values with the window. That makes it "nearly impossible to use". Cause developers had to stringify their data and send them into the Worker.

where a non-security boundary sync execution sandbox suffices for the use case, do we need a new primitive?

I'm curious about where is "the old primitive" I can use. iframe? It is too heavy and not easy to use.

• You have to create a new iframe (with tons of unused Web APIs, I don't know if creating so much object is a burden to the browser)
• Insert it into the document (this step is bad like set a global variable)
• And I cant use it in a Worker

[atifsyedali]

In our case (similar to Figma's -- see blog post https://www.figma.com/blog/how-we-built-the-figma-plugin-system/) just de/serializing the value and passing it between main and worker threads takes way too long for a large amount of data.

The counter argument to it is to simply use asynchronous API and not pass data. But imagine if you were trying to use Excel and all formulas required async/awaits...

[Jack-Works]

We have a new use case these days, again, similar to Figma's plugin system. We need to interact with plugin synchronously. (Otherwise, the indexed DB will close the transaction after the current working loop ends.)
Without Realms, SES, and Compartments, the only choice is to have a JS VM in JS like what Figma does in their plugin system.

[ByteEater-pl]

In the past, there has been some tension around using Realms as a potential foundation for a new security model for the web, that is not the case anymore, and it hasn't been for about 2 years now.

@caridy, how was the tension resolved, have you got a link handy? Was it by browser implementors' definitive veto or were any fundamental flaws found in that approach? If the latter's not the case, are the ideas from e.g. this paper by @erights et al. [Distributed Electronic Rights in JavaScript] still viable outside of browsers (and possibly even there, though with a tailored implementation or a polyfill flavoured framework, not native support in browsers)?

[erights]

We resolved this by adopting more precise terminology.

The term "security" means different things to different people. In particular, some browser makers reserve the term "security" for either the Same Origin Policy, or for security mechanisms that (at least try to) defend confidentiality against side channel attacks. The mechanisms of Realms, Compartments, SES, and my paper that you link to above do none of these. Rather, they are only about defending integrity. Integrity is a core concern of all abstraction and modularity mechanisms, in support of many software engineering goals. Thus, by consistently labeling the goals of these proposals "integrity" we avoid unnecessary conflict caused by differing definitions.

[erights]

Since I wrote the comment above, there has been endless thrashing caused by the slogan "Realms are not a security boundary". Without defining terms, this slogan is empty. "security" and "security boundary" are both umbrella terms that mean different things to different people. To clarify these matters and give us an understandable conceptual framework, I wrote:

A Taxonomy of Security Issues
for understanding language-based security and modularity

In these terms, Realms are an integrity boundary. They are clearly not an availability boundary. Regarding confidentiality, they contribute little. They do nothing to inhibit non-overt channels (side and covert channels). They are a boundary regarding overt channels.

[leobalter]

I believe the new Callable Boundary API was a good resolution for most of the concerns raised here. Thanks everyone!