I was away from home this Christmas and realized that I was missing the highly anticipated Basketball game between the Lakers & Celtics. As we were in a house dominated by women (who dislike basketball) at a ratio of 5-2 the odds of watching the game was at best remote. It was then that I remembered that we have access to AT&T Web Remote Access which gives me the opportunity to remotely program and record programs from the web or my mobile phone. I love this!

I briefly mentioned about SkyDrive (25gb free), however, I am not sure I really realized the variety of free online storage at my fingertips. These are my current crop of favorites:

• GMail\GSpace: 7.3gb (20mb max file size)
• Windows Live: Hotmail - 5gb; Sky Drive - 25gb, Live Mesh (Online Desktop) 5gb; – Total 30gb (sky drive 50mb max file size)
• 4 Shared : 5gb  (100mb max file size)

That is a grand total of over 40gb online storage for free!

I am purposefully not including Yahoo’s claim to unlimited email storage as they specifically search out people who are attempting to use it as online storage and shut them down.

Any other suggestions?

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.

I was completing some Spanish translations this week and got a bunch of errors in QA (missing characters), I basically forgot to convert the characters with accents. This ‘note to self’ will ensure that I will remember to search and replace next time.

I have had a series of posts recently about various, supposedly responsible, Social websites asking for my username and passwords (email), and another post about not so trustworthy sites asking for Live Services passwords. I had resolved to only be concerned about sites that were clearly not taking advantage of the OAuth security pattern, however, it is quite difficult to explain to a layman if a site is using OAuth or taking short cuts of storing your password, logging in and doing some kind of screen scraping. I hope to address this here.

Why do we even need something like OAuth? Well if you are, like me, a user of the something like Live services, but you would love to be able to import all your contacts from a social network like LinkedIn. You have a couple of options, hope that LinkedIn allows you to export the contacts in some common format (csv, xls, etc) and also hope that Windows Live offers a compatible import solution … or … you need an Open secure API which both services can comprehend, vis-a-vis OAuth (I will not go into the details of the OAuth pattern, except to say that it overcomes the need to send user id and password with every request sent to a third party, like BasicAuth).

In short when a site is responsible enough to employ the OAuth open protocol you can gain access to secure areas (contacts, photos, etc) of other sites without spreading your password everywhere. A good example of this pattern can be seen at work in the Windows Live Services. I go through the steps of selecting the import process from LinkedIn, as shown below.

This is the really important part here! After clicking next I am redirected to the LinkedIn web site for authorization. What you should not be doing at this point is adding your LinkedIn credentials into the Windows Live site. This is always a bad idea! To be clear I trust both LinkedIn and Windows Live, I just do not believe they need the keys to each others houses.

Any system that teaches users that it is ok to put passwords from one site into another is really doing us all a disservice, this password Anti Pattern teaches people that it is ok to give away your password. This bad habit ensures that people will be more likely to be caught in Phishing scams the world wide web over. Many social networks have spread like this and LinkedIn is as guilty as any of them.

For me the design of this LinkedIn import page is really problematic. While it appears to redirect authentication for Windows Live and Yahoo,  for Gmail, AOL and the Others options it relies on you putting user names and passwords directly into the LinkedIn site.

I am sure that LinkedIn is being above board and responsible with my information (am I) but this pattern is doing the overall security of the web no good. They are teaching a whole generation of Social network users that this type of password sharing is ok.

What is more confusing is that AOL and Gmail appear to have OAuth implementations (AOL OpenAuth, Google AuthSub) yet LinkedIn seems to disregard this and teach bad habits to its users.

Hopefully in a future post I will go through some code that complies with the OAuth pattern.

Sweet!!