Presuming a precursor almost never pans out.

The key is to *nail* the simple case first before worrying about the complex case.

Tantek, on the paucity of OpenID adoption

Item: Ben Ward writes Understand The Web which rambles all over the place, has an egregious grammar botch in the first sentence, but makes some really important points.

Tim Bray, writing on HTML5 and the Web. This is perhaps one of the most apt summaries of Ben I have ever read.

This is why I like you.

Also why I hate you. Somewhere in between lies our friendship.

Ben Ward, on my being a pedantic git.

For existing iPhone 3G owners though, there’s a snag stemming from the fact that the original iPhone – unlike just about every other mainstream mobile from the last few years – was not subsidised by the network carrying it: in the case of the UK, this was O2. The way this works for most phones is that the network pays a large portion of the phone’s cost, in return for the customer signing up to an n-month contract with them. As the Macalope puts it, it’s a loan with the repayments baked into the cost of the service contract. As a result, when the iPhone 3G came out last year, existing iPhone owners had no outstanding loan payments to make, so O2 quite rightly allowed them an early upgrade. This time around, iPhone 3G owners, who had bought their handsets at the lower “loan price”, were somewhat put out to hear that they would either have to wait out their contract (tedious), buy out their contract (expensive, at a minimum of £35/month × 6 months == £210), or buy the new phone on a Pay and Go deal (seriously expensive, at a starting price of £440.40 for the 16GB model). Cue enraged rants, online petitions, threats of defection to other networks and other general foot-stamping.

In response to (or possibly anticipation of) these complaints, O2 have put up an Upgrade FAQs page on their site, addressing the concerns of the irate iPhone owners and explaining why they won’t offer the same terms that they did when upgrading last time. This page, however, did not answer my most pressing question: what are the upgrade terms for upgrading from the original 2G iPhone to the 3GS? There is plenty of spiel about how “the original 2G iPhone was unique as customers bought the device outright” and “contract terms of iPhone 3G are […] the same as for every other handset we sell”, but nothing about upgrade terms from original iPhones. So I popped into the nearest O2 store and asked them directly.

My answer? Exactly the same as if I were upgrading from an iPhone 3G. I would have to wait out or buy out the remaining months of my contract, or pay through the nose to buy the phone outright.

Not entirely trusting this (or perhaps not wanting to), I headed over to Cambridge’s local Apple store and asked them the same question. Same answer.

In short, O2 are not offering early upgrades to 3G owners, for which they give perfectly valid reasons. They are also not offering early upgrades to original iPhone owners either, for which the originally stated reasons no longer apply. The only reason I can think of that applies is “because we can; because you signed a contract, and we know you’ll probably be staying with us anyway”. I honestly can’t see how this makes economic sense from O2’s perspective: there are no loan payments to recoup, and original iPhone owners will have an absolute maximum of seven months left on their contracts (I don’t believe there was a 24-month contract available for the 3G). Given that they are turning up asking to sign up for up to two years, turning them away and pissing them off in one smooth motion seems to be a very bad plan.

For some reason, I have to say I’m feeling remarkably sanguine about the whole affair. Sure, I’d love to have a beautiful new iPhone at a price that isn’t batshit insane, and I’d love to have it right now, but I wouldn’t have signed up to my original 18-month contract if I wasn’t willing to serve out an 18-month contract. So I’m not incensed at the prospect of waiting until September or October to get a faster, shinier phone with faster, shinier internet access, a faster, shinier camera and a compass which, while not noted for being fast, certainly looks pretty shiny. I’m just a little disappointed that O2 haven’t thought to – or have decided not to – extend the same courtesy to original iPhone owners this time around that they did before. There’s a possibility that this will change at some point between now and September, and that I’ll be able to upgrade, but I’m not holding my breath.

What it hasn’t offered me, at least until now, has been the ability to sign on in invisible mode. When you quit, Adium remembers the status of each of your accounts, and returns to that status when you next launch the program. Very useful, unless you want to sign on invisibly without everyone on your contact list seeing you online for a joyous but fleeting second.

