Vendors Signal Feedback Cycle 1

[weizman]

This PR focuses on addressing feedback provided by:

• Realms Initialization Control WebKit/standards-positions#389
• Realms Initialization Control mozilla/standards-positions#1062
• Realms Initialization Control w3ctag/design-reviews#985

As well as issues that are currently open in the same context:

• Missing background information #18
• Escalation to code execution #16
• What is the performance impact of RIC? #17
• What if the CSP directive is dictated from within an iframe? How should we behave?  #14
• CSP not a strong enough mechanizm for RIC implementation? #10

Thus, it includes the following PRs (by merge order):

• Address Support #29
• Address Performance #23
• Update Proposal Requirements #28
• Address Code Execution Escalation #26
• Address CSP Meta Tag Support #27
• Address ShadowRealms #20
• Address Realms Alternative #25
• Address Cross Agent Realms #24
• Address CIA #30

[weizman]

Progress

• Addressed almost everything via (Address ShadowRealms #20 , Address Performance #23 , Address Cross Agent Realms #24 , Address Realms Alternative #25 , Address Code Execution Escalation #26 , Address CSP Meta Tag Support #27 , Update Proposal Requirements #28 , Address Support #29)
• What's left:
  • Taxonomy of Security - I think observing RIC's purpose from the lens of Agoric's "Taxonomy of Security" essay can be highly beneficial, both in general (like ShadowRealm#Security did) and to address Webkit's question regarding side channeling attacks.
  • Monkey patching literature - to Mozilla's request, it might be important to shed some light on how virtualization of JavaScript at runtime helps with security, and how integrating it with RIC is important.
    • Actually, I don't think the explainer should include references to vendors and literature, a sum up of such posted as a reply should cut it (SES, LavaMoat, JScrambler, Airgap, Akamai, Human, etc)
  • Document Policy - to Mozilla's request, we should talk about why RIC is still needed even when put in context against Document Policy
  • Nesting - it's still not very clear how should we treat iframes that set their own RIC directive (read more @ What if the CSP directive is dictated from within an iframe? How should we behave?  #14 (comment)) (also consider using "nesting" instead of "canonicality")
  • Mechanizm - this concern is still to be thought of and manifested within the explainer

[naugtur]

Suggested change

	This feature doesn't provide any information about the user, and hence doesn't have privacy aspects to consider.
	This feature doesn't provide any information about the user, and hence doesn't have privacy aspects to consider.
	It is limited to Same Origin Realms therefore offers no new ways to track the user.

[naugtur]

Suggested change

	* PRO - a capability preserved to the web app (which is the entity expected to be capable of controling such power)
	* PRO - a capability reserved to the web app (which is the entity expected to be capable of controlling such power)

[naugtur]

Suggested change

	* PRO - Better than a header in the sense that transitioning from a headers' setting capability to XSS is unprecedented and quite an escalation, but if attackers need to be able to modify the initial HTML of the app to transition to XSS, that is (1) more unlikely and (2) less of an escalation (if they can inject HTML tags, they might as well inject a script or an iframe).
	* PRO - Better than a header in the sense that escalating from controlling headers to XSS is unprecedented, but if attackers need to be able to modify the initial HTML of the app to transition to XSS, that is (1) more unlikely and (2) less of an escalation (if they can inject HTML tags, they might as well inject a script or an iframe).