explain transitivity mechanisms

[caridy]

What would happen when a newly created same domain iframe without the meta/header attempts to create another same domain iframe? Similarly, what would happen if the iframe's src (from same domain) does have additional meta/header itself? I see the following paragraph in the readme:

the top main realm is the only realm in a webpage with the power to set the new CSP directive, and it must trickle down to child realms from the same origin, as they don't have the power to set this directive.

But it is not clear how this will work. While CSP directives can trickle down just fine... this is not about a traditional CSP rule, but about an entry point to execute scripts. What happens if top adds a.js, while the iframe adds b.js to the meta/header? From the paragraph above it seems that only a.js gets executed, even though b.js should be additive.

[weizman]

The paragraph correctly manifests this proposal's intention - b.js should not be added. Non-top realms should not be able to set the RIC directive, I am not yet convinced it makes sense for child realms to be able to set it. As for this not being a classic CSP rule, agreed, we are already investigating whether CSP is most appropriate for this proposal https://github.com/WICG/Realms-Initialization-Control/issues/10#issuecomment-2346540154

[caridy]

Non-top realms should not be able to set the RIC directive, I am not yet convinced it makes sense for child realms to be able to set it.

The thing is that in many cases, the child does not need to know that it is being embedded, nor it needs to be controlled by the same people. In the child app requires the directive to function well, will that app just simply fail to load because it is trying to exercise a capability that is often available but not always available? I don't recall any precedent for something like this in the web.

[weizman]

I don't recall any precedent for something like this in the web.

The whole 3rd party scripts long living paradigm is such precedent, which is true to almost any software that's being constructed at runtime (remember '$' is undefined?).

When websites are being constructed live in the browser, they embed scripts that often count on some prerequisites to exist. To this day many of them do so unsafely, and by that crash with exceptions, but the better ones simply check for those required prerequisites to exist before counting on them.

Same goes for cross origin iframes, and same would be expected from same origin iframes - to check whether capabilities needed by the child were first initialized via an RIC script (or something else) at the top.

[caridy]

fair enough, but how to feature test this? just curious!

[weizman]

Well, it really depends on what they expect to find, since RIC's nature is essentially code.

So if the precedent was '$' is undefined so that scripts would ask if (!window['$']) return, here it would be pretty much the same, where a normal script would ask if (!window['SOME_API_LEFT_BY_RIC']) return.

Since many RIC use cases would be to perform reconfiguration of the environment instead of exposing new APIs, they could also leave a mark instead if (!window['ENV_DEFENDER_JS_DOT_COM_EXECUTED']) return.

[caridy]

Oh, that's a user-land mechanism, I was asking about a built-in mechanism, equivalent to something like "am I being embedded?", so you can take certain measures. Equivalently, I can ask, is my app running in a distorted env, so I can't really distort my same domain iframes?