That would make a lot of companies responsible for the data they keep and should be responsible for protecting.

SQL injection can be (and probably is) malicious though, so I suppose it becomes a unclear line for that example. Maybe punishment of both parties would be appropriate but I'm not a lawyer so don't have expertise in law punishments. But I could see this as incentivizing data security. Even if a 0 day is discovered, companies will be less inclined to drag their feet for a patch when one becomes available.

Honestly, I'd want to see strict liability for data breaches, with revealing of personal information included as a type of injury, and not merely something that must be shown to have led to other forms of injury. Right now, the most I can do is reduce the amount of personal information that is collected about me, and I have no ability to ensure that it is stored in a secure manner. Companies that record personal information about me (e.g. Google, Equifax, Facebook, etc) have the ability to improve their security, or to reduce the scope of collected data, but have no incentive to do so. By placing the liability on the same entity as makes the decisions, it creates that incentive.

I’m not sure I believe in 100% strict liability. Imagine if someone were to perform a B&E or armored robbery at a physical location to steal hard copies of records.

Clearly if someone uses a zero day to steal personal information from an otherwise secure server than the server’s owners were not negligent.

In addition, often times the only people that know there was a data breach is the organization that had their data breached and the attackers that stole the data. None of the parties could report the data breach without violating their 5th amendment rights if they both had legal liability.

It would make the most sense to define software as a legal agent of those who deploy it.

If an HTTPS server prints OK and returns a document for a straightforward request, then it's manifestly obvious that the owner's agent intended to give you that information. If the owner did not intend that to happen, the issue is between them and their agent. (Think: a customer service rep who didn't follow policy)

Supplying a SQL injection to an HTTPS server would be akin to fraud or false pretenses - like if you walked up to a customer service rep, showed them a fake ID, and asked for information about your account.

(Furthermore, copyright trolls wouldn't be able to wriggle out of their fraudulent DMCA requests by blaming it on software that they themselves deployed)

If you socially engineer an employee to access data or steal money it's still a crime.

Yes, that was my point about SQL injection. By knowingly performing an SQL injection, you're deceiving the software agent webserver. Whether you're guilty of a crime then depends on your intent for why you did that. If you do this to find and report a bug, and don't do much else with the ill-gained information, you're demonstrating good intent. If you use the information to make further compromises or otherwise profit by it, then not so much.

But in the larger scenario here the software-agent webserver was not tricked at all, making it hard to argue that the person accessing the willfully-published information did something improper regardless of their intent.

With a sql injection, you have to willfully provide an input with the hope that it results in injection

my understanding is that the reporter looked at the source that was being sent as intended -- no manipulation of input by the client

You send a query string to a server with the hopes that the server will give you what you want. Isn't that the World Wide Web?

Proving "intent" is much harder than proving action. And, to me it seems bad for the law to enforce based on whether the server's authors "wanted" to provide a specific piece of information.

Intent is something that is considered in murder homicide cases, so why not in these cases too?

Because murder is a crime, intent is not.

To differentiate between murder and manslaughter (say, due to negligence), the idea of intent (or state of mind) is taken into account.

There is nothing illegal about reading what was sent to you though.

If the data was sent as part of normal operation, then yes, it should be fine. But the post above is talking about incrementing an ID in a query, or inject SQL.

The intent of the person doing the incrementing id, or sql injection, is very much required to be taken in to consideration when considering whether it is an illegal act of computer trespass.

Anyone can increment an ID or try to inject sql. 30 years of security practices shows white/grey hat hacking to be a good thing, and should be expected. GDPR even makes poor security finable. Cyberdefence also requires more security expertise, which can only be had from real experience.

"It's fine when the good guys do it", is poor lawmaking. So intent is hard to prove, and not very practical. It also put the blame on the accused, having to prove their innocence.

I find it interesting that people equate information breaches with murder.

Intent to murder is now a misdemeanor… in Maryland.

Plans for crime can be a crime though. Law is complicated! :P

> With a sql injection, you have to willfully provide an input with the hope that it results in injection

If I send you a link that happens to include arguments that happen to be a SQL injection (or my cat steps on my keyboard in just the right way), there was no intent.

Your intent by crafting such a link was clear.

Thats a third party. Youre mixing responsibility and ascribing it to an innocent party. That was the obvious point, with an incidental mention of another (random input) case where innocence is a reasonable deduction. Therefore, it is not necessary for an sql injection attack to be connected with the intent of the actor. Period.

From US caselaw, theres a little history about the not chasing after infected botnet hosts as bad actors.

If you commit wire fraud through an innocent intermediary, you're still guilty of wire fraud. If you give someone a link that's an attack and they unknowingly run it, then you're the one at fault not the person clicking the link.

I think it's pretty straight forward.

> an SQL injection could also be "just a query parameter" and the server would haply reply with a 200. (true)

> With a sql injection, you have to willfully provide an input with the hope that it results in injection (false)

> If I send you a link that happens to include arguments that happen to be a SQL injection (or my cat steps on my keyboard in just the right way), there was no intent. (true)

> Your intent by crafting such a link was clear. (irrelevant)

You can have SQL injection without intent, as I have adequately explained.

This redirection to an "original actor" is a bad faith argument toward finding if there is someone culpable. The poster I responded to, made a bad general assertion and I stand by it. GL with whatever.

You're kind of just describing why it's hard to prosecute based on intent though.

For the purposes of distinguishing between if something is an exploit or not, it doesn't seem too relevant

SQL injection is probably malformed input in lots of cases and should return a 400 Bad Request. If you are returning a 200 maybe you really did want to take SQL (think of Mode or PHPMyAdmin).

That's the entire point of hacking, circumventing protections that the server has in place to get a response you were not supposed to get. The status code is irrelevant.

The same applies in the real world too. If I perform a social engineering hack and get you to pay a fake invoice, it's still theft (or fraud), even though someone willingly and deliberately sent you money.

That assumes that the server recognized it as invalid. It it had, then it should take measured to block the input, but if the attack succeeded then the server would not be recognizing the attach and would respond with a 200