Most 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.
Sure, 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.
Because 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.
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".
I don’t know what linters you use, but the ones I like are the ones that show you problems in the workspace stably, not just in the files that happen to be open and altering as files open and close.
You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.
> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
I claimed that it is possible, not that it is easy.
Im highlighting that defining that sandbox policy cohesively in a way that works for all the different extensions types you’d want to support and doesn’t overwhelm the user with permission fatigue is difficult as to be impossible.
Browsers have a different problem - they protect different websites against each other. The IDE should probably protect you against extensions being able to access arbitrary files on disk, but even that’s difficult (eg a bundled linter often wants to read user defaults in a central location. But protecting even further than that is even harder, especially as here where the access was to the actual repo not anything else.
These kinds of permissions lists have been mostly a failure in history. Users see a massive list of permissions, or permissions constantly changing between updates and just ignore them because there’s no way to reasonably audit them or take any action on them.
Securing VS code would require making malware that has access to the system impossible, not just making it add a permission to the permission list.
Ideally, the permission list is meant for curators which end-users trust and can rely on.
Also, historically, permission lists have been fine-grained but too coarse at the same time, meaning they were "fine" in the wrong way, based on what is easy to implement instead of what the user needs.