Sunday, October 11, 2009

Fear the Cloud: Microsoft Danger was well named

Maybe the name was intended as a warning.

Microsoft "Danger", formerly independent creators of the Sidekick Cloud-centric phone, died when they destroyed their customer's data. They haven't been buried yet, but they're an ex-Parrot.

Fear the Cloud. Fear any time you don't have full control over a useable copy of your own data, and a proven restore path.

The Sidekick was particularly vulnerable because it cached server data, it didn't maintain a full local instance. Anyone who knows synchronization is hell can sympathize with the cache approach, but the responsibility of the parent company is then immense.

Publicly traded companies don't do well with that kind of responsibility.

Glenn Feishman tells us that sync-based solutions are less vulnerable. Technically that's true -- but ActiveSync-class Push solutions can behave like a Sidekick cache. Depending on sync behavior, lost data on the server may wipe local copies. How many people can then restore an old local copy from backup? (Do you know how to do that for an iPhone? I didn't think you did.)

Be afraid. Be very afraid.

What should we look for?

We should look for a NTSB-like approach that treats Cloud data loss like an airplane crash. We need experts in error to identify the proximal cause, the 2nd cause and the 3rd cause. We need to turn each instance of data loss into a program to avoid an entire class of future disaster.

Failing that, maybe you should print reports of your key Cloud data every few weeks.

Oh, and run from Microsoft as fast as your little legs can carry you.

Update 10/12/09: As a free market alternative to an NTSB equivalent, how about we require corporations who own our data to post substantial bonds? So Microsoft would post a $5,000 bond for every Cloud customer. As long as the they don't blow it the money is theirs. Come the Dapocalypse though their customers get a reasonable pay out and Microsoft is out a few billion. that would concentrate their mind, though it would provide customers with some perverse security-testing incentives ...

No comments: