I agree... You could argue the same with security:
I can create an exploit in an npm package -> everyone does -> npm is fundamentally unsafe.
That is kind of true, but no one stops using npm for this reason. I guess the same goes for every metric. Who guarantees you that a project github stars dont come from a clickfarm ?
When using a npm package, you're trusting its author, to some extend.
(This is fun to see that npm doesnt even try to protect itself against this, though)
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
That's not what the post is getting at (to my reading). The equivalent would be, I think:
There happens to be wild fluctuations in the number of exploits accidentally appearing in npm packages due to cosmic rays -> I can demonstrate getting an exploit into an hyperbolic number of npm packages to prove a point -> npm is fundamentally unsafe.
It's talking about how the metric is useless even in telling you how many unique users downloaded a package, or how often something caches it or runs a build job.
You don't need a significant portion to spoof for the metric to be useless.
Let's say you need a package, you go look at exxpress. It has 30M downloads, therefore it's probably the popular package you wanted. So you're good to go with npm install exxpress right?
I don't get the logic here
Your argument is based on your exploit, which makes an illogical jump
I can spoof downloads -> Everyone spoofs -> the metric cannot be trusted
Unless you can proof a significant portion of users spoof (like in appstore reviews), then the argument is moot
I agree... You could argue the same with security:
I can create an exploit in an npm package -> everyone does -> npm is fundamentally unsafe.
That is kind of true, but no one stops using npm for this reason. I guess the same goes for every metric. Who guarantees you that a project github stars dont come from a clickfarm ?
When using a npm package, you're trusting its author, to some extend.
(This is fun to see that npm doesnt even try to protect itself against this, though)
That's not what the post is getting at (to my reading). The equivalent would be, I think:
There happens to be wild fluctuations in the number of exploits accidentally appearing in npm packages due to cosmic rays -> I can demonstrate getting an exploit into an hyperbolic number of npm packages to prove a point -> npm is fundamentally unsafe.
It's talking about how the metric is useless even in telling you how many unique users downloaded a package, or how often something caches it or runs a build job.
You don't need a significant portion to spoof for the metric to be useless.
Let's say you need a package, you go look at exxpress. It has 30M downloads, therefore it's probably the popular package you wanted. So you're good to go with
npm install exxpressright?Sorry if I've made this unclear, there are two main points I'm trying to emphasise. Just in case you missed it 👇
In terms of the exploit side of things, my personal opinion is that data which can be manipulated to this degree shouldn't be given any weight.
Edit: I've updated the conclusion to remove the emphasis on the latter point - hope that clears up any confusion!