Realms Initialization Control

[weizman]

こんにちは TAG-さん!

I'm requesting a TAG review of Realms Initialization Control.

Initialization of same origin realms in an application should be under that application's control.

This proposal describes an opt-in capability to set a script to be loaded first, every time a same origin realm with synchronous access to the main execution environment of the application is created.

The location of the script can be relative or absolute. Secure connection is required. The proposed method for setting the script is a Content Security Policy directive as follows: Content-Security-Policy: "realm-init: /scripts/on-new-same-origin-realm.js" so that the on-new-same-origin-realm.js script will execute before any other JavaScript code executes in the top realm execution environment, as well as any other child realm that matches its origin.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/Realms-Initialization-Control
• Security and Privacy self-review²: https://github.com/WICG/Realms-Initialization-Control#self-review-questionnaire-security-and-privacy
• GitHub repo: https://github.com/WICG/Realms-Initialization-Control
• Primary contacts (and their relationship to the specification):
  • Gal Weizman (Champion)
  • Yoav Weiss (Spec Mentor)
• Organization/project driving the design: ConsenSys
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5080729822953472

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• Existing major pieces of multi-implementer review or discussion of this design: None atm
• Major unresolved issues with or opposition to this design: None atm
• This work is being funded by: ConsenSys

[jyasskin]

Are you planning to, or have you talked to WebAppSec and TC39 about this feature?

[weizman]

Sure did, the community was rather interested in solving this issue as well as in the manner suggested:

• https://www.w3.org/2023/03/secure-the-web-forward/talks/realms.html
• https://www.w3.org/2023/03/secure-the-web-forward/report.html

(edit: as well as accepted to the WICG of course)

[weizman]

Is there any other information I can provide to assist you @jyasskin?

[jyasskin]

Sorry for dropping this. Secure the Web Forward isn't either of WebAppSec or TC39. Do you need introductions into those communities? I'm inclined to think that this is reasonable, but those communities have the deep expertise to notice risks or smoother ways to do this.

[weizman]

Fair enough, thanks @jyasskin for the clarification.

Driven by your feedback, I pitched RIC to the WebAppSec group at last week's TPAC.
From my perspective, while folks helped nudge us in better directions regarding some of our takes, it seems that in general they were somewhat interested in this proposal and what it'll help deliver.

The recording isn't out yet, but from what I recall, the minutes really capture the gist of the conversation rather well, given how it was only 15 minutes long - 2024-09-26-TPAC-minutes.md#realms-initialization-control (cc @yoavweiss)

[jyasskin]

We talked about this in our breakout today, and we're very concerned about a belief that one can make a Javascript environment secure against hostile Javascript by running first. We think WebAppSec and TC39 have relevant experience in this space, and you should make sure they're both happy with this before moving forward.

[erights]

We think WebAppSec and TC39 have relevant experience in this space, and you should make sure they're both happy with this before moving forward.

For context, I've been on TC39 since 2007 with a strong focus on security. I believe the following comments speak for many participants on TC39, especially those active in TG3, the Technical Group on JavaScript security.

We talked about this in our breakout today, and we're very concerned about a belief that one can make a Javascript environment secure against hostile Javascript by running first.

At TG3, we tend to avoid the overly broad term "Security", and focus instead on its main components: Integrity, Availability, Confidentiality, as explained at
A Taxonomy of Security Issues for understanding language-based security and modularity.

Starting with EcmaScript 5, we explicitly designed JS so that one can make a Javascript environment secure against hostile Javascript by running first, regarding integrity attacks. The ses-shim is an implementation of Hardened JS as code that runs first, mostly to protect integrity. But
Hardened JS Web Challenge
seems to demonstrate that it also protects confidentiality under limiting assumptions. This challenge is on a web page running in a browser accepting hostile JS after it runs first. It is a subject of Agoric's bug bounty program. For purposes of this conversation, an attack on either integrity or confidentiality would win the point of the challenge.

As A Taxonomy of Security Issues explains, there is no practical defense of availability against hostile code running in the same thread (aka "agent"), and Hardened JS makes no attempt to do so.

Those who believe that a script that runs first cannot defend integrity against hostile JS loaded later should submit guest code that breaks the integrity of the Hardened JS Web Challenge host program.

So, please reopen this bug. Thanks.