Hacker News Reader

Comment by profmonocle | Hacker News Reader

> And... I kind of want to say "once it's published, it's forever".

This is effectively the norm with more traditional, curated package managers. Say I release a piece of open source software, and some Linux distro adds it to their package manager. Under a typical open source license, I have no legal right to ask them to stop distributing it. They can just say "sorry, you licensed this code to us under X license and we're distributing it under those terms. Removing it would break our users' systems, so we won't do it."

The difference is that NPM is self-service - publishers add packages themselves, and NPM has chosen to also provide a self-service option to remove packages. I honestly wouldn't have a problem with them removing that option, and only allowing packages to be removed by contacting support with a good reason. (Accidental private info disclosure, copyright violation, severe security bug, etc.)

View on HN

  I honestly wouldn't have a problem with them removing that option, and only
  allowing packages to be removed by contacting support with a good reason.
  (Accidental private info disclosure, copyright violation, severe security 
  bug, etc.)

Even Rust's Cargo won't allow you to revoke secrets [1]. I think this is the correct policy.

[1] http://doc.crates.io/crates-io.html#cargo-yank

Aside from secrets there is also sensitive data. If someone accidentally uploads some personal information, they need a way to remove it if, say, they receive a court order ordering them to remove it.

I'm not sure how the court could force you to do something you can't possibly do...

They would force the provider to facilitate the removal.

"So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct." "You're being honest with me." "Yes, your Honor." "Will the computers continue harming the plaintiff's interests if shut off?" "... That would be dreadfully inconvenient, your Honor." "Do you have a more convenient solution?" "No, your Honor." "You are hereby ordered to turn off your computers in 48 hours." "... You can't do that." "I can do a lot of things, including jailing you if you disobey my lawful authority. 48 hours."

Engineers often think that they are the first people in history to have thought "Hey, wouldn't it be easy to pull one over on the legal system?" This is, in fact, quite routine. The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

How about a blockchain-based NPM? Can't take all the computers down.

Legal, shmegal.

Yep, but someone should implement that first. Package repositories have pretty much centralized control still, and will have for foreseeable future.

You can still be jailed for contempt of the order, though.

"I've found a clever workaround for court orders" doesn't work around that bit.

OK, now tell me how you can remove this file from BitTorrent (it's Fedora 18 KDE)

magnet:?xt=urn:btih:14f146cdfaef83951ca9d3ac647e18e1977d1367

I'll wait

It's not about whether the removal is logistically possible, it's about whether a court can punish someone for failing to carry out the removal.

Even when the former is actually impossible, a court could still punish for the latter. "Ha ha ha I use technology to cleverly show how futile your orders are" is not the kind of thing you want to say to a court with broad contempt powers.

If the "forbidden" action was previous to proceedings and carried out in good faith by unknown parties, it would be very hard to sanction anyone.

The court can't punish you for not being able to do the impossible. That's ludicrous. "We have shut down all of our servers, yes. We can't stop people from downloading this, no"

Pay damages, then.

Pay damages because someone else uploaded something by accident and you can't fix it? It doesn't work like that.

It only doesn't work like that in the context of safe harbor laws.

If the safe harbor law protection doesn't apply, and the defendant is responsible for the illegal behavior, the defendant can absolutely be held legally liable and pay the legally-appropriate punishment.

Why should you pay the damages for something that's not on your server?

That's because all laws make sense and all people who enforce and judge them are understand this.

that's why we'll kurtzweill ourselves into the computers that can't be shut down!

Would that work if you did it before the court order?

No.

Just live outside of the United States, and you'll be fine.

Yeah, there's literally no other courts outside the USA.

Yeah, because the US doesn't have treaties with most of the world...

Or something like http://ipfs.io/

IFPS is cool, however pretty far away from being usable as a package management system... Some package management system could use it as a backend, though.

In fact, gx[0] is such a package management system.

[0]: https://github.com/whyrusleeping/gx

Huh NPM already handles git?

http://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdX...

npm already replicates to hundreds of other servers. Right now, it is practically infeasible to actually remove packages permanently.

> The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

In other words, Hulk Hogan vs Gawker.

What Patrick says is technically true. But before granting the "extraordinary remedy" of an injunction, U.S. courts would apply the traditional four-factor test, which includes assessing:

+ the balance of hardships between allowing the conduct in question to continue vs. issuing the injunction;

+ whether the damage being caused by the conduct in question could be satisfactorily remedied by a payment of money as opposed to a mandate or a prohibition; and

+ (importantly) the public interest.

See, e.g., the Supreme Court's discussion of the four-factor test in eBay v. MercExchange, 547 U.S. 388 (2006), https://scholar.google.com/scholar_case?case=481934433895457...

That's why I'm looking into IPFS(https://ipfs.io) as part of my infrastructure. How that would look then, with IPFS...

> "So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct."

> "You're being honest with me." "Yes, your Honor."

> "Will the computers continue harming the plaintiff's interests if shut off?" "No it wouldn't, your Honor.".....

And suddenly things like NPM can transfer the data to other machines, and those machines themselves can also provide to others. Deletions are impossible if people still want the content.

And IPFS guarantees that if a single node has the data, then any node can download it and also be part of the cloud that provides the data. Once it's out, it's impossible to retract.

This why sites that don't allow package authors to "unpublish" have contact information so that data deletion can be handled on a case-by-case basis.

If they receive a court order, and there is no technical way to do that, then the court is out of luck. "A court might order it in the future" is not a design constraint on your decisions today.

Sure there's a technical way to do it: you unplug the server hosting it (or more likely, your hosting provider does that for you).

No court is going to shed any tears over fact this has wider consequences than if you'd been able to comply with a narrower takedown request.

This combined with the cost of hosting (I remember the ruby community freaking out over rubygems costs a couple years ago) makes me think maybe we're evolving towards decentralized dependency hosting. Something like Storj where users offset hosting fees with blockchain payments when dependencies are fetched.

The go solution seems more reasonable and achievable- the host is part of the namespace. Instant decentralization.

There's nothing preventing decentralization with npm now; it's a matter of configuration. Tying the namespace to a host seems more like instant excessive coupling.

Tying namespaces to a hostname isn't really that controversial -- it's no different than email.

If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration.

If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees.

Throw in some automatic bittorrent support in the client to help offload costs and you've got something great.

npm already supports all of that except the bittorrent bit, with the proper configuration, and without requiring that idiosyncratic namespace convention. [0] I don't think bittorrent is actually relevant to most use cases. Most people complaining here just don't want their site to go down, so they should vendor or fork all their deps and run their own registry to support that. Downstream users of public modules can either go through npmjs or perform the same vendoring and forking work themselves.

[0] https://docs.npmjs.com/misc/registry

There have been links to child porn in the Bitcoin blockchain. To date, this has not resulted in any courts preventing full nodes from running in the US.

Reply on news.ycombinator.com