There are several solutions to this problem, some more pleasant than others. There are solutions involving writing AppleScripts, there are solutions involving setting yourself into invisible mode before you sign off (although, as Ryan Tomayko points out in an otherwise unrelated article, The Thing About Git, solutions which involve the words “you should have” are dangerous things). None of these were good enough for me.

Today, after a bit of poking around on the Adium bug tracker, I found the solution I needed: if you hold down the Shift key when you launch Adium, it starts itself up but doesn’t connect any of your accounts. You are then free to select invisibility at your leisure.

To clarify that statement, I don’t like seeing passwords. A row of asterisks is fine: perfectly happy with that. A row of little black circles is even better: after all, it’s prettier. But looking at a monitor, sheet of paper or Post-It note and seeing a password staring back at me sends a little shiver running down my spine. Some cultures are reputed to believe that taking a photograph of someone steals a little piece of their soul; I tend to think much the same about writing down someone’s password. “Keep it secret”, as they say; “keep it safe”.

This, of course, is pretty much the standard geek attitude to passwords: they are to be guarded with one’s life. Offer a geek a Mars bar for their password, and they’ll offer you an angry stream of verbal abuse. Or possibly a lecture on social engineering and user account security. Knowing most geeks, it’ll probably be somewhere between the two.

All of this leads up to a discussion of two things: the OAuth protocol which aims, amongst other laudable goals, to help safeguard users’ passwords, and the distinctly unnerving trend which Jeremy Keith has christened the password anti-pattern, which really doesn’t.

OAuth?

The problem OAuth addresses is, on the face of it, a simple one: if I am using an application, how do I allow another application to access some amount of my private information, or act on my behalf, without leaving myself wide open to abuse? In point of fact, OAuth is far from the only protocol to address this problem, nor is it, strictly speaking, a new one; it’s more of an attempt to standardise the ultimately similar, but subtly varying, authentication protocols from the likes of Flickr, Facebook and Upcoming, and to tease out a common standard protocol from the aspects they share, while remaining abstract enough to give individual implementers the freedom they need to tailor the system to their own needs. (For the record, when I refer to “OAuth” in the remainder of this article, I most likely mean “OAuth and the similar protocols on which OAuth is based”.)

Much as the problem is ostensibly simple, OAuth’s solution is also based on a simple premise: keep control as close as possible to the user. When an application wants to access your account (a “Consumer”, in OAuth-speak), it first asks the application holding the account details (a “Service Provider”). The consumer then directs you to the provider’s site, where you get to authorise the access. There’s a whole swath of cryptographic gubbins behind the scenes which I don’t yet profess to understand, but that‘s the basic premise of OAuth in a nutshell. So far, so shiny.

Where it gets really interesting is in two of the main implications of this method: granularity and revocation. Depending on the way the provider has chosen to implement OAuth, different sets of permissions can be granted to different consumers. By way of example, you’ve probably heard of Moo and their facility to pull photos out of your Flickr stream and onto business cards. Because of this, I have chosen to allow Moo to retrieve information about my photos, my sets and my tags. They cannot, however, change anything. After all, why should they be allowed to?

Revocation is another nifty consequence that naturally drops out when using the OAuth-style approach. To carry on the previous example, should I ever decide, for any reason, at any time, that I no longer wish to deal with Moo, I can simply log into Flickr and revoke their authorisation. The most notable side-effect of this is that it becomes much less scary to allow another application to poke around in my account, since I know, to some degree, what they can and cannot do, and I know I can stop them at a moment’s notice.

The OAuth site gives two particular real-world analogies for this situation: valet keys for your car, which will only allow the car to be driven a short distance, and credit cards, which you authorise by signing a slip of paper or typing in your PIN, rather than giving the PIN to your waiter and hoping he doesn’t nip over to the nearest cash machine to clear our your account. To use another analogy, imagine you needed someone to come into your house and fix your boiler. Now imagine you could give him a special key which would allow him to enter your house, fix the boiler, make himself the obligatory cup of tea, and nothing else. Then imagine the key would disintegrate once the work was completed. In the real world, this will likely remain, for the foreseeable future, in the realms of science fiction and over-excitable documentaries with “Of The Future!” in their titles; in the world of computers, however, we have it right now.

