Vendors Signal Feedback Cycle 1

[weizman]

This PR focuses on addressing feedback provided by:

• https://github.com/WebKit/standards-positions/issues/389
• https://github.com/mozilla/standards-positions/issues/1062
• https://github.com/w3ctag/design-reviews/issues/985

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

• 18

• 16

• 17

• 14

• 10

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

• 29

• 23

• 28

• 26

• 27

• 20

• 25

• 24

• 30

[weizman]

Progress

• Addressed almost everything via (#20 , #23 , #24 , #25 , #26 , #27 , #28 , #29)
• What's left:
  • [x] 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.
  • [x] 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
  • [x] Nesting - it's still not very clear how should we treat iframes that set their own RIC directive (read more @ https://github.com/WICG/Realms-Initialization-Control/issues/14#issuecomment-2329045381) (also consider using "nesting" instead of "canonicality")
  • [ ] Mechanizm - this concern is still to be thought of and manifested within the explainer