This article discusses best practices on access control for modern web services, a field for some reason still embarrasingly set back, in relation to the kind and amounts of data we have started to work with through emerging APIs for various services offered all over the web. Your data, privacy and who gets what access to it are valuable resources worth protection seldom offered today. I'm going to ease into the subject by examples of three services,
Blogmarks,
Del.icio.us and
Blogger.
I was just playing around with Blogmarks a bit today, after stumbling on
News Berry, an edited "best picks" feed of
Yukuan Jian's recent bookmarks, which I found very stylish indeed -- the screenshots that sets Blogmarks out from what other community tagging services I am familiar with really add that extra something to the mix.
So I thought I should investigate it, passed by, imported my Del.icio.us account's data set, set up a bit of a test blog, which incidentally got recognized as a splog by the Blogger spam detection, as I imported the day's worth of what was mostly CommentBlogging bookmarks. (Oh, well; if I'm lucky the Blogger people might clear it, I suppose, and if not, I'll try setting it up on some other blogging service. :-)
As I do not want to clutter this blog with more or less autogenerated content, I thought it best to make a new blog, and as I do not want to spread my Blogger login details around, I had to set up a separate Blogger identity for it too. Bothersome, but necessary at the moment, until the dawn of a more fine-grained password system that would allow me (or the entity using it, in this case the Blogmarks sync feature) to limit write access only to one particular blog. I assume such a system might be a bit beyond the short time span of Blogger development, unless things like this really take off and Blogger get appropriately uneasy about lots of their users sharing their passwords with random third parties. Because they well ought to.
I get back to this topic once in a while, because it is important to API designers for systems on the modern web, and few if any get it yet. If you provide a service with an open API, such as the Blogger Atom API, or the Del.icio.us API for managing your bookmarks, you should not only offer
one password that enables the holder to do anything, including erasing your blog or wiping all of your bookmarks. This is the equivalent of the root password, in Unix terminology. Yes, you should offer a root password. But for services such as Del.icio.us, where several typical innovators around your service will only need read access to your data, for importing bookmarks, for instance, you should also offer a different password for a lower privilege level, in this case offering read only access. That way, your users can safely share that password with other services that would feed on data off your repository, knowing that malicious code or system administrators can not perform destructive transactions using your API methods. Since they only have
read access.
In the case of Blogger, the appropriate level of relevant access granularity would on top of full access to all administered blogs, read only or read/write access, also break down on particular blogs, multiplying the number of possible combinations of modes of access to 2N+1 (the number of blogs times read only or read write access, plus the root password used by the human logging in to Blogger to write her posts, or using her preferred post editing tool to do the same).
Bear in mind that this line of thinking is not specific to Blogger, or Del.icio.us, but lends itself to any system on the web offering access to user created data. You can do the math and resituating of the theory to your own case better than I could, I'm sure.
Only the root password needs to (and indeed should) be user configurable and treated by the web interface as a secret hush-hush entity. All other passwords could well get shown in some page view where you go as you need to share data with third party services. You might even offer the user the choice of tagging every password with the name or URL of the service she has used it with, for ease of tracking, and generate new passwords as needed, so every new service used could get its own password for the same privilege level. Add a button next to each to terminate the password's validity, and the user will be able to kill a service she is fed up with or for some reason no longer wants to place trust in, or whatever.
We need to move towards advanced systems for access control like this, as web APIs mature and increasing number of services start to become the bones and marrow of the web, building atop one another, until we will look back on the web of the early decade and smile at the thought of specific sites being called "mashups" for picking up something from one service, joining it with another. It need or should not be hard to grasp by a casual user, though, so don't go too far, making up scary-looking access matrices or similar.
Hopefully, some system similar to the one outlined above will evolve into a de facto standardized way of controlling data flow from one application to the next, so users will not have to face the burden of relearning every new service, as often today. On average, running your own interfaces is almost always the wrong choice. Today you are among the very first to do this, and hence have greater freedom of coming up with something really good. Try going for something really simple, yet powerful. The ideas outlined above may go too far, and may not go far enough. Don't patent your interface and don't mark your territory; both practices limit the likeliness of
your solution being adopted in the larger web community, marginalizing the reach and usefulness of your design work. But be good.
And offer your users the option of employing safe hex with the data you host for them. You only invite trouble tying them down to root access alone. If you would not offer a random third party your root password, why should you encourage your user base to be any less security minded?
