The problem extends far beyond VS code. All extensions and executable code has the same problem. There was a case where Disney was hacked because an employee installed a BeamNG mod that had bundled malware.
A company that wants to remain secure would have to employ strict restrictions on installing software. Only installing npm packages and plugins from an internal preapproved repo for example.
Running code isn't the problem. The fact that (almost) all code runs at the same security level is.
You regularly run tons of untrusted code when visiting websites. That code can't wreak havoc on your machine because it's well-sandboxed. Yet, if we advocate for sandboxing in more places, the "gun nuts of tech" scream about monopolistic practices and taking away user control.
Fully agree with the first half of your comment. The second half goes off the rails, though.
I rarely see people complain about sandboxing.
What people complain about is when devices are locked down in a way where you are only allowed to install software that is approved by a central gatekeeper, even though sandboxing is in place that should make it far safer to run arbitrary safer than on traditional desktop systems.
Agreed. What's frustrating is that we have models for how sandboxing can work and instead of investing efforts into nailing that experience, the OS providers are prone to turning it into a monetization/lock in layer instead. My VLC and VS Code should have an OS native way of being limited to particular functionality. But when the OS providers implement the sandbox, they center it around an App Store and restrictions on only apps that have been notarized where said notorization costs money or a requires a subscription. And then they remove the ability to do things which their own native apps can do and set tighter controlling rules on what APIs apps can ever have access to.
When all I wanted was for VLC or similar to run in a sandbox by default where a plug-in I install can't do anything to my system or access the internet by default because the software itself is restricted to just the files I'm using and that's it.
That exists on linux under flatpak, but it requires Wayland and Pipewire. Also many packages just request full system permissions rather than update to work in a sandbox.
It's in the works and one day we will have it but progress is slow.
Never let a crisis go to waste, huh?
We've had the solution to shit like this, and it's called the SecurityManager in Java. No one wants to configure the damn thing, but it is there. Also, auditing the code you pull in. Yeah. Reading code sucks. Yeah. It's a lotta work. But if you don't check, you don't effing know.
All y'all want the fun of unprotected sex (rawdogging the ecosystem) and are starting to get burned by the VD's we old-timers have been hollerin' at you telling you will be coming the more you do this promiscuous dependency inclusion.
But hey. Enjoy it I guess. No skin off my nose.
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.
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.
What are you withholding from the sandbox without making it useless?
Internet access. An editor extension does not need it.
All AI agent extensions disagree in unison.