Naughty NSA was so drunk on data it forgot collection rules

Re: why you think URL's are content?

http://www.supermarket.com/shopping.php?username=bloggsj1975&authenticated=1&aisle=fruit&product=oranges&quantity=3

Yes it's a shit way of writing things but it happens.

The content is obvious. User jbloggs1975 bought 3 oranges from supermaket.com

What it is not (simply address info): Anonymous person from IP address aaa.bbb.ccc.ddd went to www.supermarket.com and accessed their online shopping section.

Re: URLs are Content

@AC

First, one AC asking for responses to another AC's questions/points is a bit of a meal but anyway . . .

I am not going to enlighten anyone about why - or even if URLs are 'content'. What I am going to do is use this post and the ones you are responding to as a perfect demonstration of why I said in a previous comment that we shouldn't be talking about 'data' vs 'metadata' and 'content' vs 'addressing information'.

It's a distraction. Evidently.

There is no one objective definition of what 'content' is because it is dependent on what you are referring to. The contrast to 'content' is usually 'presentation', in that you split out which components are which. Sometimes this is elementary; a novel is easily split: the text is content but whether it is a hard/soft-cover or digital copy is firmly 'presentation'. So to is the choice of binding used (if a hard copy), the fonts, the page margins, pagination, etc...

Even there, however, you run into questions that don't have a clear answer. Is the table of contents to be considered 'contents'? What about the index? If it is a non-fiction work, what about the bibliography? Chapter names and numbers? And what about the title? Mixing the terms up a bit, the title of a book could well be considered 'metadata' but I think it would be hard to argue that it would not also form part of the creative work and thus be 'content'.

If we look at a URL, how does that relate? Is it 'content'? It's certainly not mere presentation.

Drawing from the example case, avove, a URL is the equivalent of a book title. In that way, your argument that just reading a URL doesn't provide automatic knowledge of what content was read by the user can be investigated. It is true in the case of a book as well - just knowing the title of a book someone has read does not bestow automatic knowledge of the content read, unless one is already familiar with the book.

The point people are making, however, is that knowing the URL visted allows someone - 99% of the time - to find out what was being accessed, just as knowing the title of a book someone read allows you to find out what words they read.

Of course, you can't prove from a URL that someone read a specific paragraph or looked at a specific picture but accessing the site alone may well be enough, just as having a copy of Mein Kampf (couldn't think of a better example on the spot, sorry) on your bookshel could weigh into an investigation, regardless of whether you have read it or not. After all, how do you prove you haven't read it?

How do you try and convince your wife you 'only buy it for the articles'?

What happens in the family court when your (soon to be divorced) wife brings up your Internet browsing history and shows all the pornography sites you have been visiting as proof you have been neglecting her? She cant prove you were watching a specific video or even that you watched any but it doesn't matter - the fact that you visited the sites is enough for the purpose.

Going back to book titles, let's say that a book's title is not content. What about a book that contains a list of books? Are the titles contained inside that book 'content'? On the surface it's the same thing - a book's title, which doesn't contain the text of the book itself. In this instance, I think most people would consider the list of titles to be content. But what has changed? Simple: the purpose of the book.

An easy example of this is a phone book. My name and phone number might be considered 'metadata' but gathered together in big directory for the express purpose of matching a name to a phone number, that same information must be considered to be the 'content', or, the 'data'.

But the above is really just me making my point in presentaion as much as content - the argument is silly, lengthy and without any resolution. I don't submit the above as anything more than a demonstration of just how pointless it is to get bogged-down arguing about something that, in the end, comes down to how we define a bunch of words that only have any meaning in reference to our subjecive intepretations of rather abstract concepts.

It's doubly-pointless because the government's definition seems to be:

Metadata

pl. n

1. Addressing information.

2. Anything else we want to record about our citizens.

Re: URLs are Content

Sigh.

pierce writes: "URL's CAN be the address of static content.. but they also can be an API, passing data as POST or GET arguments."

HTTP URLs can include a query-string. Since the HTTP GET method does not include a message-body, the query-string is the usual way to pass parameter data to the server. But the user agent can use a query-string with any method (except possibly CONNECT, since the syntax of that method isn't defined by RFC 2616).

By convention, web browsers processing HTML forms that use the GET method will URL-encode the form field data and append it to the action URL's query string. Parameters for HTML forms using the POST method are sent in the message-body, not in the query string. But the method is irrelevant to the presence of a query-string in the URL, from HTTP's point of view.

Whether the presence of a query-string makes a URL an "API" is debatable. The latter term is not, of course, defined by RFC 2616.

AC writes: "Because technically speaking, HTTP GET request was not designed to be used for posting data or API, it is even written in the specification."

Citation, please. No, don't bother; I'll tell you what RFC 2616 says. It says that the GET method is both "safe" (9.1.1) and "idempotent" (9.1.2) - terms of art in this context. Safe methods SHOULD NOT have user-visible side effects¹; idempotent methods can be replayed without additional side effects.

Nowhere does RFC 2616 say that GET cannot "be used for posting data or API". An idempotent method can "post data" (presumably - the term is not defined by 2616) as long as multiple invocations don't have additional side effects. A safe method can "post data" as long as the side effect isn't user-visible.

And whatever "API" might mean in this context, it almost certainly includes operations that are not only allowed for safe methods, but are in fact commonly achieved by them. I use APIs all the time that include operations without side effects.

More broadly, though: the query-string has no special status in this regard. It's intended for passing parameter data, but any part of the URL that's visible to the server (at least the abs_path and query-string, and possibly the entire URL) can be treated as whatever sort of data the server likes. There are conventions for using other parts of the URL as input, for example the use of PATH_INFO in the CGI/1.1 specification. Nothing about query-strings or any HTTP method magically turns an HTTP request into an "API". In isolation, all HTTP requests have the same status; it is the server's interpretation that distinguishes between simple retrieval and operations with other side effects.

¹That is, side effects beyond retrieving data; 2616 9.1.1 is less specific than it might be on this point, but it's clear what's intended.