4 ms·
There's been lots of discussion about blockchains, webs of trust, trusted reviews, small[0] fees and a host of other ideas to address npm package spam. I'll th
by nobody9999 4y ago
There's been lots of discussion about blockchains, webs of trust, trusted reviews, small[0] fees and a host of other ideas to address npm package spam.
I'll throw out another one: create an automated testing process for uploaded NPMs, such testing to be performed before allowing the new "package" to be visible to others.
If the testing process can't find any code or if it really is a real package, but can't be successfully tested, the upload can be rejected with (or without for obvious spam) an email to the "developer" letting them know their code doesn't work and won't be visible to the world until they fix their bugs.
The devil is, of course, in the details. I'm sure there are many edge cases and special circumstances that will likely require manual intervention, but I'd expect that such a solution would cover the vast majority of "spam" packages, with the added benefit of not allowing broken code on the site either.
Perhaps (likely even) there are other, better ways to handle this issue, but this idea would, presumably, significantly reduce the spam issue without negatively impacting honest/real developers.
Just a crazy thought.
[0] "Small" is relative, as a bunch of folks have pointed out.
- lenzm 4y agoThis seems like an arms race doomed to failure. The spammers can just add Hello World to pass the check. Then the check could be upgraded to look for some non-trivial behavior. Then the spammers will work around that. ... all at increasing costs to the package hosts. And now they have to be arbiters on what counts as trivial functionality.
- nobody9999 4y ago>This seems like an arms race doomed to failure. The spammers can just add Hello World to pass the check. Then the check could be upgraded to look for some non-trivial behavior. Then the spammers will work around that. ... all at increasing costs to the package hosts. And now they have to be arbiters on what counts as trivial functionality. IIUC, most of these spam "packages" don't have any code at all, just a README with links to whatever malicious sites they want folks to visit. As such, don't assume that just because someone uploads a spam package actually knows how to code anything, especially since it appears that such spam packages are uploaded not to scam Node devs, but to use the good reputation of npmjs.com to host their spammy content. Getting rid of that stuff is the low-hanging fruit. And I would not be at all surprised if almost all of these these folks couldn't code anything useful or worthwhile in Node or any other language. It's highly unlikely that most of the folks uploading these spam packages are node devs, or devs of any kind. As such, most of these folks wouldn't be able to participate in an "arms race." And while some tiny fraction of those folks might be an enterprising spammer who writes an actual npm package. The problem with that, of course, is that it's quite likely that it's just a small number of folks who are uploading dozens (hundreds?) of these "packages," forcing them to either reuse the code over and over again (which is fairly easy to spot) or to actually develop new code for each package. And that's way too resource intensive for scammers. If they were folks who had skills, decent work ethic and/or an interest in anything other than running their scams, they wouldn't be posting fake (i.e., just an empty package with a README) packages in an attempt to use npmjs.com to host their crap. I mean, I get it. Perhaps you made the assumption that these folks are actually devs? Since they're using the site -- but IIUC, there's no proof that's the case -- at least for the specific empty packages I referenced above. Edit: Clarified my thoughts.