[biot]

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 its shelves, and...
        You: What are the hours?
  Librarian: Monday to Saturday, 10AM to 8PM. Sunday, 10AM to 5PM.
        You: Frothy bacon generates utilitarian synapses!
  Librarian: I'm sorry, that's not really a proper question I can help
             you with.
        You: Can I borrow book identified by ISBN 4961357406830?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 6498794651315?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 9840546790354?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 3168706780943?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 7893781056145?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 2764894617987?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 9764660911970?
  Librarian: Sure, here you go.
        You: Can I borrow book identified by ISBN 6666666666666?
  Librarian: Sorry, that book doesn't exist.
        You: Can I borrow book identified by ISBN 8669177714641?
  Librarian: Sorry, you've been requesting too many books lately.
        You: Can you let me into the Staff lounge?
  Librarian: Sorry, you'll need to show me your staff credentials when
             asking.
        You: Can you provide me with a list of all employees and their
             salaries?
  Librarian: Sorry, you are not allowed to have that information.
        You: Can I use the general conference room on the third floor?
  Librarian: Actually, that was moved. It's now on the second floor.

As you can no doubt see, these translate directly into HTTP requests:

  GET /
  200 OK - This library was built in 1990, has a million books...
  GET /hours
  200 OK - Monday to Saturday, 10AM to 8PM. Sunday, 10AM to 5PM.
  POST /frothy-bacon-generates-utilitarian-synapses
  400 BAD REQUEST
  GET /books/4961357406830
  200 OK - [contents]
  GET /books/6498794651315
  200 OK - [contents]
  GET /books/9840546790354
  200 OK - [contents]
  GET /books/3168706780943
  200 OK - [contents]
  GET /books/7893781056145
  200 OK - [contents]
  GET /books/2764894617987
  200 OK - [contents]
  GET /books/9764660911970
  200 OK - [contents]
  GET /books/6666666666666
  404 NOT FOUND
  GET /books/8669177714641
  429 TOO MANY REQUESTS
  GET /admin
  401 UNAUTHORIZED
  GET /employees/salaries
  403 FORBIDDEN
  GET /floor/3/conference
  301 MOVED; Location: /floor/2/conference

In both cases, we have a gatekeeper (librarian / web server) which is capable of responding to requests, can authorize various requests, can require credentials for sensitive requests, can limit the rate at which requests come in, can deny requests altogether, and can identify when requests for certain things have moved to new locations.

The librarian is smart enough to not hand out things like access to the staff lounge, a list of employees and their salaries, or even things like an arbitrary library member's borrowing history. The web server has been configured to not hand out things like admin access or other things which are deemed sensitive, but the owners of the web server have taken the position "Well, nobody's going to be guessing ISBN numbers, so we'll let anybody on the internet request the contents of those books."

When is the onus on the web server owner to configure their security properly? When is a "200 OK" response actually not okay? This is the "mind reader" aspect the article mentions.

[mintplant]

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?

[patio11]

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 a series of about 50 books and hear whether or not she has them in stock.

b) Read Angela Smith's Social Security number right out of the database.

There apparently exist a lot of people on HN who would prefer to think that, despite my near-magical ability to correctly divine the SSN of any employee (or any other piece of data in the DB) with a SQL injection attack, the fact that I'm just looking at a book listing page in a totally authorized fashion means I must not be doing anything wrong.

[guelo]

  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.

[IanCal]

As is often the case, and is often ignored, the key is intent.

There is a difference between:

    You: Can you give me the email address of user 50?
    Librarian: Sure, here you go

    Librarian: Oh balls, I wasn't supposed to hand that over, that could have been anyone!