If only we’d had a bit more of it a few months back.

The Password Anti-pattern

While this is all well and good, it would appear to a pessimistic observer that it may all have come too late. You see, many of the applications with the most useful information either haven’t yet implemented OAuth-style APIs yet, or hadn’t at the time that particularly influential consumers (Facebook being a textbook example) wanted access to said information. Yes Twitter, yes Google, I’m looking right at you. In the absence of such a solution, the consumers adopted the pattern of asking people, on their site, for the username and password on the other site.

I’m not sure I possess the words to describe how mind-buggeringly bad an idea this is. To return to the boiler analogy, the equivalent situation is that you need someone to come into your house and fix your boiler, so you cut him a copy of your house keys. If anyone asked you to do this in real life, you would tell him, in no uncertain terms, where he could go and what he could do to himself when he got there. You would then phone the police in rather short order. This, though, is what you are doing every time you put your username and password for one site into any other site: you are trusting them, not only to be kind enough not to shaft you, but also to be responsible enough and smart enough to keep your password completely secure. At all times. Forever. As if that weren’t bad enough, an overwhelming majority of people who use a particular password in one place will use it in many, if not all, of the other places where they need a password. So your house keys also work for your car, your holiday cottage in the Cotswolds, your office and perhaps even your safe deposit box at the bank. How many people would you trust with a copy of those keys?

Unfortunately, the cat is now out of the bag; the horse has bolted and is prancing happily around in the fields, merrily shitting on everything it sees. People have seen that they can enter their username and password, letting the application they’re using sort everything out for them and, as shown by the reaction to the Pownce iPhone app, many are rather taken aback when required instead to perform an abrupt context switch, and would prefer it the other way. You know, the mind-buggeringly bad way. The “copying your house keys” way. That way. This is a big problem.

Well, crap

So is there anything we can do about it? If so, what? I’ll be honest and say, right here and now, that I don’t know. It could be that it’s a case of saying “Look, we know what’s good for you, so we’re going to do it the right way and you’re just going to have to play ball”. It may be that the number of OAuth-style services will increase over time, and that this will become the “normal way” of doing things. However, if people are given a choice between a service which bounces them off another website and a service where they can enter a password then and there, they would seem to have shown their preference already.

It’s possible that the solution is to educate people, to explain to them why giving someone free rein over your account is a bad plan. It may even be that the nature of the password anti-pattern will accomplish this for us, as a few highly-publicised cases of people having their accounts hijacked may jog the public out of thinking it’s something that happens to Other People. It’s not a nice way to move things forward, but if it serves to make the web a safer place, it just might be worth it.

It may even be that we have to give people the choice themselves: security-conscious users can use an OAuth-style approach, while those for whom convenience is an absolute priority can use their username and password and accept the risks. Would this work as a stop-gap solution? I don’t know, but I wouldn’t hold my hopes too high, given the laziness of developers, the tightness of deadlines and the paradox of choice. Give people a choice as to which authentication method they want to use, and a significant number of them will probably just choose to go elsewhere, where it’s simpler.

Whatever happens, this is all happening and this is all changing right now, and we, the developers in the thick of it, hold the power and responsibility to determine how this whole mess situation unfolds. I’m not sure whether that’s comforting, exciting or terrifying. Probably it‘s all three.

In his article, Jeremy says that the password anti-pattern “teaches people how to be phished”. Simon says on Twitter that the password anti-pattern “has taught users to be phished”. I would say at least one – probably both – of these statements is true.

Let’s see what we can do about that.

This week, Ben Ward has been clearing out the London flat that he has been sharing with David Singleton this past year. Tomorrow, he plans to emigrate to San Francisco and work for Yahoo! Brickhouse.

I wish us both the best of luck. It’s going to be interesting.

