this is aaronland

"everyone was looking at a different camera"

Anti-aliasing

Untitled Caveat #1207092776

Also: Myles is my conceptual device.

One of the reasons I've always thought that OpenID never caught on is simply because not many people self-identify with URLs. Yet. Those of us who live and breath the web long ago understood the attraction (sometimes even the value) of having a personal domain and the benefits of being able to hang services (OpenID, for instance, or some other trust/validation mechanism) off of it. That is still by and large a level of technical engagement with the plumbing that many people may not be able to wrap their heads around. Even when they can, though, most people just don't have the time to care about it. Lots of things have a way of losing out to, say, children.

That's started to change in recent years as Facebook and Twitter, the twin towers of the Broadcast Nation, have insulated themselves in to everyone's lives and taught people to address others in conversation by their username or some service-level equivalent handle. Which is an interesting wrinkle in what will be possible in years to come simply because people are comfortable with the notional construct of an addressable online identity. I doubt that OpenID will ever be more than a good idea that happened too soon but something like it will probably gain a foothold over time.

I mention all of that because Tom Coates and I had a long conversation about custom URLs (generally referred to as "path aliases") on Flickr and ultimately about the larger issue of conceptual devices like addressable identifiers. You know the part where you can get to my photos by visiting http://www.flickr.com/photos/straup instead of http://www.flickr.com/photos/35034348999@N01 (where 35034348999@N01 is a unique ID for my account and a hold-over from the original game that birthed Flickr). Specifically, we were talking about the inability of users to change their path alias once its been created. This is a situation that is further exaserbated or at least made more confusing by the ability of users to change their username (the name that Flickr uses to say "Hi So-and-so!" when you visit the homepage) as many times as they want.

So if you chose the path alias "bobby" when you created your Flickr account way back in the dawn before time known as 2005 but have decided that you'd really rather now be known as "robert" in online circles you are out of luck when it comes to your photos. This is one of those good news / bad news situations.

The good news is that Flickr has never and (if there is any justice in the world) will never break URLs. When you create a custom URL Flickr agrees to make sure that only your photos will appear at that URL. And even if you delete your Flickr account the site won't suddenly start showing someone else's photos when a person visits that address on the Internet.

The bad news is that Flickr never got around to making it possible to change your path alias in a way that preserved the old one and simply redirected visitors to the new URL. I don't honestly remember why we didn't do it during my time but it was probably the usual combination of having too few people doing too many things multiplied by it being a time before the Broadcast Nation had been adopted en masse (read: how many are really going to care enough to change their custom URL?) and it became a feature that kept being pushed down the stack.

If you ask me now, I think Flickr should make it possible for users to change their path aliases. It would involve a bit of planning and a bit of head-scratching to account for the massive big-iness of Flickr and all its users and to account for the edge cases but it's certainly possible.

parallel-flickr lets you change your path alias!

As a way to work through some of the issues I added the ability to create and change path aliases to parallel-flickr. The code first checks a local list of path aliases but also checks Flickr for existing aliases since parallel-flickr is, by design, a very tiny subset of the entire user base. That still leaves open the possibility that a local (parallel-flickr) user might claim an alias that a Flickr user claims in the future. If that (Flickr) user then gets added to the (local) database who gets to use the alias in their URLs?

I opted to give it to the user who claimed it first (locally) because parallel-flickr is a personal backup and if someone's already claimed it that probably means they are an active user. The other user's photos are still addressable using their Flickr ID (or NSID, the 35034348999@N01 I mentioned before.) Which means that the code needs to do some extra hoop-jumping to see if a path alias is shared between users and display some notice to that effect. Which means that the whole project starts to feel a lot like the maze of horrors that was (is) trying to merge Flickr and Yahoo! accounts but there you go. If you disable the path aliases can change feature in parallel-flickr all the localized magic stops and the site just chugs along as a mirror image of Flickr, which means the hypothetical shared path alias will belong to the same user who owns it on Flickr.

The place where Tom and I disagree about changing aliases is how to handle the redirects at both a network and a conceptual level. I was tempted to grossly misrepresent Tom's argument in order to bait him in to finally blogging again but I haven't and if I get it wrong it's because I got it wrong not because of something Tom said. At the network level there are two types of redirects identified by their numerical status codes. (There are actually several types of redirects but we're just going to leave them in the corner for now, as a practical matter.) Status code 301 says "the URL you are looking for is gone forever and the stuff that used to be there lives over here, at another URL". Status code 302 says "the URL you are looking for has temporarily moved over to this other URL".

