7 ms·

Sure, AI tools can do this. However, VS Code is the platform. Why aren't more people worried about running arbitrary VS Code extension that can do the same thin

Sure, AI tools can do this. However, VS Code is the platform. Why aren't more people worried about running arbitrary VS Code extension that can do the same thing, AI or not?

zukzuk 8mo ago
Yes, exactly. The lack of any sort of permission controls for extensions in VS Code gives me the creeps
deleted 8mo ago
[deleted]
tormeh 8mo ago
The situation is absolutely insane, but it's also productive, but real security would slow everything down a lot. The moment you ask some corporate bureaucrat to put their signature down on a piece of paper saying that such and such dev tool is approved for use, they're going to block everything to avoid the responsibility implied by their approval. I can't really come up with a system that both works and is secure. The only exception is signing up for an integrated environment where Microsoft or Apple provides the OS, compiler, and editor. Oops - Apple doesn't sell servers, so only Microsoft offers this. Hope you like C#. In theory you can mix and match, but in practice most bureaucrats will insist on single-sourcing.
- rapind 8mo ago
  Linux development has a blueprint they could follow. Like the principle of least privilege. These aren’t cutting edge concepts. Also I’m not sure the tradeoffs of adding security to an editor are that big of a deal. Are we really seeing revolutionary stuff here? Every now and then I check out VS Code only to realize Vim is still 10x better.
  - fc417fc802 8mo ago
    Vim is hardly secure either. Extensions in both provide for arbitrary code execution.
    - rapind 8mo ago
      No doubt, but I (and I suspect many others) rarely update plugins and I have a very select list of plugins that I use (mostly from one guy), and I just use git to manage them. I never see churn, but that might just be me. I assume you could probably do the same with VSCode, but I suspect there's a cultural difference that pushes you to always update? Do things stop working because of churn?
- not_ai 8mo ago
  At the company I work for they locked down installing extensions through the marketplace. Some are available but most are not and there is a process to get them reviews and approved. You might be able to side load them still but I haven’t cared enough to want to try. They did the same with Chrome extensions.