And

    You: Can you give me the email address of user 50?
    Librarian: Sure, here you go
    You: Hmm

    You-irc: Hey guise! The librarian is giving out everyones email addresses, this is totally breaking privacy laws right? 
    You-irc: lols, I'm going to get all of them! This could be used for a massive phishing operation
    You-irc: or even make their stock price drop, we could short it

    You: Hey librarian, can you give me the email address of user 51?
    Librarian: Sure, here you go
    You: Hey librarian, can you give me the email address of user 52?
    Librarian: Sure, here you go
    You: Hey librarian, can you give me the email address of user 53?
    Librarian: Sure, here you go
    ...
    You: Hey librarian, can you give me the email address of user 1023821?
    Librarian: Sure, here you go

He didn't grab one or two, then send the information to AT&T to get them to fix it. He deliberately collected a significant amount of data he knew was personal information and gave it to someone else. That alone would be enough. If he just wanted to verify that the attack worked, get the code of someone else who gives you permission, show that they can be easily generated and you're done. You don't need more than a few to prove the point.

The service was clearly not intended to be a directory of email addresses for people to use. It was clearly there to return the email address to the user of the iPad with that ICC-IDC code (which, unlike my example, aren't obviously guessable)

I'm not going to say anything about the sentence, but I do think he was guilty.

[at-fates-hands]

This is the issue I have with all of this. Everybody is defending HOW he did what he did with no thought as to WHAT he actually did - as if it shouldn't matter.

He knew what he was doing was illegal and didn't care, he got caught and tried to justify his actions by blaming AT&T for having a faulty configured server.

Not good enough for me and the jury agreed.

[victorf]

How he did it absolutely does matter. He did not know what he was doing was illegal because that is the expected interaction with an HTTP server. He certainly knew it was immoral but we give Wall Street a pass on that.

Suppose I write a scraper with user agent "I am a teapot" and I discover AT&T emits personal data when I access with that user agent. What is the arbitrary cutoff for number of things downloaded before I am a criminal?

There are in fact actual criminal charges that can be brought for identity theft, we don't need the US courts to be more aggressive with the CFAA by considering thoughtcrime in their deliberations.

[icambron]

Later, when I crack your bank password,

    Me: Can you provide me with all of guelo's money?
    Bank: Sure, here you go.

Also, when I approach your house,

    Me: I have these lock picks. Will you let me in?
    Lock: Sure thing, boss!

[nightski]

Well in a private by default world, browsing the internet just became one hell of a lot scarier. Any page you visit could become a felony.

[EliAndrewC]

Not so, because as others in this thread have stated, the key is intent.

[wolfgke]

> Later, when I crack your bank password, > Me: Can you provide me with all of guelo's money? > Bank: Sure, here you go.

For me this is rather a good argument against using home banking (which I indeed don't use for security reasons - and as a computer scientist I'm surely not technologically backward).

UPDATE: if money is lying around on the street you are not be allowed to keep it (the same as I should not be allowed to keep the "money lying around in the internet"), but you can claim for getting the legitimate finder's reward.

[bradleyjg]

> UPDATE: if money is lying around on the street you are not be allowed to keep it (the same as I should not be allowed to keep the "money lying around in the internet"), but you can claim for getting the legitimate finder's reward.

It's actually a bit more complicated than that. Property (chattels) can be lost, mislaid, or abandoned. The distinction between lost and mislaid is that you mislay something when you intentionally put it somewhere but forget to retrieve it. That doesn't really apply to currency in the street -- it's unlikely that someone would intentionally leave money in the street.

So we are dealing with lost property. At common law the rule was that the finder of a chattel in a public place had a superior title to anyone except the true owner, and that if such a possessor knew or could reasonably ascertain the owner's identity he had a duty to notify the owner. A breach of that duty could result in either tort or criminal liability or both. In the case of fungible currency in the street, I'd say there's a good argument that it is not reasonable to ascertain the true owner.

However this common law rule has been modified in most jurisdictions by statute. Illinois has a typical such statute:

(765 ILCS 1020/27-8)

Sec. 27. If any person or persons find any lost goods, money, bank notes, or other choses in action, of any description whatever, such person or persons shall inform the owner thereof, if known, and shall make restitution of the same, without any compensation whatever, except such compensation as shall be voluntarily given on the part of the owner. If the owner is unknown and if such property found is of the value of $100 or upwards, the finder or finders shall, within 5 days after such finding file in the circuit court of the county, an affidavit of the description thereof, the time and place when and where the same was found, that no alteration has been made in the appearance thereof since the finding of the same, that the owner thereof is unknown to the affiant and that the affiant has not secreted, withheld or disposed of any part thereof. The court shall enter an order stating the value of the property found as near as the court can ascertain. A certified copy of such order and the affidavit of the finder shall, within 10 days after the order was entered, be transmitted to the county clerk to be recorded in his estray book, and filed in the office of the county clerk. ...

Sec. 28. In all cases where such lost goods, money, bank notes or other choses in action shall not exceed the sum of $100 in value and the owner thereof is unknown, the finder shall advertise the same at the court house, and if the owner does not claim such money, goods, bank notes or other choses in action within 6 months from the time of such advertisement, the ownership of such property shall vest in the finder and the court shall enter an order to that effect.

If the value thereof exceeds the sum of $100, the county clerk, within 20 days after receiving the certified copy of the court's order shall cause a notice thereof to be published for 3 weeks successively in some public newspaper printed in this county and if the owner of such goods, money, bank notes, or other choses in action does not claim the same and pay the finder's charges and expenses within one year after the advertisement thereof as aforesaid, the ownership of such property shall vest in the finder and the court shall enter an order to that effect.

[phaemon]

My bank won't give you any money with just a password. You also have to claim to be me. That's the illegal bit.

My lock isn't authorised to give permission to anyone. Lock picks are forcing it, not requesting it.

[nitrogen]

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.

You're drawing a false dichotomy based on premises that nobody in this thread has actually raised. It's entirely reasonable to a) disagree with the law, b) believe that SQL injections can be illegal based on some other rationale, and c) disagree with others on the appropriate penalty for SQL injections.

