Live data from Hacker News

50% of new NPM packages are spam

blog.sandworm.dev

201–210 of 325 posts

Re: 50% of new NPM packages are spam

#201

Earlier quoted context omitted.

This is basically what I was doing in the 80s and 90s, downloading compressed tarballs from ftp sites and compiling them. It takes quite a longer developer time than the package manager approach. That includes the time to learn which sites you can trust (probably none today) and which dependencies to use (usually listed in the README.) Furthermore there would be a big incentive to use very few libraries: this is both…

The registry-less dependency management is how Go works today, and doesn't have those problems. It's even less developer time than NPM. 1. No need to spend time publishing, just push a commit 2. No need to `npm i` or edit a file, modules can be inferred from imports because they use FQDN

Indeed, Golang really got this right.

Re: 50% of new NPM packages are spam

#202
post #61

Was the joke creating JavaScript frameworks is way to get promoted in FANG / MANGA..

I related this "story" elsewhere, but in another context is good too.

So, when I was younger, I used to frequent DEMF, the Detroit Electronic Music Festival. It's now called Movement or whatever.

It was a great time. And one of the favorite feel good moments was seeing Grandma Techno there: https://mixmag.net/feature/grandma-techno-shares-her-love

Looking back, this view might have been kind of ageist. It shouldn't be that surprising or weird to have older people there. Elders in the tribe. But at the time it was also just a happy recurring image during the event.

We were taught to love this woman through informal network stories and "whispers". Everybody had that friend who pointed her out pridefully, and maybe you became that friend pointing her out to another.

I can imagine another world where seeing Grandma Techno dancing among the younglings is creepy. At least make her wear a VR headset when she's within 1000 feet of the festival. It's nothing personal, it's just nature.

She has a book now. Whether that's because she wanted that sweet "FAANG" publishing deal or liked contributing to the scene. Well... who cares... both benefit us.

Fortunately, we were taught to accept people through informal support networks of friends.

Same goes with npm and cargo.

Yeah, this story seems disjointed and out-of-place. But it's important. And I'm naive, but I'd rather have an orderly migration to social and technical controls for packaging than drama. And I can still respect the people who want some other solution.

Because I'm that fucking old person now.

Re: 50% of new NPM packages are spam

#203
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.

Re: 50% of new NPM packages are spam

#204

I'm afraid it can get worse. What happens when there will be a proliferation of "looking legit npm packages" thanks to AI, full with ransomware? Currently I can't really figure out a one size fits all solution to that. Any idea?

Deno’s model where code needs explicit permissions to use the network and file system is a good first step.

It is very hard to turn a black box function into something that can be used reliably. Network and filesystem permissions are baby steps that only prevent genuine developer mistakes, not malicious attacks.

The PDF converter library you're using might not need filesystem or network access, but it can detect specific text in links and replace the URL with a phishing site. There are no technical shortcuts to trust.

You can sandbox all you want, use three layers of VMs and what not, but if you're allowing me to produce bytes for you and then expect to use them elsewhere in any nontrivial way, I've already won.

Re: 50% of new NPM packages are spam

#205

I was expecting this article to be a promotion of their audit tool considering a thread about it was flagged as spam less than two weeks ago[1] Turns out it indeed is. Interesting article nonetheless, but it's quite ironic that it's about spam [1] https://news.ycombinator.com/item?id=35233877

Hmm. I found this article informative. I suppose it did mention their service, but only toward the end. Even then, it wasn’t like “Buy now for 50% off!!!” So on balance, I am glad they posted.

Re: 50% of new NPM packages are spam

#206
post #25
post #19

Earlier quoted context omitted.

Are people who submit to NPM really that short on cash? I doubt it.

A lot of counties (like mine) don't have access to global payments. Having a card in Euro or USD requires special paperwork.

Do you mind if I ask what country?

Re: 50% of new NPM packages are spam

#207

Earlier quoted context omitted.

One of the first proposals for blockchain was a email with a minuscule, verifiable fee to make email spam uneconomical. Spamming emails is one of the cheapest things you can do with a network connection. Even $1 per 1,000 emails would make spam untenable.

And the first proposal for proof-of-work was having emails include a proof-of-work to make it computationally expensive to mass-send emails.

I'd rather have my ISP donate 0,1 cent to some national park foundation when I send an email or whatever than have me waste power though.

Re: 50% of new NPM packages are spam

#209

Earlier quoted context omitted.

I think the suggestion was that the revenue generated by NPM's commercial dealings should cover any cost associated with a review process for OSS submissions (which in itself would make such spam repositories ineffective)

So, let the spam happen, and remove it after the fact using humans? Or hold all submissions until a human reviews it?

I'm just clarifying my interpretation of OP's comment, not necessarily agreeing with it.

Anyway, involving humans (funded by NPM's commercial revenue) doesn't reduce the options to "letting the spam happen and dealing it after the fact" or "holding all submissions until a human reviews [them]".

If I was trying to solve this problem, I'd be open to a solution that tried to automatically classify submissions as either legitimate or spammy, with an associated confidence level. If the confidence level fell below a given threshold then I'd involve a human.

Re: 50% of new NPM packages are spam

#210
When I did a coding boot camp, one of our assignments was to push a package to RubyGems. It didn't matter if the package did anything; just make up a name and publish it. I'm pretty sure this kind of thing was a common practice with other boot camps, and applied to NPM as well. I always despised how this effectively trashes the repository and represents a complete waste of digital space, no matter how insignificant, as well as take up names that could go towards code that is actually useful. I wouldn't be surprised if a significant number of spam NPM packages were these boot camp assignments.
Post reply on HN