Live data from Hacker News

This hacker might seem shady, but throwing him in jail is bad for everyone

washingtonpost.com

101–110 of 213 posts

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#101
post #99

Earlier quoted context omitted.

I approach this from a different angle. If someone broke into my web app by injecting SQL, I'd be mad that I allowed them to do so. If someone broke into my apartment by smashing the window with a brick, I wouldn't be mad at myself for not using thicker glass. Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.

So does that mean if someone picked the lock on your front door and just had a look around your apartment, without doing any damage; you’d be ok with that and just be mad at yourself for not installing a better lock?

I guess if I never knew about it, I wouldn't be upset.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#102
post #72
post #69

Earlier quoted context omitted.

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

No, it is because lying about your user-agent is not explicitly trying to make an HTTP server perform an action it is not supposed to perform and is therefore not in the same category as SQL injections. HTTP servers are not supposed to use user-agent as authentication.

It's the equivalent of going to a Chinese restaurant and asking for the "Chinese menu" rather than the "American menu" even if you can't read Chinese.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#103
/u/biot's analogy is apt. But I don't understand why it isn't a defence that the HTTP protocol starts with a REQUEST . The server is the one who actually serves up the information.

If I _request_ something from you ("hey, can I borrow your car?"), and you give it to me, then what's the problem here?

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#104
post #35

Everyone throws out analogies about walking into unlocked houses and such. Those are fairly poor analogies, so let me offer one which I think is far better at conveying what really happens. Imagine you walked into a public library and struck up a conversation with the librarian: You: Can you tell me general information about this library? Librarian: Certainly, this library was built in 1990, has a million books on it…

What happens in the scenario where the librarian is instead a low IQ worker helping out?

    You: Can I have this book?
    Worker: No, sorry, not allowed.
    You: It's ok, the boss said so.
    Worker: I don't think so.
    You: We're friends, right? You don't say no to your friends, do you?
    Worker: Well, ok, I guess you can have it.
Hey, the worker said it was ok, I guess you were authorized after all!

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#105
post #69

Earlier quoted context omitted.

So if I ask the librarian for a copy of the book with ISBN 1; DROP TABLE books; -- is that okay because, technically, the server let my request through?

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

It is the server's problem. A misconfigured server is not a client's problem.

Set aside the SQL injection. Suppose there's a bug in Apache's path parsing such that using "\" instead of "/" causes it to interpret it as an escaped string, which somehow (bear with me) causes it to run exec("/bin/rm -r /"). Now some n00b comes along and uses "\" in the path, because he's used to paths on MSDOS; crashing the server. Whose problem is it? The client's, for sending a malformed request? How do you expect the client to know that the "\" will trigger a catastrophe? Or what if the client made a mistake, and while he thought it was "some query string" in his cut buffer, it turned out to be "; drop table *" (or something like that). Now whose problem is it?

If the server willy-nilly takes any input and doesn't check it, it is the server's fault.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#106

Earlier quoted context omitted.

>This was a PUBLIC website... you are supposed to be able to visit it. If you make a request to a server without providing authentication and it returns data, that is not your fault. That is what you are SUPPOSED to do to servers. If it asks for authentication and tells you you are unauthorized, but you brute force the password or find an exploit, then THAT is a crime. There was not authentication in this case. Unfor…

If I find a $50 bill on a sidewalk I can INTEND to steal it as much as I want. But no matter how badly I WANT to steal it I cannot because at that point it's not a thing that can be stolen. There is no way to trace it back to it's former owner and as such, the first person to find it is legitimately the new owner. Weev might have said that he "stole" the information or that he "intented" to perform an unauthorized ac…

Depending on what you find and where you find it, actually, you may have a legal obligation to attempt to return it to the owner. The law is not quite as simple as finders, keepers.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#107

Earlier quoted context omitted.

By "unpopular speech", do you mean the AT&T bit, or the harassment bit? If the latter, I disagree. A free and fair society can certainly draw a line between "unpopular speech" and "criminal harassment." If I were to threaten to murder you, you wouldn't expect the police to say "Eh, nothing we can do, he's got a right to free speech. Call us back after he shoots you, you'll have a case then."

If I were to threaten to murder you, you wouldn't expect the police to say "Eh, nothing we can do, he's got a right to free speech. Call us back after he shoots you, you'll have a case then." This is the problem with thought experiments regarding crime: they always make the facts 100% certain, when in real life, the facts are never 100% certain. If we were to rephrase your thought experiment, it would be: "Some guy s…

If only there were some way to determine what was meant. Barring that, maybe it's best not go around saying such things if you can't even convince one out of twelve people that you weren't serious.

Regardless of whether you truly intend to carry out the threat, the threat itself is a form of violence. It imposes your will on an unwilling subject.

If you rob a bank with an unloaded gun, you can't claim afterwards, "oh, they were perfectly safe and didn't actually have to give me the money, so therefore it wasn't a crime."

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#108
post #74

Earlier quoted context omitted.

You totally nailed it. 100% right. Distilled it down to the essentials of how the internet works and the nature of a protocol as a contract. Bravo.

His whole analogy only works because the librarian is a human, and if a human with some apparent authority lets you do something, you can reasonably infer that you have permission to do it. But you can't anthropomorphize a server like that. It's not a gatekeeper, capable of granting permission, just a dumb lock which may be flawed. Only humans can consent. To repurpose his analogy, if you sneak into the staff room an…

[deleted]

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#109
post #69

Earlier quoted context omitted.

So if I ask the librarian for a copy of the book with ISBN 1; DROP TABLE books; -- is that okay because, technically, the server let my request through?

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

  You: Can you provide me with Angela Smith's email address?
  Librarian: Sure, here you go.
Later,

  Librarian's manager: You weren't supposed to give out that information!
  Librarian: Oops. I had the wrong access rules.
  Librarian's manager: Let's call the cops on that guy. 
    It's his fault that you gave him the information he wasn't
    supposed to have.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#110
post #105
post #69

Earlier quoted context omitted.

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

It is the server's problem. A misconfigured server is not a client's problem. Set aside the SQL injection. Suppose there's a bug in Apache's path parsing such that using "\" instead of "/" causes it to interpret it as an escaped string, which somehow (bear with me) causes it to run exec("/bin/rm -r /"). Now some n00b comes along and uses "\" in the path, because he's used to paths on MSDOS; crashing the server. Whose…

Whether it's the server's or the client's fault doesn't matter that much from a legal perspective. Intent plays a big role: if you knew that ending a URL with "\" causes `rm -rf /*` to be run, and intentionally run that on a server, you could likely be prosecuted and convicted if it were proven that you did it intentionally. If it were done accidentally by a client, they would (likely, and hopefully) not be convicted.

Weev intentionally exploited an information disclosure flaw. Should he have gone to jail for that? No, I don't think so at all. But the scenario you're presenting has no relation to what happened here.

Post reply on HN