Use cases

[weizman]

Use cases of the RIC proposal are needed.

If you find this proposal useful, its probably because you have a use case for it.

Sharing it with us would help a lot in showing the community this is an important issue to fix.

You can either share here or open a PR.

[eligrey]

Transcend would consider adopting this API in airgap.js to implement efficient privacy protections if shipped in browsers. We currently hook realm creation, although we are limited by platform capabilities for some realm creation sources.

[nicjansma]

Akamai has a few products that could use something like this:

• We have a real user monitoring (RUM) product that wraps a lot of top-level APIs for performance and error telemetry. For example:
  • XMLHttpRequest and fetch to monitor network performance
  • addEventListener to get better call stacks for errors
• We have bot management and security products that wrap APIs for protection and monitoring

Our existing patching techniques generally just swap our own function in for the native one, and squirrel away the original incase we need to "un-patch".

We've seen cases in the past where this patching can conflict with other third-parties who use slightly-different techniques or have different expectations. Problems can arise when the loading order between the third-parties is not controlled, and one library may not work well when loaded first/last.

Having a better-defined way of being able to control patching would probably help with stability and security-related concerns like above. We would definitely consider something like this to harden our existing "patching" techniques.

[yoavweiss]

Shopify sandboxes various scripts in different ways. One of them (the lax sandbox) is using a same-origin sandboxed iframe. Custom overriding of native functions further restricts the capabilities that code running in these iframes has access to. Being able to perform those overrides as the (guaranteed) first script that runs in these iframes would help us ensure that malicious code doesn't attempt to escape those restrictions.

[kzar]

I could imagine browser extensions like Adblock Plus and DuckDuckGo Privacy Essentials using this if it became available. I wrote up more of an explanation on this related proposal, but the short version is that to stop adverts and fingerprinting, such extensions often need to wrap certain APIs, to restrict how the website uses them. We attempt this already, for example see this old Adblock Plus code, but there are seemingly unending tricks websites use to circumvent us.

Having it managed via a CSP header sounds good, since extensions can add those and they are additive (so we won't undo the website's CSP header, or weaken it, if there was one already present). But my question would be what if the website already set the new realm-init directive? Ideally for our use case, in that situation our realm-init directive would "win", but I wonder about the details there. If that wasn't the case, we'd be stuck parsing and editing the CSP headers ourselves, which I worry would be error prone and lead to us making the CSP of some websites weaker by accident.

[weizman]

Hi @kzar, thanks for participating,

To be honest, I don't think RIC is the right place for such use case, because RIC's purpose is to help web apps regain control over their own (same origin) realms, without taking extensions into account. That's why we decided to introduce this via CSP - it's the security policy API the browser provides for websites, not for extensions.

AFAIA, CSP directives that can be added on aren't a thing, so we'll definitely won't focus our energy towards challenging that in this proposal. I know that extensions that need to modify the CSP headers of websites when introduced by a website, usually do so by parsing and editing its content before serving it on to the user (as you mention). If this isn't good enough (as you say), I'm afraid that sounds like a new issue (unrelated to RIC).

Sorry if I mislead you earlier here, I think I misunderstood the situation there 🙏

[kzar]

Browser extensions can add response headers, and in fact Adblock Plus and the other ad blockers already do support adding CSP headers using the $csp filter option. When multiple CSP response headers are active, each one can make the policy more restrictive but never less restrictive (see "Enforcing multiple policies" in the spec). That is why to apply a $csp filter to a website, we could just add another CSP response header, instead of worrying about the existing headers the website had. I think you will need to consider what happens when there are two or more CSP headers with a realm-init directive therefore. I suppose as long as there's a reliable way for extensions to make sure their entry wins (e.g. by making sure their header is first in the list or something) then it's fine by me.

[weizman]

You learn something new every day - #6 - Thank you @kzar.

I believe #6 should fit your needs properly, would love your feedback on this.