[proposal] Different script contexts with different browser features allowed

Feature policy can be defined for browsing context , but there is no way to define it for script context. I think it’s totally wrong, and there is an objective need to be able to run different scripts in different script contexts (with different global environments and different set of available browser features / Web APIs). Example: I need to run two scripts on a webpage. The first script is a first-party script that will access sensetive data (or fingerprintable API’s). The second script is a third-party script that will make some network requests. I need to isolate these scripts from each other to ensure that the second script will never have access to sensetive data. But now there is no way to do it. I tried to create a model that can describe script contexts and any browser feature that can be used, maybe someone will find it helpful: https://pastebin.com/EGBX5Z5G

Note: see also https://github.com/WICG/feature-policy/issues/238

This is a very laudable goal, and I think it would help with various security and privacy issues on the Web. When suggestions along these lines have been raised in the past, the challenge of adding these restrictions to the existing scripting model has been a blocker.

I think one of the first steps here needs to be documenting and preventing any workarounds. That is, scripts loaded with a limited set of privileges need to not be able to break out of that sandbox. If a script can modify the DOM, can it add another script element? And then, at the next level, if it has shared state with the more privileged scripts, can it influence the actions of those scripts in such a way that it effectively exceeds its privileges?

Is there academic work on this topic? Could we collect it and synthesize the key conclusions or recommendations?

Each script should have two ways of executing another scripts:

1. Execute script within the same context.
2. Execute script within a new script context. Each newly created script context should inherit all limitations from parent script context.

1. Priveleged scripts shouldn’t be able to influence the actions of scripts that may send network requests.
2. Priveleged scripts should be able to be influenced by scripts that may send network requests.

I don’t think it is possible. It is a paradox.

As long as the ‘privileged’ script will be able to modify the DOM, it is impossible. And if the ‘privileged’ script cannot modify the DOM, then the privileged script is useless because you cannot do much without it.

The argument is the same as those people who blame everything on 3rd party script by some Ad networks. What they dont realize is that their argument is insane. If ads were forced to be first party, they would still be tracked. But their ability to not be tracked would be hampered even more because when everyones browser does not support 3rd party scripts, then ad networks would develop a 1st party tracking ecosystem, to track you via 1st party cookies and other identifiers like ip address and statistically correlate them.

Tracking is an issue because of the users of the web platform expect everything for free. Its a race to bottom.

It is possible if the ‘privileged’ script will not be able to create and / or modify script elements, but will be able to do any other DOM modifications.