Tom thinks Flickr should issue 301-style redirects for path aliases that have changed and I think Flickr should issue 302-style redirects (and ignore the temporary part in the semantics of the status code). My argument for 302 redirects is simply that to do otherwise would violate the promise that Flickr makes that URLs don't change. Tom's argument is two-fold. First, that lots of things actually do change, or are impermanent, on the Internet and to pretend otherwise is simply ignoring reality. Second, by not allowing for path aliases (which are "usernames" by any other... name) to be recycled Flickr is further strip-mining the finite natural resouce known as "good" usernames and perpetuating the proliferation of awful usernames like bobby.1497.

I am sympathetic with both arguments although I don't think the first holds weight when we're talking about photographs. I agree with Tom's basic premise that things online should be allowed to die, whether it's by the hand of the person who created them or just because it's probably healthier in the long run to remember that some things in life are transient. I just don't think that applies to photographs, especially photographs that exist on a photo sharing website where people are actively encouraged to share their pictures publicly. They are not the same flights of fancy that status messages, for example, are considered to be. There is the larger issue that if your business is built on the trafficing of things that are meant to be ephemeral then the value of your business itself (to users) is ultimately no less ephemeral. And before you say it, I don't actually believe that, in the end, people will think things like Twitter messages are any less important than photographs but that's a whole other story.

