3 ms·

Please correct me if I am wrong but the only application (class) that currently sandboxes extensions is a web browser. So the bar is pretty high. Sandboxing do

• dumbo-octopus 2y ago
  And happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
  • essentia0 2y ago
    not only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.
    • dumbo-octopus 2y ago
      Sure, I’ve even made a handful of those myself. I contrast them with workspace extensions that run on a (possibly remote) host with full access to subprocesses/etc.
• CraigJPerry 2y ago
  Definitely. Would still be nice to have the option to opt into, for example, running as a WASM isolate - given the option of a robust sandbox, some plugins will find it desirable to migrate and gain the secure badge or however isolated plugins are marked for user identification. But There are plugins where it’s going to be too much of an uphill battle to move to that model though. I still think on balance having sandboxed plugins, however they’re implemented, would be pretty nice.