Hacker News new | past | comments | ask | show | jobs | submit login

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 does not come for a free, as it creates more complex development APIs and a performance hits.




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.


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.


not only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: