FriendFeed appears to be a Twitter clone that improves on the original, it allows you and your friends to chat about the minutia of life and get updates about each other regularly (not attractive to me, but it takes all sorts). I was looking through the API documentation just wondering what they may have available and this was the blurb they produced on authentication.

If you are publishing data to FriendFeed or if you are requesting the feed that includes data from a user with a private feed, your HTTP requests must be authenticated.

All FriendFeed users have a Remote Key to provide third party applications access to their FriendFeed. A FriendFeed Remote Key is just like a password, except that it is only used for third party applications, so it only provides access to the functionality defined by the API. Users can easily reset it if a third party application abuses the API.


All requests that require authentication use HTTP Basic Authentication. The username should be the user's nickname, and the password should be the user's Remote Key.

Now this fledgling company is being endorsed by some interesting bloggers, but I think the lack of an OAuth implementation is a real problem. They are getting around it by effectively giving you a public password (referred to as a Remote Key), this is quite separate to your actual password.

There are a few problems I foresee with this approach. Firstly you only get one Remote Key and if you want to stop access to your personal data for one particular app you must reset the Remote Key. Unfortunately when you reset your remote key you actually reset it for everyone and therefore need to update the key for everyone. They could get around this by providing management of multiple keys to multiple third party apps, that way you could cut access to any given app without disrupting others, but who would honestly want to do that.

Secondly this practice still plays into the basic problem of the password anti pattern, even though this is a a public password the level of control given means that this is still the basic user name and password paradigm. Either way we look at this it still better than the Twitter security option, where Basic Auth rules supreme, real account passwords are given out, and session cookies last forever, I will not go into detail about Twitter as this method is appropriately lambasted here.

Technorati tags: , ,

Comment Section

Comments are closed.