The majority of the insanity, however, is now mercifully behind me (with the exception of my brand new copy of Bioshock, which seems to feature insanity fairly prominently), so it’s now time to look forward to the future. And to a new experience.

It’s quite a popular topic of conversation: those lucky people who have done it before talk about how fantastic it is, and many of those who have not yet had the pleasure think about what it would be like. Those in this latter category, such as myself, wonder who it’s going to be with, whether we’re going to be any good at it, and of course there’s the worry that it’s going to be over almost before it starts.

Not to mention all the fun that’s going to happen between sessions.

I’m talking, of course, about BarCamp Brighton, at which I lose my BarCamp virginity. As the aspects of last year’s South by Southwest which I remember most fondly were the sense of community and the bouncing around of thoughts and ideas, this looks to be precisely that, without the registration fee or the 12-hour journey time. For those of you who will be attending, I look forward eagerly to seeing you there.

Oh, and I’ve ordered myself a shiny new MacBook: after all, I hear these things can be much more fun if you bring the right toys along.

A certain record label (which, for the purposes of this post, will remain nameless) decided that, as a marketing experiment, they would sent pre-release copies of one of their artists’ new albums (which, for the purposes of this post, will also remain nameless) to people who owned and maintained blogs. While there is, of course, no obligation for the blogger to publicise the album in question, either in a full review or simply recommendations to friends, that is clearly what the record label is hoping for. I have no problem with that whatsoever: if I think the album is worth buying, I will – in all likelihood – tell people about it.

However…

When I got hold of my free bit of schwag, my first act was to rip it into iTunes: as I listen to the vast majority of my music in the office, and as I don’t really want to cart a load of CDs around with me, having a new album on my iPod as quickly as possible to give it a good few listens through is a Very Good Thing™.

Unless, of course, the record label has misaligned the tracks on the CD with the songs on the album, so that what iTunes thinks is a track comprises half of one song and half of the next. This is not simply a careless mistake: the record label has deliberately broken the pre-release copies of the album to discourage (so I have been told) recipients from sharing the tracks online.

The way I read this is as follows: “We value your opinion, we want you to check this out and tell your friends what you think. Oh, and by the way, we think you’re a criminal”. Not to mention a criminal who isn’t smart enough to get his copy of QuickTime and re-align the tracks to rip them properly.

This is all a terrible shame, as the album in question is really very good: so much so that, had it not come bundled with a free slap in the face, I would have made sure that anyone with a remotely compatible music taste to myself would have known how good I thought it was. Still, I truly hope that enough people take umbrage to provide a valuable lesson for record companies: if you want to market to bloggers, and if you want them to help you, don’t piss them off.

The first of these events is, as those of you who follow the news and know my stance on DRM may well have guessed, is EMI’s decision to provide DRM-free music from the iTunes Music Store. This is a thoroughly welcome decision for my part, and I truly hope to see more record companies and other “content providers” following suit. As a direct result of this, I now have an iTunes Music Store account: I don’t doubt that there are quite a number of other people who have done the same.

The other event which has me smiling is Microsoft’s decision to start up an Xbox Disc Replacement Plan, whereby damaged game discs can be cheaply replaced (£10 in the UK, $20 in the States). While other publishers have offered a service to replace damaged game media for a small fee (under the premise that the gamer is paying for a license to play the game, rather than the media itself), Microsoft’s returns policy up until now has boiled down to two words. The polite version of these two words is “go away”; I shall leave it to you, dear reader, to guess the impolite version.

As the proud owner of a stricken Gears of War disc, I’m very glad to see this scheme come into effect – of course, I would have been happier to see it come into effect before I bought myself a full-price replacement copy, but better late than never.

Do these shifts in policy, both related to DRM and companies deciding not to shaft their paying customers with it, represent a more global shift in corporate attitudes? Are they just isolated incidents which happen to have occurred within days of one another? Or should we just be glad that they’ve happened now, and not worry too much about where it will lead?

I think I’m going to go for the third one.