Live data from Hacker News

70% of new NPM packages in last 6 months were spam

blog.phylum.io

71–80 of 116 posts

Re: 70% of new NPM packages in last 6 months were spam

#71
post #13

Why are these spam accounts not perma banned and removed? For example, this[1] account mentioned in the article has 1781 packages of gibberish. Also, the whole reporting process is onerous, there is a large form. Of course, gatekeeping on reporting is good, but there should be a possibility to report an entire profile of package publisher. [1] https://www.npmjs.com/~eleanorecrockets

Isn't it better to leave accounts that correlate spam than to force spammers to obscure the connection by creating a new account for each piece of spam?

That primarily works if you can shadow ban the account. Otherwise the spam is still negatively impacting the community (ex. By polluting search results).

Re: 70% of new NPM packages in last 6 months were spam

#72

Earlier quoted context omitted.

We can empirically observe that NPM-sphere is relatively alone among software ecosystems to have this particular problem. This is an indication that the problem is either with some facet of NPM itself, javascript the language or js programmers, as that is what distinguishes the ecosystem from e.g. Maven or Pip that do not suffer from the same problems, at least not to the same extent. However, going from this observa…

You're doing it again, though: are "this particular problem" and "these problems" the tea.yaml spam? The million tiny packages problem I mentioned? The fact that people online will generically attack the ecosystem without being specific about their complaints? I'm not asking for solutions, and I'm not asking for people to identify casual factors. I'm asking for people to put a little bit more effort into their critic…

A lot of people have already been very specific in many other threads -- "the JS ecosystem has way too many and way too small packages and there's zero curation".

Not sure what your seemingly intended moderation is supposed to achieve but the complaints towards the JS ecosystem have been very clear for no less than 10 years.

Re: 70% of new NPM packages in last 6 months were spam

#73
post #65

Earlier quoted context omitted.

The Lpad fiasco was pretty bad, being able to delete libraries used by so many people. Hard to forget that.

Which, incidentally, some people seem to have forgotten when suggesting that NPM should start deleting things en masse.

What other outcome than "curation" do you see as a solution of the "bloat" problem?

Re: 70% of new NPM packages in last 6 months were spam

#74
post #24
post #8

How about removing the incentive? Take down every package with tea.yaml in it, after say 1 month's warning, so legitimate packages trying to use it don't leave their users in the lurch. The tea protocol is clearly not going to accomplish what it set out to (see below), and is instead incentivising malicious behaviour and damaging the system it set out to support. From https://docs.tea.xyz/tea/i-want-to.../faqs : "tea…

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never meant anything. A proper response needs to not break expectations like this. [0]: https://docs.npmjs.com/policies/unpublish

[flagged]

Re: 70% of new NPM packages in last 6 months were spam

#75

Earlier quoted context omitted.

I am not sure I am following that this fits the broken window fallacy? That fallacy is 'if I break/destroy something I create value on other things'. I am actually curious how spamming a bunch of accounts with junk in them would fit that? Oh no doubt it is creating negative value but nothing is destroyed to do that. 'Broken window' is probably not the right pattern here? I can think of a couple of other terms that fi…

I think you are making a confusion about what's the broken windows theory, I suggest reading about it: https://en.wikipedia.org/wiki/Broken_windows_theory

The other commenter was actually just mixing it up with the broken windows fallacy[0]. Funnily enough, it's a common enough confusion that both of the pages reference each other at the top of the page.

>This article is about the economic parable. For the criminological theory, see Broken windows theory.

[0] https://en.wikipedia.org/wiki/Parable_of_the_broken_window

Re: 70% of new NPM packages in last 6 months were spam

#76

Earlier quoted context omitted.

Principles are a means to an end, not an end in themselves. The end here (presumably) is a healthy ecosystem, an end which this principle arguably harms more than it helps. Rigid and unthinking adherence to principles is dogmatic, and dogma has no place in engineering.

> The end here (presumably) is a healthy ecosystem More specifically, the end here is a package manager that doesn't randomly start break your builds because a dependency you need can just vanish from the main servers or lose files you expected to be there. That may or may not contribute to a healthy ecosystem, but it definitely contributes to widespread usage of npm.

