4 ms·
I don’t understand why we don’t just sandbox everything. We have done it for web browsers, we can definitely do it for VSCode extensions.
by charlieyu1 5mo ago
I don’t understand why we don’t just sandbox everything. We have done it for web browsers, we can definitely do it for VSCode extensions.
- inlined 5mo agoWhat are you withholding from the sandbox without making it useless?
- atq2119 5mo agoInternet access. An editor extension does not need it.
- sedatk 5mo agoAll AI agent extensions disagree in unison.
- californical 5mo agoIt could request access to a specific domain which you can approve or deny
- larusso 5mo agoMost sandbox systems today, take seatbelt from Apple for instance, only strip permissions. If your extensions without internet access calls a tool that needs it, boom access denied or worse, weird network issues. One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.
- therealdrag0 5mo agoLet the user grant permissions at install time. An error is a success in this scenario.
- atq2119 5mo agoSure, that's the main challenge with building good sandboxing systems. But it's not actually that hard to do when the will to do it is there. For example, Android already allows you to give apps restricted access to your media. My understanding of the way it works is that the resulting interface for picking photos etc. is not under the control of the app. The app only receives whatever file you picked.
- Gigachad 5mo agoBecause it's hard to create a system that is both sandboxed and powerful. You can't have an extension system that allows a plugin to run a locally installed linter or view the status of docker containers but can't execute something malicious. I do agree though that it is incredibly important to start taking sandboxing seriously. But there is a lot of difficulty and friction, and most of the users will scream and cry about extensions being limited.
- charlieyu1 5mo agoI don’t know, we got rid of things like CGI and Java Applets for web but things are still useful enough
- moring 5mo ago> You can't have an extension system that (...) Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both". Taking your examples: > run a locally installed linter VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something. This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata. Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access". Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too. > view the status of docker containers "This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window". > users will scream and cry about extensions being limited Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".