Webview process isolation

Hi,

Are there any plans to remove the VSCode restriction that Webview components are isolated in a sandbox (and therefore can’t access vscode API directly)?

Whether or not there are plans to do it (Microsoft justified it as a security measure https://blog.mattbierner.com/vscode-webview-web-learnings/ ), how difficult would it be to do technically/what would the rough root be? I’m not experienced in these platforms so don’t have a great mental model for these Electron processes.

This seems to be quite a fundamental restriction on extensibility (since one needs to proxy/pass all interactions/state directly, vs what would be at worst a generalized RPC kind of system)

Are there any plans to remove the VSCode restriction that Webview components are isolated in a sandbox (and therefore can’t access vscode API directly)?

I do not believe there are plans to remove the restriction, as mentioned it is due to security concerns which is a very important aspect to consider.

how difficult would it be to do technically/what would the rough root be

It is difficult to estimate, if you were to implement and maintain your own extension which extends/overrides the default behavior, in theory it would be possible but it is unlikely the framework will support unrestricted webviews which are a security concern.

Thanks a lot for the quick reply,

What would the rough road look like for unrestricted webviews? As in roughly which bit of code would need to change, how?

A related question:
If unrestricted webviews in core are off the table, the copyleft license implies that changes to the source would need to be republished, but given the inversify modules used throughout, if one linked to this project and reconfigured the DI patterns hard, that wouldn’t require republishing right? Since no line of actual source would be changed?