#985: Realms Initialization Control
Discussions
Comment by @jyasskin Aug 28, 2024 (See Github)
Are you planning to, or have you talked to WebAppSec and TC39 about this feature?
Comment by @weizman Aug 29, 2024 (See Github)
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)
Comment by @weizman Sep 12, 2024 (See Github)
Is there any other information I can provide to assist you @jyasskin?
Comment by @jyasskin Sep 12, 2024 (See Github)
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.
Comment by @weizman Sep 29, 2024 (See Github)
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)
Discussed
Oct 14, 2024 (See Github)
https://github.com/mozilla/standards-positions/issues/1062#issuecomment-2412451522 is fun
<blockquote>We're very concerned about a belief that one can make Javascript 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 going forward.
</blockquote> Comment by @jyasskin Oct 15, 2024 (See Github)
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.
Comment by @erights Oct 16, 2024 (See Github)
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.
OpenedAug 28, 2024
こんにちは 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 theon-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.Further details: