[ivraatiems]

> The problem isn't that "well-meaning members of the community" decided to upload packages. The problem is that when their system decides that a package shouldn't be up it completely removes the package, as if it never existed, and allows the namespace to be reused immediately. Those "well-meaning members" should not even be able to hijack packages this way, as it means the people who aren't "well-meaning" can also do it.

Hasn't this been an ongoing issue with npm since pretty much its inception? I remember reading articles about this vulnerability and the hijacking of packages that were taken down temporarily years ago.

How has this not been dealt with systematically yet?

[tedivm]

Yeah, about two years ago NPM stole a package name from an existing user and gave it to a company to use. The user then said that if he can't trust NPM to actually treat package naming fairly then he was just going to delete all of his packages[1]. This broke a ton of packages on people (in part due to "left-pad" disappearing), so the community went ahead and registered/uploaded all of the packages to NPM again.

Afterwords NPM came out with a blog post[2] where they went out of their way to take as little blame as possible and basically said it was the developers fault. They said they "stand by [their] package name dispute resolution policy, and the decision to which it led"- basically ensuring that no developer should ever trust their repository in the long term, as they'll happily hand over any package name to a corporate entity if that entity asks for it.

The weird thing is that they claimed to make it impossible to "unpublish" packages, so that developers could no longer rage quit their site, but apparently they didn't extend that new requirement to their own "security" systems.

[1] http://azer.bike/journal/i-ve-just-liberated-my-modules/ [2] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

[ivraatiems]

This is exactly the incident I was thinking of, thank you.

It is bizarre that npm hasn't resolved these kinds of situations by now. Makes me glad I've continued to stay away from that ecosystem.

[Dylan16807]

I don't think the dispute resolution process makes them untrustworthy. It's an annoyance. It's the unpublishing that's a huge security flaw vector, and the fact that they didn't actually fix what they claimed is pretty bad.

[tedivm]

To me it's a trust issue. Their dispute policy breaks trust in two ways-

1. As a developer I can not know with certainty that a package I publish will remain published under its current name.

2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better.

What you say is also a problem. The fact that they claimed to have solved the unpublishing problem when they apparently hadn't is pretty huge, as is the fact that the flaw exists to begin with. Unfortunately NPM is just not a trustworthy company.

[djsumdog]

I agree as well. The guy published his kik package well before Kik was even a company. There was no reason for the npm team to resolve the situation they way they did. If someone already owns your Twitter ID or Facebook page name, well they're closed private services. Same if someone buy's your domain name (see the case of Nissan).

You don't have a right to a name on every service on the planet just because you trademark it somehow.

[allover]

> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name.

You can as long as your package name isn't trademarked or likely to confuse users installing the package.

> 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better.

I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. When they handed over 'kik' it wasn't in the same league as 'left-pad' which was widely depended upon.

> What you say is also a problem. The fact that they claimed to have solved the unpublishing problem when they apparently hadn't is pretty huge

I agree it sucks, but the fact is they 'prevented unpublishing' to bug-fix one vector for this problem, but then introduced a bug in process that appears very similar to unpublishing. If you've never had this sort of thing happen to you as a software dev, (had some stakeholder question 'but I thought you'd fixed X') you're very very lucky.

> as is the fact that the flaw exists to begin with.

Easy to criticise in hindsight. At the time of left-pad, several other package registries (e.g. PyPI) also allowed unpublishing.

[dozzie]

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name.

> You can as long as your package name isn't trademarked or likely to confuse users installing the package.

Trademarked where exactly? You know, there's quite a lot of world beside US.

> I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity.

What makes you trust them in this matter? They haven't displayed such behaviour, and their behaviour up until now slightly suggests the opposite.

[bigiain]

>>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name.

>> You can as long as your package name isn't trademarked or likely to confuse users installing the package.

> Trademarked where exactly? You know, there's quite a lot of world beside US.

And, if I recall correctly, trademarked when? Wasn't leftpad.js's author using the name kik well before the company Kik existed? So you don't just need a name that's not trademarked _now_, you need to pick one that no-one else trademarks sometime in the future (in whatever jurisdictions the npm people care about)...

[allover]

