Comment by Tyriar
1 month ago
> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment
Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically.
> I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it".
I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
> Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state.
You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
> Trusting this folder means code within it may be executed automatically.
But as you point out elsewhere, what constitutes code is very context dependent. And the user isn't necessarily going to be sufficiently expert on how Code interacts with the environment to evaluate that context.
> I'm curious what would stop you from opening it in restricted mode?
Even after years of using Code, I don't know the precise definition of "restricted mode". Maybe I ought to, but learning that isn't at the top of my list of priorities.
> You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
NO! Not even close! And maybe this is at the heart of why we're not understanding each other.
My goal is not to run an editor and change some characters, not at all. It's so far down the stack that I'm scarcely aware of it at all, consciously. My goal is to, e.g., find and fix the bug that the Product Manager is threatening to kill me over. In order to do that I'm opening log files in weird locations (because they were set up by some junior teammate or something), and then opening some code I've never seen before because it's legacy stuff 5 years old that nobody has looked at since; I don't even have a full picture of all languages and technologies that might be in use in this folder. But I do know for sure that I need to be able to make what edits may turn out to be necessary half an hour from now once I've skimmed over the contents of this file and its siblings, so I can't predict for sure whether whatever the heck "restricted mode" will do to me will interfere with those edits.
I'm pretty sure that the above paragraph represents exactly what's going on in the user's mind for a typical usage of Code.
Good point about one off edits and logs, thanks for all the insights. I'll pass these discussions on to the feature owner!
Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"?
In light of this vulnerability, the team may want to revisit some of these assumptions made.
I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this workspace?' and hit the big blue "Yes" button to quickly just get to work.
With AI and agents, there are now a lot of non-dev "casual" users using VS code because they saw something on a Youtube video too that have no clue what dangers they could face just by opening a new project.
Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
Didn't mean to come off that way, I know a lot of the decisions that were made. One thing I've got from this is we should probably open `/tmp/`, `C:\`, ~/`, etc. in restricted mode without asking the user. But a lot of the solutions proposed like opening everything in restricted mode I highly doubt would ever happen as it would further confusion, be a big change to UX and so on.
With AI the warning needs to appear somewhere, the user would ignore it when opening the folder, or ignore the warning when engaging with agent mode.
> Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).
I’m not sure this is possible or non-misleading at the time of granting trust because adding or updating extensions, or changing any content in the folder after trust is granted, can change what will be executed.
For what it's worth, I absolutely agree with the comments saying the warning doesn't clearly communicate the risks. I too had no idea opening a directory in VS Code (that contains a tasks.json file) could cause some code to execute. I understood the risk of extensions but I think that's different, right? i.e. opening a trusted project doesn't automatically install extensions when there's an extensions.json (don't quote me on that, unless that's correct)
To give some perspective: VS Code isn't my primary IDE, it's more like my browsing IDE. I use it to skim a repo or make minor edits, without waiting for IntelliJ to index the world and initialize an obscene number of plugins I apparently have installed by default. Think—fixing a broken build. If I'm only tweaking or reinstalling dependencies because the package-lock file got corrupted and that's totally not something that happened this week, I don't need all the bells and whistles. Actually I want less because restarting the TypeScript service multiple times is painful, even on a high end Mac.
Anyway enough about IntelliJ. This post has some good discussions and I sincerely hope that you (well, and Microsoft) take this feedback seriously and do something about it. I imagine that's hard, as opposed to say <improving some metric collected by telemetry and fed into a dashboard somewhere>, but this is what matters. Remember what Steve Ballmer said about UAC? I don't know if he said anything, but if it didn't work then it's not going to work now.
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.
Isn't that what you would want if you're opening an untrusted codebase?
No, I want syntax highlighting.
In the past, editors could give me syntax highlighting without opening me to vulnerabilities.
1 reply →
> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
loss of syntax highlighting and to a lesser extent the neovim plugin. maybe having some kind of more granular permission system or a whitelist is the answer here.
opening a folder in vscode shouldn't be dangerous.
> opening a folder in vscode shouldn't be dangerous.
You're not "opening a folder" though, you're opening a codebase in an IDE, with all the integrations and automations that implies, including running code.
As a developer it's important to understand the context in which you're operating.
If you just want to "open a folder" and browse the contents, that's literally what Restricted mode is for. What you're asking to do is already there.
I've been using VS Code for many years and I try pretty hard to be a security aware dev.
I checkout all code projects into ~/projects. I don't recall ever seeing a trust/restricted dialogue box. But, I'm guessing, at some point in the distant past, I whitelisted that folder and everything under it.
I've only just now, reading through this thread, realized how problematic that is. :o/
Syntax highlighting should work if the highlighting is provided by a textmate grammar, it will not work if it's semantic highlighting provided by an extension and that extension requires workspace trust. If it's possible to highlight without executing code, that sounds like an extension issue for whatever language it is. I believe extensions are able to declare whether they should activate without workspace trust and also to query the workspace trust state at runtime.