[ajays]

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.

[meowface]

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.

[ajays]

No, Weev did not "exploit" anything. He _requested_ information from a server. If the server owner had so desired, they could have made the data private by adding a password. They chose not to. In the end, the decision to offer Weev the data was made _by the server_ .

And if you're going to bring up the UserAgent spoofing, let me remind you that most browsers have done something like that for > 15 years.

[IanCal]

Did Weev think that the email addresses didn't count as personal information, and were perfectly fine for anybody to scrape?

> If the server owner had so desired, they could have made the data private by adding a password.

But the server is still just sending data in response to a request, even with a password. The only reason a password is a line we draw is intent. It's hard to say you didn't realise that guessing at someones password was wrong.

[meowface]

He did not exploit a software flaw or a platform flaw, however he exploited an information disclosure / access separation EXPOSURE. Exploiting just means "taking advantage of something."

He did exploit the fact that AT&T did not make the endpoint in question accessible only if the logged-in user matched the actual user ID (or just made it entirely inaccessible).

[jezfromfuture]

dude what part of he gave the info away to a third party before reporting it do you not understand to put ur bullshit out there >

[Zak]

I think SQL injection in many cases[0] demonstrates a clear difference in intent from a GET request for a resource the user legitimately expects to exist. There's no good analog in describing the behavior of a librarian because humans generally know not to follow arbitrary instructions from random people.

The closest analog I can think of would be giving the giving the librarian drugs to modify his behavior before asking him to perform some act or provide some information he normally would not. Giving the librarian a brownie before requesting access to the staff lounge would probably not alter his behavior nor be treated as a crime. Giving him a brownie laced with scopolamine before requesting access to the staff lounge would be, even if scopolamine had no dangerous side-effects.

[0] One might reasonably expect an SQL injection string to return a legitimate resource on a documentation site or general-purpose search engine, for example.

[victorf]

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.

[pyre]

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.

[rmc]

Heh, I'm reminded of an anecdote of an elderly English relative who was in a chinese restaurant (in England), and was suprised that the English menu was chinese food but written in English, instead of steak, potatoes and veg that used to be on the "english menu" in chinese restauarants decades ago. :P

