Total anecdata but I don't appreciate the nag screen every time I've opened repos that I have either authored or contributed heavily to... I default to "yes I accept in this directory and all directories" which seems very sketchy in general, but is the easiest for me to get my work done.
Which is kind of ridiculous because .zshrc isn't a workspace. My understanding of this feature was to calm fears of untrusted code running due to some configuration in .vscode configurations or with plugins.
Basically the files and folders are usually innocuous, it's the particular configuration of the workspace or plugins that may run code on them that need to be "trusted" or designed to request permission before executing code
Ah, the classic tug of war continues between the principle of least privilege and convenience/productivity. It's safe to say people's opinions are all over the spectrum.
Despite favoring "least privilege" myself, I find the new nag screens overbearing. I think some basic UI reworking can help to alleviate that, though. It's a new feature; they'll get it right within a couple of iterations.
There is a third approach, which is both safe and convenient, but unfortunately it's not universal and well supported on modern systems - segregation. The vast majority of applications don't actually need access to your operating system. My entire development environment for each project I work on could run in its own container or even VM and I'd simply connect my interface into it.
Builds, tests and the app itself could easily run inside a container - web apps can simply expose a TCP port and GUI apps can use X forwarding or the platform equivalent. Other programs that need external devices (like a serial connection to an MCU) could have those and only those passed in.
And if we're even more paranoid and worried about code exploiting our editor and tools, the editor could also be just a simple thin client with all the linters, language servers and everything else running in the container. For VS Code, this already exists for cloud development services (Che, etc.).
Based on the first four comments, I see some do not appreciate this unlike me, at least. Just last-night, I was forced to download a zipped folder with source code from a site I was new to. Well, I did appreciate using this new feature because I wasn't sure what I of the 'trustworthiness' of the folder.
It is the same approach to defend off phishing attacks in large corporations: shift the responsibility to the user.
In my opinion, this is just another scream for codified capabilities. Which would be a real solution and not just repeatedly a click away from disaster.
> Now, I'm sure many of you will agree, VS Code suffers from a bit of what we call "Notification Fatigue"
Yup.
I love VS Code but the sheer amount of chatty notifications especially when browsing a large code base can be simply overwhelming. I just start reflexively ignoring them. There’s no “just shut up already and let me work” button.
I’m glad this is something they are working on improving.
Being verbose isn't bad, but VS Code is actively spammy. "Hey, this extension just updated, want to read the changelog?", "hey, we've added this new feature", "hey, want to star our extensions on github?"... It's like WordPress plugins all over again.
Yeah I think people really underestimate how massive of a security liability node modules are in the way the system currently works.
Fixing it should really be given top priority, but doesn't look to be a very popular subject when you compare it to some of the others such as whether or not ESLint should become a NodeJS core module ...
NPM is one of the most dangerous implementations, but the whole concept of pulling in thousands of unknown dependencies is dangerous on its own, even in other languages.