> and their behaviour up until now slightly suggests the opposite.

Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name.

[1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

[kevin_thibedeau]

Trademarks only apply within a common industry. Kik the company isn't in the business of creating NPM packages. It's perfectly legal to use the same name for something unrelated to messaging even after the founding date of the commercial entity.

[allover]

I'm not arguing what's legal. If your package name is a trademark, thinking you're entitled to hang on to it is naive. This is well understand with domains, so why do you think a package registry should be different?

[5h]

Just had a quick look - the "kik" package isn't in even use anymore - the whole thing was just drama theatre from by a messaging app I've never heard of. Despite it having 200 million users. Apparently.

[mherdeg]

> a messaging app I've never heard of. Despite it having 200 million users. Apparently.

Yeah it's tough for me to keep track of which apps are/aren't significant because I'm not in the loop with every community out there.

I'm guessing the users are distributed among small pockets in a network of people who all know each other -- like how in the 1990s there were pockets of "MSN Messenger" and pockets of "Yahoo Instant Messenger" and pockets of "AOL Instant Messenger" users randomly scattered around various schools. OR like how Orkut grew so precipitously in Brazil.

Or it's a generational thing -- I think there is a certain age group of people in the US who used Yik Yak, another who uses tbh and co, and so on.

I would generally trust Facebook employees to tell me which apps are "real" / growing since they have Onavo surveillance and other sources (https://www.wsj.com/articles/facebooks-onavo-gives-social-me...). But aside from those data, I'm not sure how else to keep track of which apps are "real" / big.

[erk__]

Kik is mostly popular outside the west, it is pretty popular in South East Asia.

[olefoo]

In the US Kik has a pretty active userbase; but it's demographics skew older, poorer and more female and more rural. So that might be why you haven't heard of it.

[wutbrodo]

Are you sure? This wasn't my impression and what I'm seeing from a quick Google is pretty different on multiple counts:

"Quite surprisingly, close to 70% of Kik’s users are men. It is most popular among young men between ages 20-24. Vine and Flickr are popular among men too, though their users tend to be a little older: 25-29 and 35-39, respectively. Not so surprisingly, Instagram and Pinterest are more popular among women than men. Women also prefer Facebook Messenger over WhatsApp and Kik"

http://www.vertoanalytics.com/the-demographics-of-social-med...

[amyjess]

Kik is pretty popular among camgirls. Usually paying for a subscription to them gets you added to their contents on Kik so you can chat with them.

I wouldn't associate that with older, rural people. More female, sure... but then you've also got their male followers.

[dannyw]

Older?! Kik’s demographic is far younger than anything.

[amyjess]

I hope this leads more developers to begin using restrictive trademark terms for their work, like Mozilla does with their software (e.g. you cannot fork Firefox and still call it "Firefox") or what Tuomo Valkonen did with ion3.

And for that matter, this sounds like a pretty strong disincentive for developers to make their code open-source at all. I'd rather just release proprietary software under a license that allows me to revoke individual entities' ability to distribute my work on a whim to prevent something like this from happening. And I mentioned Tuomo above for a reason--his experiences with ion3 and dealing with the open-source community drove him to a similar decision, and he quit writing open-source software and developing for Linux as a result. By the time he quit, he had become an active opponent of free software.

[_pmf_]

IIRC, Tuomo was also dissatisfied with the state of Linux on the desktop in general.

[amyjess]

A huge chunk of that was that he was fed up with stable distributions shipping older versions of his software, so he'd get inundated by bug reports from users who were reporting things he'd already fixed. He argued that distros like Debian Stable and RHEL were actually more prone to bugs because of this. He wanted distros to use either rolling release or the Microsoft/Apple model, where the OS vendor only ships the base OS and all other software is acquired from third parties.

Because of this, he ended up putting in a termination clause in his license:

> 3. Redistributions of this software accessible plainly with a name

> of this software ("ion", "ion3", etc.), must provide the latest

> release with a reasonable delay from its release (normally 28 days).

> Older releases may be distributed, if the full version, or some

> other explicit indicator, such as the word "ancient", is part of

> the name that the package is accessed with, or if this identifier

> is completely unrelated to a name of this software.