g947o 8mo ago
As an VSCode extension author, I am always terrified by the amount of power I have. It is a shame that the team never prioritized extension permission issues [0] despite their big boss said security is the top priority [1]. All they have is "workspace trust" and various other marginally useful security measures. I don't install a VSCode extension unless it is either official or well known and audited and I have to use it. I keep most of them disabled by default unless I need something for a project. (Even if you don't care about security, it's good for VSCode performance. I'll save that story for another day.) [0] https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116 [1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/ https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...
- yomismoaqui 8mo ago
  When some minor extension that I have installed on VSCode updates (like parens colorizing and the like) I think what could happend if the author sells it to some bad actor (or decides to push some weird code in an update). So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago. I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.
  - thedanbob 8mo ago
    It doesn't even have to be malicious. I used a certain syntax highlighting theme for years, when out of nowhere the author pushed an update that rearranged all the colors. It was extremely disorienting. I forked the extension and reverted the change, so I know that one at least won't change out from under me anymore.
    - freedomben 8mo ago
      This is the thing I hate the most about "automatic updates" in general. I've disabled them and gone back to updating manually because the constant unexpected and unwanted UI changes finally broke a part of my soul. Unfortunately that is something that can't be done on the web, where major UI changes can be rolled out right in the middle of a session on you.
mentalgear 8mo ago
Same thing for browser extensions: a simple browser extension (e.g. web dark mode), can read all your password fields. It's crazy that there are no proper permission scopes in any major browsers ! It would have been so easy to make password / email fields exempt from browser extensions unless they ask for the permission.
- fc417fc802 8mo ago
  In your example wouldn't that leave the email and password fields the wrong color? I agree with the principle though. Most extensions don't need to access everything.
  - mentalgear 7mo ago
    No, you only need to protect input.value - styling can be left to the extension.
- vunderba 8mo ago
  Pro tip: I’ve seen plenty of dedicated extensions that could have just been simple snippet equivalents in Tampermonkey - an extension that lets you run JS limited to wildcarded websites. I've used it to inject download links on sites, autoclose modals, etc. You can either write them yourself, or review other people before installing them. It’s not a perfect solution, but at least it reduces the surface area to a single extension. FYI: Just set Script Updates to Never. https://github.com/Tampermonkey/tampermonkey https://github.com/Tampermonkey/tampermonkey
- sheept 8mo ago
  I do not think it'd be "so easy" to separate password input access into a separate permission because it'd only open up a can of worms. There's so many ways to read a password input's value, from listening to key events to monkey patching `fetch`, that it's not worth playing whack-a-mole just to provide users a false sense of security I'm also skeptical that even a dark mode extension would be simple considering how varied web pages can be
  - 7mo ago
larodi 8mo ago
I am (am worried) and recently stopped adding extensions by just the random anon. Also I take time to sanitise foreign (to my knowledge) gh repos using Claude code.
- freedomben 8mo ago
  As an aside, claude and codex (and probably gemini) are pretty good at doing that. I've now done it with several repos and they are pretty good at finding stuff. In one case codex found an obscure way to reach around the authentication in one of our services. This is a great use case for LLMs IMHO They are (of course) not foolproof and very well may miss something, so people need to evaluate their own risk/reward tradeoff with these extensions, even after reviewing them with AI, but I think they are pretty useful.
dirkc 8mo ago
Installing any 3rd party dev dependency without sandboxing should terrify you. These supply chain attacks are not hypothetical. Trusting other devs to not write malicious code has led to a surprisingly small number of incidents so far, but I don't think this will extrapolate into the future. With more lines of code being auto-written without deliberate intent or review from an accountable author, things can only get worse!

Sure, AI tools can do this. However, VS Code is the platform. Why aren't more people worried about running arbitrary VS Code extension that can do the same thing, AI or not?

zukzuk 8mo ago

Yes, exactly. The lack of any sort of permission controls for extensions in VS Code gives me the creeps

deleted 8mo ago

[deleted]

tormeh 8mo ago

The situation is absolutely insane, but it's also productive, but real security would slow everything down a lot. The moment you ask some corporate bureaucrat to put their signature down on a piece of paper saying that such and such dev tool is approved for use, they're going to block everything to avoid the responsibility implied by their approval. I can't really come up with a system that both works and is secure. The only exception is signing up for an integrated environment where Microsoft or Apple provides the OS, compiler, and editor. Oops - Apple doesn't sell servers, so only Microsoft offers this. Hope you like C#. In theory you can mix and match, but in practice most bureaucrats will insist on single-sourcing.

rapind 8mo ago
Linux development has a blueprint they could follow. Like the principle of least privilege. These aren’t cutting edge concepts. Also I’m not sure the tradeoffs of adding security to an editor are that big of a deal. Are we really seeing revolutionary stuff here? Every now and then I check out VS Code only to realize Vim is still 10x better.
- fc417fc802 8mo ago
  Vim is hardly secure either. Extensions in both provide for arbitrary code execution.
  - rapind 8mo ago
    No doubt, but I (and I suspect many others) rarely update plugins and I have a very select list of plugins that I use (mostly from one guy), and I just use git to manage them. I never see churn, but that might just be me. I assume you could probably do the same with VSCode, but I suspect there's a cultural difference that pushes you to always update? Do things stop working because of churn?
not_ai 8mo ago
At the company I work for they locked down installing extensions through the marketplace. Some are available but most are not and there is a process to get them reviews and approved. You might be able to side load them still but I haven’t cared enough to want to try. They did the same with Chrome extensions.

g947o 8mo ago

As an VSCode extension author, I am always terrified by the amount of power I have. It is a shame that the team never prioritized extension permission issues [0] despite their big boss said security is the top priority [1]. All they have is "workspace trust" and various other marginally useful security measures. I don't install a VSCode extension unless it is either official or well known and audited and I have to use it. I keep most of them disabled by default unless I need something for a project. (Even if you don't care about security, it's good for VSCode performance. I'll save that story for another day.) [0] https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116 [1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/ https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...

yomismoaqui 8mo ago
When some minor extension that I have installed on VSCode updates (like parens colorizing and the like) I think what could happend if the author sells it to some bad actor (or decides to push some weird code in an update). So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago. I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.
- thedanbob 8mo ago
  It doesn't even have to be malicious. I used a certain syntax highlighting theme for years, when out of nowhere the author pushed an update that rearranged all the colors. It was extremely disorienting. I forked the extension and reverted the change, so I know that one at least won't change out from under me anymore.
  - freedomben 8mo ago
    This is the thing I hate the most about "automatic updates" in general. I've disabled them and gone back to updating manually because the constant unexpected and unwanted UI changes finally broke a part of my soul. Unfortunately that is something that can't be done on the web, where major UI changes can be rolled out right in the middle of a session on you.

mentalgear 8mo ago

Same thing for browser extensions: a simple browser extension (e.g. web dark mode), can read all your password fields. It's crazy that there are no proper permission scopes in any major browsers ! It would have been so easy to make password / email fields exempt from browser extensions unless they ask for the permission.

fc417fc802 8mo ago
In your example wouldn't that leave the email and password fields the wrong color? I agree with the principle though. Most extensions don't need to access everything.
- mentalgear 7mo ago
  No, you only need to protect input.value - styling can be left to the extension.
vunderba 8mo ago
Pro tip: I’ve seen plenty of dedicated extensions that could have just been simple snippet equivalents in Tampermonkey - an extension that lets you run JS limited to wildcarded websites. I've used it to inject download links on sites, autoclose modals, etc. You can either write them yourself, or review other people before installing them. It’s not a perfect solution, but at least it reduces the surface area to a single extension. FYI: Just set Script Updates to Never. https://github.com/Tampermonkey/tampermonkey https://github.com/Tampermonkey/tampermonkey
sheept 8mo ago
I do not think it'd be "so easy" to separate password input access into a separate permission because it'd only open up a can of worms. There's so many ways to read a password input's value, from listening to key events to monkey patching `fetch`, that it's not worth playing whack-a-mole just to provide users a false sense of security I'm also skeptical that even a dark mode extension would be simple considering how varied web pages can be
- 7mo ago

larodi 8mo ago

I am (am worried) and recently stopped adding extensions by just the random anon. Also I take time to sanitise foreign (to my knowledge) gh repos using Claude code.

freedomben 8mo ago
As an aside, claude and codex (and probably gemini) are pretty good at doing that. I've now done it with several repos and they are pretty good at finding stuff. In one case codex found an obscure way to reach around the authentication in one of our services. This is a great use case for LLMs IMHO They are (of course) not foolproof and very well may miss something, so people need to evaluate their own risk/reward tradeoff with these extensions, even after reviewing them with AI, but I think they are pretty useful.

dirkc 8mo ago

Installing any 3rd party dev dependency without sandboxing should terrify you. These supply chain attacks are not hypothetical. Trusting other devs to not write malicious code has led to a surprisingly small number of incidents so far, but I don't think this will extrapolate into the future. With more lines of code being auto-written without deliberate intent or review from an accountable author, things can only get worse!