We are hard-wired for photos or more precisely still images (I've got six thousand years worth of claims that "painting is dead" to back up that outrageous claim, by the way) and they come with enough emotional baggage and social triggers that they deserve to be treated with care and thought. At the very least they deserve to be guaranteed some degree of permanence. This is one reason that parallel-flickr mirrors Flickr's URL structure. If the shit ever does hit the fan (I still don't know anything you don't, okay?) then all those Flickr links you've got lying around can at least be kept alive (or un-dead) by replacing "flickr.com" with "my-copy-of-parallel-flickr.com" which is not ideal but is better than nothing.

with apologies to Ed

Tom's other argument is that by allowing users to change their path aliases without also putting old aliases back in to the pool of available names then eventually there just won't be any good names to choose from. On the face of it, this is true. We have twenty years of ugly and stupid usernames at AOL and then Hotmail and Yahoo! and now Google to point at. I would argue this is the function of bad, or at least lazy, UI design more than it is a proof of people's inability to think of a username they want to self-identify with. This is also a hard problem. It is one of those genuinely hard problems that no one has solved and I do not have a handy list of best practices for getting users to think about identity within the constraints of a seemingly finite set of possibilities. On the other hand we have entire languages at our disposal and entire histories of literature and poetry with which to encourage people to think about the act of naming things as something other than just "bob.jones.3327".

Not to mention a legacy of semi-anonymous communities of interest (often weird but usually not creepy) that have been role-playing and choosing names and guises for themselves to indicate that, really, it's a problem people are more than capable of solving. For example, I would totally create a Twitter account for NEWAESTHESTICHULK except for the part where Twitter names can only be 15 characters long...

What I am saying is that it's a problem we haven't ever really tried to solve at scale. There's a reason that everyone has been so eager to use services like Facebook and Twitter for managing user accounts because it means they can effectively punt on the problem entirely. That's all good so long as, in the long run, you understand that you are share-cropping your users and are comfortable with the realities that these companies will always have a knife to your throat. This is, after all, still business.

I sometimes use Twitter as an example not so much of opportunities missed but of opportunities for active encouragement passed by. From a business perspective you can't really fault Twitter for pursuing the Broadcast Nation strategy. It has served them fantastically well and without much coaxing from Twitter itself lots of people have figured out how to take the constraint of a message no longer than 140 characters and use it to make language sing and dance in new ways. There is a fine line between actively encouraging users down a certain path and being overly proscriptive and I could easily be convinced that Twitter badgering users to think about the art of crafting a message, of describing a moment, would just be annoying. Again, that's the hard part but life is short so why not take a stab at solving the difficult things?

But back to Flickr: If Flickr went down the road of allowing users to change their path alias then there is still a valid argument to be made that they should allow a user to willingly jettison a custom URL in to the void. To say: I know what I'm doing and I don't care if someone else's awful and disturbing (or just saccharine) photos show up in the place where my pictures used to live.

The only problem here is that it brings up another really hard design problem that no one has much bothered to tackle: How you convey to people that an action on their part is effectively crossing the point of no return. After the Flickr Commons launched lots of users wanted to be able to give their photos a public domain license (often confusing it with the no known copyright license that Commons photos are assigned which is not at all the same thing). Most people on the team, I think, were in favour of allowing users to say their photos were freely available in the public domain and it certainly wasn't a technical challenge.

We simply couldn't think of a way to really make people understand that once they'd done that there was absolutely nothing they could do to control how someone else used their photos. Nothing. Forever. Always. This was also around the same time that people were starting to discover the goofy-funny-not-really-flattering photos of themselves that they'd given a Creative Commons license because that's the right-and-good thing to do were suddenly being used in national ad campaigns and seeing themselves on posters plastered all over the place. This still happens today. To people who used to work at Flickr.

That's what I mean when I say that photos are quantifiably different.

So, I suppose you should be able to throw an old path alias back over the fence but it seems like a bit of a wasted effort to do so without also trying to crack some of the larger issues that shadow the reasons for doing it in the first place.

I've been thinking a lot about these kinds of conceptual devices, or constraints, and the opportunities they present to nudge and shift the discussion around a topic but it's all woolier than I'd like. I suppose that is their nature, to be fuzzy around the edges in a way that gives people enough of a rough guide to see that there's actually a path forward (rather than a wide open-ended landscape) but without erecting fences so high they block out the sky. It makes things difficult to talk about in concrete terms but it seems to me that this is how you at least try to get out from under the burden of all the common wisdom that's gotten us in to the messes like the one we struggle with around usernames and identity.

We did a lot of stuff wrong during my time at Flickr but if I had to highlight one thing we fucked up it was somehow creating an environment where people started to believe that their photos were not good enough for Flickr. I mean, really, how did we ever let that happen? I was speechless the first time a friend said that me and for the record: It was never part of the plan. How did we ever let people think that there is one measure of photography? How did we let people imagine that a medium which gave the world both Ansel Adams and Garry Winogrand (a photographer who died with a reported 10, 000 rolls of undeveloped film in his studio and who said that every time you take a picture you are hopefully risking failure) and everyone else in between was about any other than the joy and the discovery of the possible, foofy equipment and technique and measures of "good"-iness be damned?

The Red Pill

Since then, the Instagram steamroller has come along and earned its success fair and square by making a thing that is genuinely fun and easy and immediate to use. There's a lot about the larger project that I find problematic but you can not fault them their ability stripping away all the cruft at the intersection of photography and our Interphones. And all it took to get a whole crowd of people who I know and were intimidated (apparently) by Flickr (of all things) genuinely interested again in the act of photography was, let's be honest here, a heavy application of 1970's vaseline-porn filtering to their pictures.

Say what you want about those goofy filters (and I am the last person to call that particular kettle black) but they have been a startlingly good device for getting people to play at taking pictures again.

Dwelling and Staring

(for Slavin)

This is another one of those epically long blog posts, and I barely even wrote any of it. It's also pretty fucking depressing. I think I'm going to go and get drunk and watch videos of kittens after I publish it or maybe just show up on Myles' doorstep and ask for a hug. What follows has largely been my day, for good or bad.

I've been reading P. W. Singer's Wired for War and planning to do a dog-eared blog post, when I finished, alongside Matt Martin's Predator (as in the one he pilots) which I read last month. Then this morning I started reading about United States v. Jones which will decide whether or not GPS vehicle surveillance performed without a court order is a violation of the Fourth Amendment (since, you know, you drive around in public already) so I decided not to wait any longer

After the essay about the Supreme Court case I found myself reading about the investigation in to the sexual assault charges against Dominique Strauss-Kahn which I include here only because the weirdest part of the article is that a huge chunk of the reporting was done by surveillance cameras and cell phone and electronic keycard log files. From there it seemed only natural to finally read the Washington Post's Top Secret America series, end to end.

And by the time I'd gotten through all that Nate had sent along a piece the Post published yesterday on aerial drones in Gaza that might as well be part of Thomas Pynchon's Gravity's Rainbow. Meanwhile, Iran is claiming to have not simply downed, but p0wned, an American stealth drone that looks as though it fell from Batman's utility belt. Good times.

I did also add the ability to filter your faves by photographer in parallel-flickr this morning, so I guess that's something...

Predator by Matt Martin & Charles Strasser

Wired for War by P. W. Singer

Keeping Watch on the Detectives by David Cole

What Really Happend to Strauss-Kahn? by Edward Jay Epstein

Top Secret America by Dana Priest & William M. Arkin

In Gaza, lives shaped by drones by Scott Wilson

Things I Have Written Elsewhere #1322690400


This is a piece titled Airport Timer which was originally published in November 2011 on the Near Future Laboratory weblog.

There's a passage in David Pascoe's book Aircraft where he talks about how none of the airports of the time were prepared for the introduction of the 747. Specifically there was no part of the physical infrastructure of an airport that wasn't overwhelmed by the size of and volume of the "jumbo" jet.

None of the waiting areas were large enough to accommodate the number of passengers getting on or off the planes. Often the planes themselves were too big to fit in the loading bays outside the terminals and the few enclosed jetways that had been in use up to that point were too small to even reach the doors on the planes.

Later in the book he goes on to describe a similar clusterfuck ushered in by the hostage taking during the 1972 Munich Olympics and the decision to install security checkpoints and passenger screening areas in airports. The just opened Dallas/Fort Worth airport was particularly hard hit. Although its design was modular and extensible from the outset (with all the terminals as simple semi-circles that could be snapped together like Lego up to the 10 miles in length) the buildings themselves were too narrow to retain any design or aesthetic after they been cut in two by x-ray machines and the lint trap of people waiting to go through them.

I was thinking about this last month when I had the misfortune of flying out of Terminal 7 at New York's JFK airport. Architecturally, Terminal 7 resembles two staggered butter sticks. The first butter stick is where you check in and is connected to the second "stick" which houses the departure gates by a short flight of stairs. In between the two, just in front of the stairs, is where you go through airport security.

United Airlines flies out of Terminal 7 so at least some of the misery of the security process can be blamed on United poisoning any and everything it comes in to contact with. The rest, though, is a combination of the need for the Transport and Security Administration (and their international counterparts) to indulge itself in ever greater security theater of Broadway musical proportions; the inability of people to imagine any kind of personal efficiency or shared responsibility getting through the line; and a New York City scale "Fuck you, never again" attitude to the process born out of the reality of the 9/11 attacks. All multiplied by the ever increasing numbers of people flying to and from, and especially to and from New York City.

There isn't much to say about the other terminals at JFK. Both Terminal 4 and the newer addition to Terminal 5 are little more than oversized cargo ship containers with drywall and designer handbag shops but at least they are big enough to dampen the indignity of the fear and paranoia that define contemporary air travel. Put another way: Terminal 7 is just too small and the security line is where everything grinds to a simultaneously depressing and rage-inducing halt and forces everyone to in to a shared despairing for all humanity, all the while with too little space to comfortably take off your shoes.

Untitled Intimacy #1076031825

So I made a website: http://airport-timer.spum.org

Airport Timer is a simple web-based stopwatch application to record how long it takes to get through security at the airport.

Before you get in the screening line you enter, by hand, the three-letter airport code and the name of the terminal you're in and then press the start button which launches a timer in the background. Then you put your phone (presumably) back in your pocket before you are disappeared for spooking the security agents. When you make it through to the other side you press the stop button which stops the timer and, after a confirmation screen, uploads the airport code, the terminal and the time you spent (measured in seconds) going through security to Pachube. There's also an option to send a pithy message to Twitter.

That's it.

The site uses the Twitter API as a single-sign-on provider but that's mostly as a kind of half-assed throttle on the API that proxies and sends the timing data up to Pachube. Because of the way that the Twitter kids have built their Javascript widgets and because there's currently no place to store the Twitter user associated with a given report in Pachube there's a reasonable argument that you shouldn't need to log in at all. Modulo the part where even Instapaper gave in and forced people to create user accounts on the site. Anyway, you need to log in with your Twitter account.

The sites also uses Pachube as a datastore because it seemed like an obvious place to test the claim, in a networked world, that "every human is a sensor". Pachube's data model consists of three nested pieces: Environments (airports), Data Streams (terminals) and Data Points (individual time through security reports). The first two can be assigned additional metadata (tags, location, etc.) but the data points can only contain a timestamp and a value.

Which makes sense but right away the inability to add metadata to individual data points means that I can't record who just went through security or generate, easily, the "your stuff" style personal reports that people expect from social websites. Arguably Pachube is not a social site except for the part where, in a world where we are all sensors, any centralized time-series service that has humans as inputs will be measured on its ability to abstract the data. Robots may not care (or need) to see all that information bucketed by airport or by Wednesday versus Tuesday but we do.

You could just as easily write a backend for this kind of site using MySQL or Solr. Solr's ability to facet by date and eventually to do nested faceting (for example, to facet by airport and then for each airport by week or to facet by user and then by airport) makes it an attractive possibility but I'm choosing to use Pachube because it is a logical meeting of minds.

There are no "report" style pages for individuals or airports yet. There's actually a lot of stuff the site doesn't do yet. It does not try to retrieve your GPS coordinates automatically or use them to auto-detect your airport or validate that you're really at Charles de Gaulle aiport and not sitting at a coffee shop in Winnipeg. It does not have a magic auto-completing list of terminals for each airport. It does not (and will never) have heat maps.

Some of these things will come with time. I have already imported all of the whereonearth-airport data in to a Solr instance so auto-detection and validation are both more than theoretically possible. Auto-complete for terminals is little more wrapper code around the Pachube API to pull out the titles of terminals (datastreams) for a given airport (environment/feed). But for now, it's just a simple thing to record the data and put it somewhere safe and public.