Comment by whizzter
4 days ago
Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies).
As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Win9x and tried to maintain compatiblity for users over security up until it became untenable. So yes, the base _was_ bad when Windows was dominant but it's far less bad today (why people target high value targets via NPM,etc since it's an easier entry-point).
Android/iOS is young enough that they did have plenty of hindsight when it comes to security and could make better decisions (Remember that MS tried to move to UWP/Appx distribution but the ecosystem was too reliant on newer features for it to displace the regular ecosystem).
Remember that we've had plenty of annoyed discourse about "Apple locking down computers" here and on other tech forums when they've pushed notarization.
I guess my point is that, people love to bash on MS but at the same time complain about how security is affecting their "freedoms" when it comes to other systems (and partly MS), MS is better at the basics today than they were 20-25 years ago and we should be happy about that.
This comment seems to address users intentionally installing malware. I mean to address cracking, the situation where an attacker gains root or installs software that the user does not know about.
Preventing the user from installing something that they want to install is another issue completely. I'm hesitant to call it exactly security, though I agree that it falls under the auspices of security.
Cracking is a term related to removing copy-protections. Rooting or privilege escalation is better terms for what you're mentioning.
As for "users intentionally installing malware", Windows in the early 00s had a bunch of fundamentally insecure deployment models like ActiveX controls and browsers (IE especially) were more or less swiss cheese in terms of security even outside the ActiveX controls.
Visiting the wrong webpage was often enough to get crap on your computer.
My view is that once you have bad native code running on your computer there's a large chance that it's game-over (the modern sandboxes like WASM were designed to enforce a probably safe subset where regular kernel mistakes are shielded by another layer of abstraction that needs to be broken).
Even Linux has had privilege escalations every year as far as I know. Notarization/stores is just a way to try to keep check on what code runs on end-user computers that isn't sandboxed (and allow for revoking that code if found to be malicious), maybe Linux is slightly safer still but that's probably due to less older features in the Kernel, but Windows has for example recently gotten a rewritten font-parser in Rust (the previous font parser was a common exploitation point that was placed with a too high privilegie).
You can have security without having a walled garden. By trusting the user with the key of their own property.
You mean like the developers holding the npm-publishing keys that just allowed a worm to spread?
No. By NPM not allowing any package to run code on the developer's machine. I can trust npm (the software), but not the library. It's a very weird choice to just allow any package to run post install script. Especially when there's little to none verification done on npmjs side.
Developers can feel free to not secure their computer or sell their keys. But that not means npm should allow straight code push from their computers to everyone that has downloaded their library.
> Compared to the JS ecosystem and number of users both Python and Rust are puny
This is just plainly false in case of Python.
> also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies).
Rust is already "native" so Cargo doesn't need to do anything.
Python has the logic to do native builds baked into pip and friends, so a Python package can just specify what to build in the manifest. But it also allows for precompiled wheels, and most popular packages do them for all major OSes, so users rarely need to actually build stuff in practice.