dekstop: weblog

Visit my Flickr photo stream for more abstract eye candy.

During the last couple of months I've been using more web-based services like del.icio.us, Flickr, last.fm and others, and while I like the growing availability of web site APIs I'm often wary when testing out the possibilities, e.g. when testing a new client software: They usually require that you hand out your full login data!

Consider this: I like Flickr's ability to group photos into sets, but their current Flash-based Flickr Organizr, to be honest, sucks. It's bloated, and while it imitates native applications in its user interface, it doesn't afford the whole range of operations that a normal native application would offer. You can't, for example, draw a rectangle with your mouse to select several pictures at once, which in my opinion is a crucial function for organizing larger amounts of pictures.

Well this shouldn't be a problem, of course, because I can simply use a native client instead. (That there's currently no native Flickr client with that feature is beside the point -- there are always reasons why a native client makes more sense for a specific workflow than a web-based client. This was just an example.) So I browse their tools page and see that I have two options: a Flash-based "native" application, which I pass on, and an iPhoto plugin, which looks more interesting. I download and install it, and upon inspecting it I find that it requires my full Flickr login data to work.

I'm usually reluctant to give out a password like that; especially to closed-source software. The Flickr client is only one example of many: there's Amua for last.fm, Cocoalicious for del.icio.us, del.icio.us integration in Feedburner, and others. All of those mentioned are excellent applications that usually improve upon certain interaction types with the underlying services, or that enable new types of usage. But all of them require to open up my user account.

I found that .Net client for last.fm pretty lame in this regard: requires a password, and then silently contacts their own server. I spent some time analyzing the traffic with ethereal, and it turned out it was just their update mechanism; but there have been enough scams along those lines that a degree of healthy suspicion seems appropriate¹. I just don't like to give out my master password for any service that hosts my important data, and this is even more true for Flickr and del.icio.us.

As these data service biotopes expand in scope and usefulness, the potential for abuse grows with it. I'm just nervous to give out certain passwords when I just want to test a new client. There's too much value to me in the stored data of these services.

A stolen password can be annoying: anybody with my last.fm login can change my music preferences, and force me to listen to NuMetal and Hippie music. Recovering from this is not that hard, but it takes work.

But a stolen password can also easily become devastating: anybody with my del.icio.us login can delete all my bookmarks. Anybody with my Flickr login can delete all my photos and spam other Flickr users' inboxes.

And I certainly would never give out a password to my MovableType installation just to be able to post with a nicer interface.

There can be value in an account that goes beyond the script kiddie excitement of tagging other people's websites. Think of it this way: Gaining access to thousands of MovableType and Wordpress user passwords. A massive taking over of weblogs. Not scary enough?

Yeah those applications mentioned above are made by nice people, and I'm confident that everybody involved is honest enough not to abuse the privilege of getting my password. But that's not what this is about. This is about principle. This is about me having to rely on the programmers of those applications to take appropriate security measures when storing passwords on my hard drive that I would never voluntarily write down anywhere.

We need to find better solutions to securely connect services so that:

• data can travel via private tunnels (i.e., the generated feeds and data streams are not public)
• there is a connection mechanism that verifies a client, but that does not require you to give out the master login to your data storage (the server)
• the connected clients can still manipulate data on the server for you, but can be restricted in their abilities (this is important!)
• all of those connections can be managed from a central place (usually the server)

And until we're there I'm not sure that I will partake in these new freedoms as much as the market would allow me to.

Footnote: After being sufficiently annoyed about this I gave up and made my own HTML-based last.fm-client instead. No password required.

---