Question is how to keep that functionality in MV3? Is there any exception for force-installed extensions?
How exactly eval is blocked? Is that blocked by browser or by extension code review process?
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/65221ad5-fd65-4402-8e73-1fe3fdf3a789n%40chromium.org.
Currently, extensions can inject scripts into web pages through content scripts or the tabs.executeScript() method. In both of these cases, the renderer injects the script in an isolated world - a separate v8::Context that is unique to the extension. This is important for two main reasons:
It prevents the web page from being able to access extension API methods that might be exposed to the content script (such as extension messaging, storage, etc).
It prevents collisions in JS. The extensions window.foo variable is not the same as the page’s window.foo variable.
However, this restriction is designed to be one-way: the web page cannot enter the extension’s isolated world. Going the other direction, and having the extension execute code in the main world, is trivial (and most easily accomplished by simply appending a <script> tag to the page). This can lead to pain points for web developers, since the advantage of the isolated world is gone, and the extension can mutate the web page’s variables. In extreme cases, this could include doing things like mutating Array.prototype or other similar built-in functionality.
This type of mutation is bad for web developers (who have to deal with it) and bad for users (because developers have to find workarounds, which often come with performance costs, or don’t find workarounds, and websites are broken).
Hypothetically, we could restrict an extension’s capability to inject scripts into the main world of a web page, and require that all interaction happen in the isolated world, or else require a separate API to do so (thus increasing our ability to audit uses, as well as preventing accidental use). Removal would potentially break some valid use cases, but it is not clear how many.
However, the feasibility of this and the amount of work entailed are both unknown. There are a variety of edge cases that would need to be taken into account, and this would largely need to be a fool-proof change (or else extensions could work around it).
Likely, the extensions team will have neither the domain knowledge nor the resources to staff this project, and it would have to be pursued by the blink team if there is interest in doing it.
For our PR man the advocate the positive spin on that is "technical reasons".