No, that is but one condition of the end, but not the whole of the end.

A system is all the parts it requires to continue to exist. Widespread usage of NPM will collapse if everything on it is hot dangerous garbage that infects your CI-CD/dev box with something when you type a wrong character. There are multiple dimensions to trust. Is the package I'm using going to disappear is one. Is the package I'm using a virus is another. Is the entire NPM ecosystem going to collapse under the weight of controlled growth and hosting costs leaving me with nothing is yet another.

You need to back up and look at the whole elephant.

Re: 70% of new NPM packages in last 6 months were spam

#77

Earlier quoted context omitted.

I know it's a meme on HN to rant about the terrible JavaScript ecosystem and how bad JS developers are, but I would ask that if you're going to do it you be specific about what you mean instead of just generally accusing it of being "bad". It's not even that I disagree, it's that it's a conversation killer. "The JS ecosystem is bad" has no response someone could make besides "no it's not", which is boring. "The JS ec…

We can empirically observe that NPM-sphere is relatively alone among software ecosystems to have this particular problem. This is an indication that the problem is either with some facet of NPM itself, javascript the language or js programmers, as that is what distinguishes the ecosystem from e.g. Maven or Pip that do not suffer from the same problems, at least not to the same extent. However, going from this observa…

and then there's go, wherein you simply don't import anything outside of the stdlib. a stoic and rather perfect immunity to this nonsense

Re: 70% of new NPM packages in last 6 months were spam

#78
post #24
post #8

How about removing the incentive? Take down every package with tea.yaml in it, after say 1 month's warning, so legitimate packages trying to use it don't leave their users in the lurch. The tea protocol is clearly not going to accomplish what it set out to (see below), and is instead incentivising malicious behaviour and damaging the system it set out to support. From https://docs.tea.xyz/tea/i-want-to.../faqs : "tea…

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never meant anything. A proper response needs to not break expectations like this. [0]: https://docs.npmjs.com/policies/unpublish

No, it isn't?

The unpublish document describes the options that users of NPM have to remove packages themselves. It was created after some situation where someone unpublished an important package.

A whole different set of terms governs which packages NPM can remove. This definitely includes these packages, either as "abusive" or "name squatting"

Not only that, but NPM's TOS makes it very clear that you have no recourse if they decide to remove your package for any reason.

Re: 70% of new NPM packages in last 6 months were spam

#79

Earlier quoted context omitted.

I know it's a meme on HN to rant about the terrible JavaScript ecosystem and how bad JS developers are, but I would ask that if you're going to do it you be specific about what you mean instead of just generally accusing it of being "bad". It's not even that I disagree, it's that it's a conversation killer. "The JS ecosystem is bad" has no response someone could make besides "no it's not", which is boring. "The JS ec…

> The JS ecosystem encourages using a million tiny unmaintained packages and that is bad continuing on this, I wonder if this is a cultural thing or if there are actual technical choices made in NPM that play a role. Could NPM change something in their package management to change this? Should they?

it's language-cultural. to "publish a package" in Go simply means having a public git repository. and yet, nobody who writes Go imports packages. it's well-understood that if you can't write something like leftpad (or many other JS packages) yourself in your own codebase in a few lines, you're an absolute nonce. Javascript developers on the other hand tend to skew towards the juniors in our broader ecosystem, and they seek easy and quick prestige, which leads to "star farming"/"download farming"

Re: 70% of new NPM packages in last 6 months were spam

#80
post #2

> Contrary to what npm states, this package actually depends on one of our aforementioned spam packages. This is a by-product of how npm handles and displays dependencies to users on its website. For me personally, this is the biggest surprise and takeaway here. By simply having a key inside package.json's dependencies reference an existing NPM package, the NPM website links it up and counts it as a dependency, regar…

And worse, it shows axios, and links to the actual axios package.

https://www.npmjs.com/package/sournoise?activeTab=dependenci...

If it would show axios and link to the package provided in package.json, that at least would be better.

But here they actually link to the wrong package.

Post reply on HN