Plugin sandboxing

[sniok]

Current plugin system runs plugin's code at the same level as the rest of the app, meaning plugins have similar permissions as the app itself. This may pose a security risk when installing external plugins through plugin catalog

To limit abilities of plugins we could sandbox them, execute them in a restricted environment

---

The most straightforward way is to use an <iframe /> with sandbox attribute. This approach loads the plugin into it's own iframe that is considered a separate origin. To communicate with the app, plugin will have to use new API that send and receive messages via postMessage method.
The limitation of this approach is that we need to create a new iframe for each functionality that plugin can implement in the UI (like a new route or a button in a header), while for other use-cases like modifying table column this will restrict the plugin to only be able to update table with serializable data (without the ability to pass react components for example).
This approach will require a new set of APIs for every existing functionality (which can be made somewhat compatible with existing APIs) and any existing plugin that would want to migrate to this sandboxed approach will need to be reimplemented.
This will be a considerate effort.

I've created a proof of concept of this approach that is available in a sandboxed-plugins branch. It adds API based on postMessage and reimplements Kompose plugin to this approach.

---

ShadowRealm API looks promising but it's not implemented yet https://github.com/tc39/proposal-shadowrealm