[acdha]

That doesn’t make sense: it’s like arguing that it wasn’t useful to have boat design switch to compartmentalization in addition to trying to avoid hitting things. You can spend a lot of effort trying to ensure bad code never arrives but unless that’s perfect you also want to think about how to make it less catastrophic.

[felixgallo]

the proposed idea does not reduce the attack surface or make anything easier or less catastrophic.

[acdha]

You might want to reread more carefully. Using the OS security features to restrict what the code you just installed can do prevents immediate attacks and gives you a chance to notice suspicious activity. If the only way to read a file is for the package to request permission and a scope, that gives you a chance to notice it (huh, why does tiny-color need ~/.GitHub?) and also serves as a triage cue for scanning pipelines to flag updates, especially minor ones, which increase the scope of the requested permissions.

Using OS features to restrict access to sensitive data similarly gives you another chance to detect a compromise because a denied operation to, say, read your wallet by an app which doesn’t need to is both highly visible and unambiguous.

[felixgallo]

I can read, thank you. The specific problems are that your 'prevent immediate attacks' and 'gives you a chance' are both doing significantly more work than you'd like to admit. A large project can use hundreds of npm packages, with the total dependency tree in the thousands. Your choices are to either give them infinite dialog fatigue on every single npm update, or make security-weakening tradeoffs. And if you ever let any of the packages create a new window and draw to it, that's game over. Even without malicious dialogs, users will continue to make bad choices, and 99.9% of all non-developer users and 99.8% of all developer users will accept or even broaden insecure defaults when prompted.

The problem is coming from inside the house.