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?
70% of new NPM packages in last 6 months were spam
71–80 of 116 posts
Re: 70% of new NPM packages in last 6 months were spam
#72Earlier 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…
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
#73Earlier 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.
Re: 70% of new NPM packages in last 6 months were spam
#74How 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
Re: 70% of new NPM packages in last 6 months were spam
#75Earlier 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
>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
#76Earlier 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.
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
#77Earlier 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…
Re: 70% of new NPM packages in last 6 months were spam
#78How 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
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
#79Earlier 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?
Re: 70% of new NPM packages in last 6 months were spam
#80> 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…
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.