A lesson in how not to handle user credential storage

power_beta Social aggregator site Power.com, which allows users to access multiple social networking sites from one interface, got in trouble recently with Facebook.  Facebook sued Power.com for storing Facebook user credentials within their own database and scraping what Facebook called "proprietary data" (i.e. user data).  Facebook and Power.com are working towards an agreement to settle the suit, but the issue was certainly not good for Power.com’s public perception.

MySpace is now following Facebook’s example, and has blocked access from Power.com for almost the exact same reasons.

Power.com failed to do a few key things that would’ve saved themselves from this embarrassing situation, both technical and non-technical:

  • First, Power.com really should’ve engaged with the social networking sites they wanted to support as business partners first, rather than trying to go the renegade route and writing their own interfaces.
  • Assuming that worked, they should’ve worked with those sites to come up with solutions for single sign-on rather than storing user credentials in their own database – storing the user credentials puts undue responsibility on Power.com to keep additional sensitive data secured.
  • If the partnering approach didn’t work, and companies like Facebook ignored Power.com’s requests, Power.com could’ve used the opportunity as a way to promote the idea of the "openness of social networks" and pointed out how companies want to monopolize your social data, etc.  Instead they’re now going to need to fight the possible misconception that they are just a rogue site that shouldn’t be trusted with user credentials.

As someone that uses a lot of emerging social networking sites, I would love to have something that gives me a single dashboard to all of them.  So I would like to see the idea of Power.com succeed.  But having them be an aggregator means they must be trusted to perform that function securely.


Comments are closed.