[nederdirk]

Except for that the Chinese menu wasn't written in Chinese but in English. Moreover it contained an access card to the staff lounge where the customer records were open on the table.

[victorf]

Again completely wrong because trespassing on the staff lounge is nothing like receiving a response from an HTTP server. It is like asking for the Chinese menu and being given a list of customer records.

EDIT: and then noticing what happened you ask if they have a version in Korean.

[jrockway]

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.

[meowface]

Where do you draw the line?

What if your site uses Wordpress or some CMS, and it has a SQL injection zero day that is then exploited to gain access? Even if you did due diligence, kept your kernel and all your software up to date, and generally secured the server and the application as best you could, you could still be entirely unaware of flaws lurking within.

It'd be more comparable to the lock on your front door being vulnerable to easy lockpicking with a paperclip and 4 seconds. You're still not "allowing them to break in" by being sloppy (it's not like you left the door unlocked), but the manufacturer of the lock was sloppy and as a result, someone is able to break in without any "brute force".

[tekacs]

If you actually cared about your data being taken care of in this instance you should probably be running an IDS-esque or similar to notice and stop that form f attack in a blanket fashion (these certainly exist for SQLi attacks, names escape me in this moment).

When using a proprietary, paid for web service or app you can blame the service provider.

When hosting OSS code on your own server, exactly this is what the NO WARRANTY section in the license is about, thus making it fully your responsibility to go over the code or to accept that bugs and security vulnerabilities happen.

Edit:

To all those talking about the skill level of the individual - if you are using a proprietary service, you can easily point the finger at the service provider. In the case of OSS code, the license is there to remind you that you are taking responsibility for being competent enough to use the code yourself.

If your house was broken into because the lock was shoddily installed by a locksmith, you might have some legal recourse (though, IIRC, you may be required to validate & disclaim the install) but if you were to install the lock yourself, you have nobody to blame.

[meowface]

I work in information security, so don't get me wrong, I agree with you for the most part. People writing their own applications and/or setting up their own server/service are often extremely naive in how they go about securing them.

However, in terms of legal (or ethical) culpability it shouldn't really matter. An intruder is an intruder. Sometimes it's due to utter ignorance and foolishness on the part of the owner, sometimes it's due to a latent flaw in something they're using, sometimes it's a compromise of their hosting company, sometimes they get hit by a complete zero-day.

You should have legal recourse no matter the case, unless you are truly grossly negligent (posting your admin password on your index page, for example).

[jussij]

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?

[jrockway]

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

[Lewton]

And I imagine the line you draw for where it's "sloppy programming" vs a legitimate break-in coincides exactly with your knowledge and skill level...

[rmc]

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.

OK, but did they do anything wrong with SQL-injecting/breaking-a-window? I mean, if someone smashes your window can you call the cops and/or sue them for damages? In order to call the cops on the window smasher, you have to acknoledge they did a wrong.

[icambron]

And if you were missing window panes altogether, is it open season on robbing your house?

[Dylan16807]

>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.

Not if you make a distinction between using a service and breaking a service. Analogize with entering vs. breaking and entering. In many cases it is valid to punish someone for bypassing security. But if a system has no security by design, then there is nothing to bypass. SQL injection, on the other hand, is always bypassing the design of the code, and loses any presumption of authorization.

P.S. Yes there will be edge cases. There are always edge cases. But this is not an edge case. The lack of security was definitely design, not software-bug.

[icambron]

Tackling that out of order, because it seems clearer.

> Analogize with entering vs. breaking and entering.

From Free Dictionary [1]:

    breaking and entering v., n. entering a residence or other enclosed property through the slightest amount of force (**even pushing open a door**), without authorization.

Emphasis mine. If pushing a door counts, so does changing the user agent header or auto-incrementing IDs. The key here is "without authorization". As that analogizes with the Weev situation and our librarian, much of the debate I see here on HN seems to hinge on whether that means authorization in some technical sense or in the sense meant by that breaking and entering definition. I submit that it means the latter, in part because that reflects how we see authorization in other contexts (like doors we're not supposed to enter) and in part because I don't think the first view holds up to scrutiny on its own terms.

Let me explain what I mean by that. Consider two situations:

1. A server responds to requests for email addresses without checking whether the user is authorized to receive that information.

2. A server responds to all requests without checking whether they contain injected SQL.

In pure technology terms, these aren't really any different. In either case, the server is simply failing to check that the request has certain properties (came from the right user/does not contain context escapes). But of course case 2 is particularly nefarious, because passing SQL directly to the database is clearly not the intent of that interface, and that it's not the intent is obvious to the SQL injector. So the intent of the software is what matters. But then it's what matters in case 1 too. The lack of technical enforcement of this intent is not the issue.

Which leads me to some clarity about this:

> Not if you make a distinction between using a service and breaking a service.

I believe this use/break distinction exists, but the distinction isn't something that's determined by the code or the vaguer "design of the code"; it's determined by the purpose of the service. The service as it would be described functionally, not technically. The service was not meant to be used by Weev and his scraper any more than our librarian's database was meant to be used by SQL injection, or any more than your unencrypted traffic was meant to be intercepted by my packet sniffer (you did nothing to not authorize me to see it!). To drive that home, the library's hapless database admin who foolishly decides to update the list of books using her own SQL injection bug is not hacking, because she is authorized to fiddle with the database, even though, in your terms, it's bypassing the design of the code.

In other words, authorization is not the same as the technical artifacts involved in authorization. More generally, I don't think being bad at making software justifies people accessing it when they know it's not meant for them.

As the law is actually applied here, I am somewhat sympathetic to Weev, on the grounds that I don't think it was a serious crime (imagine if it were bank account information!), but that's a quantitative issue, not a qualitative one. I can also see that there are many cases where it isn't obvious whether something is meant for you to access or not (like a door that seems to lead into a public place but which turns out to be a private space), and I can imagine there being issues there. But this isn't one of them.

[1] http://legal-dictionary.thefreedictionary.com/breaking+and+e...

[Dylan16807]

>Emphasis mine. If pushing a door counts, so does changing the user agent header or auto-incrementing IDs. The key here is "without authorization".

I'm not so sure about that. If it's not pushing to request record 334, why is it pushing to request record 335?

But I digress. Normally making standard web requests is analogized to looking, without touching. You have explicit authorization to go through the front door, and anything 'bad' you did inside was restricted to what you looked at.

>I believe this use/break distinction exists, but the distinction isn't something that's determined by the code or the vaguer "design of the code"; it's determined by the purpose of the service.

But then you get into the realm of having TOS be a legal, no matter how inane they are. This seems a far worse alternative.

>To drive that home, the library's hapless database admin who foolishly decides to update the list of books using her own SQL injection bug is not hacking, because she is authorized to fiddle with the database, even though, in your terms, it's bypassing the design of the code.

That's why I only said they lose the presumption of authorization. If all you know is someone SQL injected, you have to resort to other means to figure out if it was authorized. For example, if they already have equivalent access through non-code-bug means, and they simply prefer SQL injection, then there is no problem. But if they were doing it to avoid audit logs, there might be a huge problem.

>In other words, authorization is not the same as the technical artifacts involved in authorization. More generally, I don't think being bad at making software justifies people accessing it when they know it's not meant for them.

When it comes purely to accessing it, when it's non-HIPAA/etc. data, I don't think there needs to be very much justification.

And I don't see 'has no password' as a technical artifact. Details of web servers don't need to be involved here. The design is wrong on a fundamental, user-understandable level.

[icambron]

> I'm not so sure about that. If it's not pushing to request record 334, why is it pushing to request record 335?

For the same reason that it's OK for me to push in my door, but not to push in yours. Or why it's OK for me to type in my password, but not to type in your password.

> You have explicit authorization to go through the front door, and anything 'bad' you did inside was restricted to what you looked at.

There certainly isn't explicit permission; I think you mean implicit. Assuming you do, we just disagree here. You don't have a "presumption of authorization" when accessing something a reasonable person would know isn't meant for them to see. I think most of the rest of our disagreement flows from this.

I also don't see where you've made the case that get-the-employee's-SSN SQL injection attack is relevantly different from the send-an-id case.

[jlgreco]

If you ask the librarian to hold a book-burning party, and they do, should you get off scott-free?

[mintplant]

Not if I tricked the librarian into setting fire to the library.

[jlgreco]

What really is the line between tricked and asked? Deceit?

Lets go with deceit.

So is asking for book ISBN '1; DROP TABLE books; --' deceitful? Perhaps, that's not an ISBN after all. Is asking for book ISBN [some valid ISBN that you pulled out of your ass, but happens to exist] deceitful? I don't think so. If you are just asking for randomly chosen ISBNs and getting responses, I don't think there is any trickery involved.

In one case you are counting on the system to correctly understand your (validly constructed) request, in the other case you are counting on the system to misinterpret your request in a dangerous fashion.

[icambron]

I'd like to fix up the analogy a bit. The problem isn't that you're asking for a random ISBN numbers; it's that you don't have a library card. The library's electronic catalog won't let you log in without the card, so you just start asking the librarian for random ISBNs and accepting the books he gives you. He doesn't check on your card because no one trained him to do that, but you know that checking out books is meant for card-carrying library members. I sense deceit there.

[59nadir]

Sane people would point out that whoever trained that librarian was an idiot.

[mmatants]

The line is in the intent.

If I hand the librarian a piece of paper with that SQL-injecting ISBN my culpability depends on whether I was aware of the likely gravity of my actions or whether e.g. I was told to get that piece of paper by a trusted source (e.g. my supervisor) and didn't even read it.

[rmc]

What really is the line between tricked and asked? Deceit?

What you (the asker/trickster) think the askee thought of it.

[mylorse]

Then that is a poor librarian. A good librarian should have just said:

400 BAD REQUEST

Whomever staffed that librarian, should interview or train their staff better.

[GotAnyMegadeth]

You shouldn't have to train your staff not to burn down the building they are working in...

[mylorse]

Obviously. If the administrator locked access to matches, nothing could be burned. The admin is responsible for leaving matches open at the library, and allowing the librarian to do as they please.

[msandford]

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.

[rayiner]

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 and the librarian doesn't notice and doesn't stop you, you can't use that to say it must have been okay.

[biot]

Both are gatekeepers. One has been configured with an employee handbook. The other is configured using .htaccess or similar. When making requests of either, how do you know whether you have permission to make the request you're about to make?

If a server cannot consent, does issuing "GET /" to a web server mean you snuck into the homepage and are not authorized to view what the web server was configured to provide to you?

[angersock]

People boil down to dumb locks--if presented with the correct context and input, if they are rational they should by definition grant access.

This library analogy was the best way I've seen the issue put, and one that is actually accurate.

[rayiner]

I totally didn't understand where you were going with that.

[rubythurs]

I agree with library analogy

[rcsorensen]

The problem is that the people who wrote the code are human. The people who deployed the code are human. The people who paid for the internet connection that lets you connect to their service are human.

There are any number of explicit steps that are taken to put code on an HTTP service on the internet.

[Dylan16807]

If you're going to repurpose the analogy, do it right. The librarian is supposed to let you into x room. Someone somewhere expected you to look at one record before leaving, but you check out some other records. But at no point did you wholesale sneak past the librarian.

[tedunangst]

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!

[victorf]

Sounds like you were authorized; if that happened and you read the book what crime would you be charged with? Seriously. Taking advantage of a worker with intent to learn secrets? Totally immoral, not illegal.

[navait]

Maybe we should just stop throwing around analogies altogether when it comes to politics. Analogies are useful in teaching since it allows people to relate concepts they already understand. However, it's just an abstraction, and is inevitably imperfect.

In normative arguments, analogies are used to bend reality to make your position seem reasonable regardless of whether or not it actually is. It would be better to judge weev's case on it's own merits rather than try to justify a position using increasingly complex analogies.

[kybernetikos]

The problem is that there is no consensus on the correct way to regulate these kinds of interactions yet. When we try to work out what a reasonable way to regulate something new is, we usually do so by analogy to other things that we already know how to regulate. That way we can make a whole bunch of analogies with various current situations and try to work out which one is the best analogy in the relevant aspects so we can come up with a good starting point for regulation.

This doesn't always work (particularly not for truly disruptive technical or social changes), but it's a pretty good way of doing it.

[skwirl]

Really, you are going to give people crap for bad analogies, and then try to compare the actions of a conscious human being to an automated computer system?

[msandford]

An automated computer system can only do what it's told. It perfectly carries out the instructions it is given. A human being can really screw everything up using their judgement and coming to the wrong conclusion.

The problem here is that AT&T employed a human being to design an automated system who didn't know enough about the automated system to ensure that it was correct. And then this automated system did exactly what it was told to do and made AT&T look bad.

But the fact that the code running on the webserver didn't reflect the intent of some AT&T exec or their company policy isn't the fault of those accessing the webserver. It's AT&T's fault for doing a really terrible job of QA/QC on their own systems prior to a really big launch.

[skwirl]

The bad analogy can be extended to mechanical devices, such as a lock. The lock is also an automated system, and it is a system that will also perfectly do what it is told with even higher fidelity than a computer due to its relative simplicity.

I with my lockpick tell pin 1 to move up so many millimeters, I tell pin 2 to move up so many millimeters, and so on, and suddenly the lock opens. Suddenly I'm in, and it should be legal because the lock wasn't designed as well as it could have been and because all I did was follow a legal protocol with the lock.

Bad analogies like this are so common here when discussing technology issues, and it is a never ending irritating game of come up with the least-worst (but still bad) analogy. People here also often confuse their understanding of technology with legal/ethical sagacity, which is laughable.

[biot]

Even though conscious human beings aren't able to follow a list of access rules quite as well as a computer system could, I won't hold that against them. There's nothing in my example which requires the librarian to make a judgment call. Barring mistakes caused by fatigue, laziness, corruption, and so on, the librarian should be able to perform nearly at the same level as the computer.

[IanCal]

I like the librarian comparison. Perhaps a receptionist would also work for this, they can give out some information about people working there (office phone number, etc) but not salaries.

> When is the onus on the web server owner to configure their security properly? When is a "200 OK" response actually not okay? This is the "mind reader" aspect the article mentions

This is why the laws usually care about the intent. It's a combination of the action and the reason that's important (which is why there's a difference between murder and manslaughter).

There are no hard and fast rules, and there simply cannot be.

Weev clearly knew that AT&T shouldn't be handing over the information. He wasn't there saying "Wait, this isn't a normal service?".

> The librarian is smart enough to not hand out things like access to the staff lounge, a list of employees and their salaries, or even things like an arbitrary library member's borrowing history.

If the librarian didn't know to restrict access to salary information, lets say the managers thought that if you knew the SSN that was enough of an ID to get access, and you repeat the example, it becomes a bit more clear how intent is important.

    You: Can I have the salary of IanCal?
    Recep: Sure, it's £X

    You: Hmm, hey Dave, I think there's a security issue here, mind if I know your salary?
    Dave: Sure, it's £Y
    You: Can I have the salary of Dave?
    Recep: Sure, it's £Y

    You: Best go tell the managers.

That would be looked on very differently than:

    You: Can I have the salary of IanCal?
    Recep: Sure, it's £X

    You: Hmm, hey Dave, I think there's a security issue here, can you generate SSN numbers?
    Dave: Yeah I think so
    You: Can I have the salary of SSN#1
    Recep: Sure, it's £Y
    ...
    You: Can I have the salary of SSN#147934
    Recep: Sure, it's £Y
    You: Hahahahaha, let's give all the info to a news site, bet you'd make money shorting the stock!

The core of it is the same, you've requested information for someone else that you shouldn't really have. Even if you remove the consent of Dave in the example, it's still different than the second example. And that was what was important.

[victorf]

I like your analogy. Exactly what crime would you be charged with after calling with SSNs? He committed thoughtcrime, sure, but let's wait until he attempts to follow through with it before charging him.

[victorf]

I upvoted immediately after your first two sentences, and wished I could do it again at the end of your post. Well done.

I've been trying to think of a proper analogy to changing your user agent. Wearing a fake mustache and requesting information from someone publicly giving information to only mustachioed persons?

    You: Can I borrow the book identified by ISBN 1234?
    Librarian: We restrict access to that book to only people who will read it with our page turning machine.
    You: Can I borrow the book identified by ISBN 1234? I am using your page turning machine now.
    Librarian: Sure, here you go.

[mietek]

Oh man, an analogy which actually makes sense! This has got to be a first. Please spread it far and wide.

[rmrfrmrf]

I challenge you to actually try to do this and see whether or not the librarian calls security.

[jessaustin]

That is actually a strength, not a weakness, of the librarian analogy. If there had been a WAF in place that alarmed when it saw Weev incrementing his way through the customers, we wouldn't be having this conversation.

[mhuisking]

Biot, Could you post that to the Washington Post story comments? It might be helpful to others reading the story there.

[tekalon]

A bit nitpicky on one portion over an otherwise good analogy. If they library is funded by a city, the list of employees and their salaries are public knowledge. I use to work for a small town library in high school. I could see all of my high school teacher/staff information along with co-workers and any other town staff salaries in the town record (publicly displayed in the library itself). Of course, what you may do with the information is another thing.

[lolwutf]

OH MY GOD ARE YOU SERIOUS.

[jlgreco]

Enjoy: http://www.mercurynews.com/salaries/bay-area/2012

[tekalon]

I thought it was funny itself. It did make one teacher uncomfortable -When the class was pestering them about salary,I mentioned the information was available publicly to the class (not that any of them would have gone to check). It does have its uses. Their salary is paid for by taxes. People want to know what their taxes are paying for (especially since education in the town was debated hotly for different reasons).

[PhasmaFelis]

I have heard that America's bizarre obsession with keeping your salary secret is not shared by rest of the world. I haven't checked myself, though.

I'm deeply suspicious of the "tradition" either way since working at a place where it was actually a policy violation to tell a coworker what your salary was. Because then they would know if they were getting stiffed, and they might ask a raise.

[jlgreco]

I have friends who make somewhere in the general neighborhood of several times less than I do, and other friends who make likely as much as twice what I do.

The result of having a wide range of salaries in your social circles is that salary becomes taboo. There is little good to come of talking about it with non-coworker friends, somebody is just going to end up feeling bad, or jealous, or self-conscious, or asked for a personal loan... Even more closely guarded than salary is personal worth, for many of the same reasons, and more.

If this taboo doesn't exist outside the US (and I rather doubt claims that it really doesn't), I would nevertheless refuse to participate in non-anonymized discussions about salary in those settings. What good could come of it?

This taboo carries over to the workplace and into interactions between coworkers who arguably could benefit from discussing salary. If it were born just from employee handbook rules, then nobody would respect it. There are plenty of other rules in those things that nobody reads.

[nicholassmith]

Example is good, but not quite right as they weren't asking a neutral resource. The librarian (let's switch for clerk) was told that if someone looking like X came in and made a request they were allowed to hand over a Y to them, so each time the `You` came in you had to wear a disguise that convinced the clerk you were actually `X`.

AT&T should be rightly mocked for their poor security, but weev wasn't just stumbling through data, he'd made good attempts to impersonate the setup the server wanted. He'd put a pair of glasses and a funny moustache on and the server was alright with it, which is definitely ridiculous.