5 ms·

Because 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 ago
If 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 ago
  Each 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 ago
    I 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 ago
      Interesting 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 ago
      Even 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.
      - dane-pgp 5y ago
        > The license that you accept each time you install or update the library explicitly states: A license isn't a "get out of jail free" card. If he had put in the license "the authors shall not be liable for murdering you" that would not count as a defence in court. > doesn't absolve you of respecting the terms of the license. You don't have to respect any term that isn't legally valid. If you sent someone an email attachment pretending to be spreadsheet, but it actually contained a destructive virus, with an accompanying licence saying "by running this code you agree to accept all the damage done to your computer", that licence would be legally void. > 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) In this case the person granting the licence is also the one doing the damage, so it's like your boss calling you into his office and informing you that he was going to punch you in the face and that you couldn't sue him. Even if you signed an employment contract which said he could do that, it wouldn't override legislation which criminalises assault. (None of this is legal advice, and there are probably exceptions to all these rules). > professional software developers and end users should be held to a different standard. I don't know of any situation where a judge decided that a crime didn't happen because the victim was smart enough that they could have avoided being victimised. It's like saying "well if you didn't want the murderer to break your window and sneak into your house at night and kill your family, then you should have known that was a risk and put bars on the windows". It doesn't matter if someone is a home security expert, or a millionaire, or had any other advantage, it is still a crime to take advantage of someone's less-than-perfect security and murder people. The whole point of having laws is that we can't put in place guarantees that crimes won't happen, and it makes more sense for society to put in place after-the-fact punishments to provide disincentives against people doing socially negative things. It doesn't matter if you could have prevented someone from harming you, you are still allowed to rely on the legal system to punish the person who causes that harm. Obviously this is all predicated on whether a DoS attack really does meet the legal definition of "malicious" software, and I don't want to pre-empt what a jury would decide in this specific case, if it ever went to trial, but I think that there is enough evidence of intent and harm here to at least investigate it, and I don't see how a software licence can be used as a defence, any more than the "by accepting this brick through your window" defence, which was jokingly invented during the infamous Sony rootkit incident: http://www.robhyndman.com/2005/11/22/by-accepting-this-brick-through-your-window/ http://www.robhyndman.com/2005/11/22/by-accepting-this-brick...

dane-pgp 5y ago

If 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 ago
Each 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 ago
  I 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 ago
    Interesting 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 ago
    Even 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.
    - dane-pgp 5y ago
      > The license that you accept each time you install or update the library explicitly states: A license isn't a "get out of jail free" card. If he had put in the license "the authors shall not be liable for murdering you" that would not count as a defence in court. > doesn't absolve you of respecting the terms of the license. You don't have to respect any term that isn't legally valid. If you sent someone an email attachment pretending to be spreadsheet, but it actually contained a destructive virus, with an accompanying licence saying "by running this code you agree to accept all the damage done to your computer", that licence would be legally void. > 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) In this case the person granting the licence is also the one doing the damage, so it's like your boss calling you into his office and informing you that he was going to punch you in the face and that you couldn't sue him. Even if you signed an employment contract which said he could do that, it wouldn't override legislation which criminalises assault. (None of this is legal advice, and there are probably exceptions to all these rules). > professional software developers and end users should be held to a different standard. I don't know of any situation where a judge decided that a crime didn't happen because the victim was smart enough that they could have avoided being victimised. It's like saying "well if you didn't want the murderer to break your window and sneak into your house at night and kill your family, then you should have known that was a risk and put bars on the windows". It doesn't matter if someone is a home security expert, or a millionaire, or had any other advantage, it is still a crime to take advantage of someone's less-than-perfect security and murder people. The whole point of having laws is that we can't put in place guarantees that crimes won't happen, and it makes more sense for society to put in place after-the-fact punishments to provide disincentives against people doing socially negative things. It doesn't matter if you could have prevented someone from harming you, you are still allowed to rely on the legal system to punish the person who causes that harm. Obviously this is all predicated on whether a DoS attack really does meet the legal definition of "malicious" software, and I don't want to pre-empt what a jury would decide in this specific case, if it ever went to trial, but I think that there is enough evidence of intent and harm here to at least investigate it, and I don't see how a software licence can be used as a defence, any more than the "by accepting this brick through your window" defence, which was jokingly invented during the infamous Sony rootkit incident: http://www.robhyndman.com/2005/11/22/by-accepting-this-brick-through-your-window/ http://www.robhyndman.com/2005/11/22/by-accepting-this-brick...