SignpostMarv's Blog

So a friend of mine sent me a link to one of Prok’s latest blog posts- “The Evils of OpenID“-, probably expecting me to agree that Prok is being a raving loony.

Unfortunately, there are some things in the post that I do agree with.

Prok’s points:

I won’t be responding to all of Prok’s points, just the first few:

1. OpenID is hard to use and misleading in its claims.

I have to agree here. And I’m not talking from the end-users’ perspective. I’m talking from a developer’s perspective.

My SLOpenID project- using OpenID to allow Residents to authoritatively log in as “themselves” has been through three different versions in it’s history. SLOpenID v1 was a heavily modified version of a now discontinued “standalone server”. SLOpenID v2 was a slightly tweaked distribution of WordPress MU. SLOpenID v3 totally abandoned the concept of attempting to be an OpenID provider (which is something that Linden Lab should really be doing themselves).

I abandoned the idea of trying to be the OpenID provider for Agni, mostly because there wasn’t enough demand for it, and partially because some changes in the WPMU platform “broke” the modifications I’d made that were necessary in integrating things in-world.

Operating software that accepts OpenID logins (a “relying party”) is almost as complex than operating an OpenID provider.

The problem lies in that you have to use some beefy math libraries (GMP or BCMath- at least on the PHP platform) in order to bring support for OpenID out of “dumb mode”- some 3rd party providers won’t log in if the relying party is stuck in “dumb mode”. In order to get these installed, you have to either contact your web host and ask them to make the libraries available- or make them available yourself.

For a total beginner to compiling software, the prospect of compiling PHP from scratch just so they can use this one feature will scare them off. For myself, I’ve had persistent problems getting the compile to run on this blog (though rarely is it a problem on SLOpenID/swslr), so even if you know how to get the libraries available, it doesn’t guarantee that you’ll be able to use OpenID.

2. OpenID is decentralized and therefore not the same everywhere.

This has caused me persistent problems on swslr. Not because of OpenID in general, but a specific, optional feature that’s touted as a means of “making it easier for end-users”- directed identity- the idea that you only have to put in “yahoo.com” anywhere you see an OpenID login.

Because of the existence of this single feature, I can’t currently rely on the OpenID data to allow people to quickly switch between their accounts, since it would allow anyone with a yahoo account to login and take control. I’m sure if I delved into the specs and libraries, I could figure out a way of supporting it, but given that the XMN stuff I’ve been working on allows people to “opt-in” with regards to linking their accounts (with the OpenID method, they could accidentally tell the server they own another account without meaning to), I don’t really have the inclination to go investigate too deeply.

Another issue I came across that Will Norris helped me out with was that the various libraries used didn’t treat URLs the same way. Some OpenID providers accepted the URLs, while others reported a vague error (to which I never received any useful help). The fix was relatively simple- just use rawurlencode() instead of urlencode(), and add in some mod_rewrite rules to enforce “+” for spaces instead of “%20″.

3. OpenID accepts other services’ log-ons, but would I give my email password to everybody?!
The system isn’t at all immune to abuse by geeks who might like to track you if they hate what you say. Christiano who raged at me for criticizing his IP captures and captures of email addresses as they came through his system screeched that the former were never used to track people to their actual homes and the latter weren’t saved but discarded. But both those pieces of info, when simply culled out and reviewed and matched against posters you don’t like, can lead you to out alts, for starters (remember the Phaylen scandal), and track people close enough to their homes to be a nuisance

I’ve always had a relatively paranoid approach with regards to the data I accept on my “public” projects- OnXiam for instance, doesn’t provide any means of “proving” that a given person owns a particular account, or is who they say they are etc. If someone wants to say they own two accounts via the XMN data, they have to log in as both avatars and say “hey, that other avatar is mine”. This would then allow the person to log in once, and “fast switch” between the different accounts- without having to log out or use multiple browsers.

Requiring explicit action on both accounts leaves out any worries that the user will accidentally expose their private alts to the world. If I were to use OpenID, the process would be more automated- just a simple SELECT/JOIN query. However, if the user associated the same OpenID with their “public” and their “private” accounts, they’ve inadvertently made it possible for me to see the private activities they get up to.

With great power comes great responsibility. I shouldn’t have to put the people who use my site into the position where they have to trust that I won’t do bad shit with their data.

My own issues with OpenID

The major feature that’s been touted about OpenID is that if you own your own domain name, you can run your own server. The average internet user wouldn’t be able to do this- previously because it meant setting up separate software to do the job. More recently, people can install a plugin on whatever blog software they happen to use- but they’d still have the issue of needing to make those math libraries available. This leaves you with the option to delegate your OpenID out to another provider, which actually relates to Prok’s 6th point- that OpenID isn’t as decentralised as it’s made out to be, since most people will gravitate towards a few well known, existing platforms (LiveJournal, Blogger, WordPress.com, even the bane of web design- MySpace), leaving only “the geeks” to utilise the actual decentralised provider features.

In the current sea of login systems, OpenID only theoretically makes things easier. You can enable millions of people to log into your software by using fewer (albeit more complex) software libraries/procedures. The only alternative would be to support the ability for people to log in with their Google account (via AuthSub), with their flickr account via flickr’s authAPI, and I’ve even noticed Facebook login support popping up on nearly every other site I stumble across. While that does mean you need to maintain another set of code for each additional service you want to enable logins for, these “non-standard” methods are typically easier to support- not requiring people to recompile PHP from scratch for example.

</end>

OpenID does still have it’s uses- I do still strongly believe that Linden Lab should start acting as an OpenID provider, as it would give 3rd party developers an existing set of tools to work with that would allow Residents to log into a wide range of SL-centric websites, without needing to go through the current paranoid methods of going in-world to prove you own the account you want to use (the alternative would be for Linden Lab to acquire each and every website that’s specifically targeted towards Agni Residents so that they don’t have to :-P)

OpenID is currently very much a double-edged sword, it has good and bad points, though its still very much a pain to learn to wield correctly.