A Strange Definition of Authorized Access

Orin Kerr has announced that he is taking on a CFAA case pro-bono. The case seems to have all sorts of procedural and substantive defects on which I am not qualified to comment, but there is one substantive issue about which I know enough to have an opinion: Do Andrew Auernheimer’s actions constitute “unauthorized access”. Orin Kerr says no. But I think that when you understand the way the Web works, you will have reason to doubt Orin’s conclusion. I will try to explain the technological reasons that make me doubt Orin’s conclusion.

For a longer summary of the facts, go read the blog post’s first few paragraphs. I tend to trust what Orin Kerr says, so I will just operate under the assumption that he is right. But let me summarize just the part that interests us.

There were a number of web pages which one could access using addresses that must have looked something like this: http://example.com/<some_id&gt; or like this http://example.com/page?id=<some_id&gt;. These are called URLs (Universal Resource Locator) and if you have found my blog, you’ve probably seen thousands of things like these. Orin’s client wanted to compile a list of the information provided on each of these pages (email addressees here) so he wrote a program which tried lots and lots of values for <some_id> and visited the web pages. Orin’s argument is simple: whatever information you get when you visit such a page is on the “public internet”. Surely, visiting a publicly-accessible web page cannot be “unauthorized access” or “exceeding authorized access”. That sounds reasonable, but let’s pop the hood and find out what happens when you visit such a web page.

The first thing that happens is that your computer analyzes the URL to find something called the domain name. Here, it is “example.com”. It then uses a directory (the Domain Name System or DNS) to find an Internet Protocol Address. (IP Address or just IP for short) The IP address is like a phone number which allows your computer to call somebody else’s computer over the Internet. (Here, it was a web server run by AT&T) Once that call has been placed and a connection between the two computers has been established, the two computers need to speak a common language. Here, they will speak a language called the HyperText Transfer Protocol or HTTP. (Yes, when you see http:// somewhere, that’s what it refers to: the language the two computers will speak to each other.) Now, your computer will send a message which will ask for the web page and in return, the web server will send the web page which your computer will draw on your screen. Let’s look at what the message sent to the web server will look like assuming <some_id> is 1234567890:

GET /1234567890 HTTP/1.1
Host: example.com

Now, you might feel that this is not much of an argument and it's not. But now, let me show you something else. This is the sort of message your computer will send to Facebook or a variety of other similar sites when they want to get the information in your account such as your private emails.

GET /my_secret_account_info HTTP/1.1
Host: example.com
Cookie: SID=1234567890

Some variant of that is also the way you send your password when you log on. Now, look at the two things above. I just don't see how the difference between the two messages should make the difference between lawful authorized access and unlawful unauthorized access. I just don't think Orin Kerr's "on the public internet" argument can make much sense.

About these ads
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

7 Responses to A Strange Definition of Authorized Access

  1. I agree, there’s not much difference. But they’re both on the public internet, right? Or should be.

    Let’s try another example. What if this were the message?:

    GET /people HTTP/1.1
    Host: example.com

    Someone rings your doorbell, asks you who your people are, and you tell him.

    • PrometheeFeu says:

      “But they’re both on the public internet, right? Or should be.”

      No. Or if they are there is a really big problem. This is the way access to your webmail account, your social networking accounts, your bank accounts etc is controlled. (That or something very similar) You get a session cookie and that session cookie is sent to the server along every request. I think it is clear that somebody guessing your session cookie in order to read your email is definitely unauthorized access or exceeding authorized access.

      “Let’s try another example. What if this were the message?:

      GET /people HTTP/1.1
      Host: example.com

      Someone rings your doorbell, asks you who your people are, and you tell him.”

      Exactly. And that’s why this whole “public internet” business is nonsense. From a technological point of view, there is no difference between authorized and unauthorized access. We have to go to mens rea to differentiate. Did you know or should have reasonably known that you were bypassing some sort of access control restrictions or not? If yes, then you are guilty. If not, you are free to go. The exact way that access control is implemented shouldn’t matter.

      • Going to mens rea doesn’t make much sense: punish people for what they do, not what they think.

        Technologically, you have the wrong idea here: “This is the way access to your webmail account, your social networking accounts, your bank accounts etc is controlled. (That or something very similar) You get a session cookie and that session cookie is sent to the server along every request.” In my browser (chrome), when I’m logged in securely to wordpress.com, there is an image of a padlock in the URL bar and the URL begins with “https”, which means that the connection is secured. Click on the packlock and I can read this: “The connection is encrypted using RC4_128, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.” This technology makes it impossible for any outsider to guess something that will allow them access.

        If someone rings your doorbell and asks for information, first verify his identity. You can’t prosecute him for ringing the doorbell.

        • PrometheeFeu says:

          SSL (HTTPS means HTTP over SSL) prevents eavesdropping on your conversation with wordpress and allows you to verify that you are indeed talking with wordpress. But it is the session cookie which allows wordpress to know you are who you say you are.

  2. Ray says:

    The meaning of authorized within the context of a law does not have anything to do with the meaning of authentication (and / or) privacy within the context of computer security. Think about a physical store. When the store is open, you are authorized to enter the store, but if you go in back of the register uninvited, you are unauthorized. If you are in the building and the store closes and they lock the door on you, you are unauthorized.

  3. Let me try a different tack: you’re focusing on syntax and ignoring semantics. The URL on the GET line is the name of the requested document, and the session id is the name of the requestor. If you walk into an office office and say “My name is Dan Grayson, please give me my secret account folder”, and you aren’t Dan Grayson, it’s fraud. If you walk into an office and say “I’d like to see the secret account folder of Dan Grayson’s”, it’s not fraud, it’s just an unjustified request, despite the similarity between the words used in the sentences.

    • PrometheeFeu says:

      We are largely in agreement here. But consider what you just said. “The session id is the name of the requestor.” The meaning of that part of the Cookie header isn’t defined by the HTTP spec. It’s defined by the application developer. So if we start with the assumption that the application developer can assign semantics to parts of the POST payload or the Cookie header which go beyond the semantics assigned to those things by the HTTP spec, why could the developer not also assign semantics to the URL on the GET line? Or rather since developers can assign authentication-related semantics to URLs (clearly, I can write an application which authenticates users using the URL they visit) why should the law be blind to that fact?

Comments are closed.