Address code execution escalation concerns

[weizman]

Come to think about it, using a CSP header for this feature can potentially introduce security concerns worth reflecting - this PR summarizes important thoughts around it

[weizman]

@yoavweiss I think I'm leaning towards option#2 (meta tag) which is a great sweet spot in the middle between a header and a JS API, because:

1. It's a better version of the header, because it is more unlikely to inject tags, and even more so to inject them high enough in the initial HTML so that they bypass the RIC dictation of the web app itself
2. It's a better version of the header, because it's less of an escalation - if attackers can inject HTML, they might as well inject a script or an iframe
3. It's a better version of the JS API, because it deviates significantly less from the original proposal

That being said, when comparing option#3 to the serviceWorker API, it makes a lot of sense, as the 2 are much alike in terms of power and SOP sensitivity

All in all, a lot to ponder, but what's becoming more clear to me is that option#1 (current proposal's state) is probably the worst one...

Would love to hear your thoughts

[yoavweiss]

LGTM % comment

[yoavweiss]

This will allow 3P scripts to register 3P RIC scripts, which can be sensitive.. Maybe we can add some controls in place if that's not desired (e.g. the API is only available for 1P scripts)

[weizman]

I thought about it @yoavweiss, but that's also unprecedented, meaning:

• The browser does not tell 1p apart from 3p scripts at any scenario (AFAIA), so this will require us to define and introduce new capabilities and checks for being able to generate such information
• This will introduce new capabilities in the browser for entities hosted within a web app (for example, it can be used to tell whether a script runs within 1p or 3p, which cannot be reliably done today)

[weizman]

Added a clarification 09ac2c3

[weizman]

This is an open issue. Continue discussion at #16