Hacker News Reader

Comment by Isthatablackgsd | Hacker News Reader

> No, it isn't legal to maliciously add an infinite-loop to a library that you know is used by other companies.

Could you cite an source for this? Because I got a impression that it "isn't legal" which mean it is not illegal based on your comment. I would assuming you are referring to USA Computer Fraud and Abuse Act?

View on HN

"18 U.S.C. § 1030(a)(5)(A) knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;"

I agree with awinter-py, it will be tricky to use "without authorization" for this. The developer only published the code, that is up to other companies to verify the code and roll with it. If Company A installed the dependency, that could mean Company A "authorized" the code because they pulled the dependency to their system. So not sure how CFAA could protect this if the Company A proceed to download the code which in turn that the code are authorized. It is their responsibility to audit and verify the code before incorporating into their software.

Is it considered "authorized" if I knowingly visit a website but did not realize it would execute malicious JavaScript on my machine? Anyone who unknowingly installed this malicious package in their project is having that same problem.

'without authorization' here is going to be tricky. author probably did have authorization to both github + npm? and didn't knowingly cause transmission to anywhere else? the rest of the steps were pull, not push.

If we're honest about the US justice system, this would be a subjective decision decided by non-technological lawyers, jurors, and judges. The purposeful malicious intent is working hard against his stance.

>> The purposeful malicious intent is working hard against his stance.

OK, but should cloud providers similarly be held accountable for screwing their customers through negligent acts - to come full circle, like pulling these updates without doing any checks or QC?

Although it's a different area of law, product-defect liability attaches to all actors in the "stream of commerce" stretching end-to-end from the manufacturer to the retailer.

scotus in van buren (2020) let off a cop who was selling LPR searches for cash so in theory the days of aggressive interpretations are over? eff called it a 'victory for security researchers', though it's probably too soon to say whether it's that or just a victory for people selling LPR data

The precedent doesn't apply. The SCOTUS interpreted (and in effect, defined) that the "authorized access" in 18 U.S.C. § 1030(a)(2) can't be qualified and limited to less access. If I'm authorized to see usernames, and due to light hacking I can also see emails - I'm n̵o̵t̵ ̵a̵ ̵c̵r̵i̵m̵i̵n̵a̵l̵ maybe a criminal (EDITED). If I'm authorized to check license plates for some reasons, and despite employer policy I checked license plates for some other reasons - I'm not a criminal.

The issue we're discussing here is based on 18 U.S.C. § 1030(a)(5) (note the last digit) and "authorized access" is not mentioned there at all. This section deals with damage and not access.

hmm, not really my area. This coverage of van buren seems to show the court trying to make 'authorization' agree in meaning in different parts of (a)(2)?

https://www.natlawreview.com/article/supreme-court-ends-long...

This incident has nothing to do with (a)(2) as Marak didn't _access_ any system. The only sections violated are (a)(5) (_knowingly damaging_ a system) and, arguably, (a)(7) (extortion). (a)(7) is a lot harder to argue though as his extortion attempt doesn't have a named target or an explicit demand and is generally... lame.

Edit: Note that I'm seeing this the same as a virus, not the same as a data-extraction hack.

Reply on news.ycombinator.com