5 ms·
How is it not a legal issue to intentionally DOS customers servers? I would send a complaint to the California DA’s office for hacking; the laws against which i
by inlined 5y ago
How is it not a legal issue to intentionally DOS customers servers? I would send a complaint to the California DA’s office for hacking; the laws against which in CA are very liberal.
- toomanydoubts 5y agoBecause you chose to download and execute it, without due diligence, while the license states that the code comes with no warranty whatsoever?
- dane-pgp 5y agoIf you create a package which claims to do one thing, but actually deliberately does something else that you know users don't want, then surely there comes a point where the harm done counts as hacking?
- dns_snek 5y agoEach version of the package comes with its own source code and license. It's your responsibility to audit new package versions before installing them. And that's what the author did, he published a new version. You can blame your tools and package.json for automatically updating, but at that point it's a self-inflicted injury.
- dane-pgp 5y agoI haven't actually checked if the README or description of the package was updated to reflect the new (malicious) behaviour of the code, but even if it was, I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking. It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls, but justified your actions by saying "Well you could have searched me before I entered to make sure I wasn't carrying that spray can". Or perhaps a better example, what if some (free) binary application auto-updated, and included in the release notes or documentation a sentence stating that the "File > Open" option had been changed to instead delete the selected file. Would you still blame the victim for their "self-inflicted injury"?
- toomanydoubts 5y agoInteresting questions. I don't know the answer and I believe even lawyers might have trouble with this. I guess it would come down to 1) how technically savy is the user(is it a FAANG engineer or a grandma? is it expected from a FAANG engineer to look at the diffs when applying updates? Is a grandma expected to read the release notes?) and 2) how malicious is this code change? Are the users updating the only ones wronged or first-time users too? Say you're installing a library for the first time. The library says it does A, you install it and realizes is does B, are you then allowed to sue the author? I guess it depends on how far A is from B and how malicious B is, but the author explicitly stated the code comes with no guarantees. Should anyone that installs "left-pad", but then realize the lib only does right-padding be able to successfully sue the author? The code explicitly comes with no guarantees! It seems very tricky and I'm not sure we can write deterministic black-or-white laws for this, but again, maybe I'm applying a higher standard based on SWE practices for other trades. As far as I know, the legal system is on the hands of politicians who write non-total functions and judges who interpret those functions as they wish.
- inlined 5y agoEven if it were in a readme, the developer knows the default version of npm install is a version lock on the major and they made it a patch version so that it would intentionally be picked up by almost everyone. I think I actually am going to file criminal charges.
- dns_snek 5y ago> I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking How so? The license that you accept each time you install or update the library explicitly states: "IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY [...]" Use of automation software (npm, yarn) to auto-magically fetch newer versions of your dependencies doesn't absolve you of respecting the terms of the license. Newer versions could have a different license or contain completely different code, there are no guarantees and no contracts. > It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls I don't think that's a good analogy at all. I think this is much closer to the truth: It's like your boss called you into the office (i.e. explicit software update), gave you a signed waiver that said you couldn't be held liable for anything that you did to the building (i.e. LICENSE) and told you to go crazy (i.e. not auditing the update), so you spray painted the walls and left. > Would you still blame the victim for their "self-inflicted injury" No, because professional software developers and end users should be held to a different standard. The fact that you should be auditing your dependencies is well known, precisely because of such scenarios, but people still choose to ignore it because it's inconvenient. This should be the final wake-up call for devs to start pinning and auditing their dependencies. For the casual end user, replacing functionality of "File > Open" button would be a dick move by the authors, but still within their rights (assuming MIT license). All in all, developers should be outraged at the state of the NPM ecosystem and their own software development/release practices. He could have easily stolen everyone's AWS access keys and other tokens/secrets if he truly wanted to be malicious. You can call him an asshole and you'd likely be right, but he was fully within his rights to do what he did.