But, honestly, is anyone really surprised?

Nick Saber isn’t happy now. Monday afternoon, after lunch, Nick came back from lunch to find out that he couldn’t get into his Gmail account. Further, he couldn’t get into anything that Google made (beside search) where his account credentials once worked. When attempting to log in, Nick got a single line message:

Sorry, your account has been disabled. [?]

That’s it.

Nick sent a message or three to Google for support. He got back this:

Thank you for your report. We’ve completed our investigation. Because our
investigation was inconclusive, we are unable to return your account at
this time. At Google we take the privacy and security of our users very
seriously. For this reason, we’re unable to reveal any further information
about this account.

And that’s it.

Suddenly, Nick can’t access his Gmail account, can’t open Google Talk (our office IM app), can’t open Picasa where his family pictures are, can’t use his Google Docs, and oh by the way, he paid for additional storage. So, this is a paying customer with no access to the Google empire.

Yes, the tools are shiny. The tools are wonderful and productive and helpful and largely state-of-the-art. But you should have a backup plan – a plan B – if you’re going to use online coolstuff.

We are still crawling towards a set of solutions, but we *are* making progress. We need self-hostable apps. We need continuous export in open formats of our data. We need offsite and redundant copies made of the things we create and generate.

We need OpenLifeBits. And we’re nowhere remotely close.

We need DiSo.

We need Tahoe.

Please hurry.

As I wrote over at claimID, we had an incredible few days. There was a new energy in the air this time as interoperability was assumed and a focus on services began to take centerstage. There was a lot of talk about Reputation, OpenID 2.0, and OAuth 1.0. We’ve got the pieces now to begin building compelling applications and services. The business models will be appearing in May at the next conference.

We even had an impromptu OAuth party on Tuesday night in honor of the spec being released. Smarr/Recordon/Wachob/Hammer-Lahav/Messina and myself.

I ran a session on Tuesday morning on OpenLifeBits (thanks to John Panzer for the wiki notes) – and had some excellent feedback as well as discussion around what we should be building to house/manage our personal information. How do we define these bits and who owns this content? Is the information we have housed in the corporate silos our own? If someone else is involved in the creation of a particular piece of data – do we both own it? Do we own it jointly with the company as well? A friend request on Facebook – who’s is that to share? Mine? Hers? Facebook’s? Legally, today, it’s Facebook’s.

I’ll take credit here for two quotes captured on the wiki:

“Stalkers were on MySpace, now Facebook _is_ the stalker.”

A little over the top – but definitely something I feel strongly about. We’re seeing individuals post more and more personal information into corporate repositories willingly and without due consideration for where their information is visible and/or to be used under the terms of service.

I see Beacon as part of a greater slippery slope – we’ll all be living, publicly documented, without recourse.

“It’s a good thing that a bad thing became public” — on FB Beacon.

I feel strongly that Beacon is only the first public-facing version of what these large corporations have been doing for years. It is completely naive to think that companies will give away their services for free to the consumer without trying to leverage what they learn through statistics and demographics to make money. They have to have a bottom line, or they go out of business. Free or not, this stuff costs money to run.

When Facebook shows the public what is possible with their data, at first we squirm and yell, then we realize that we like more targeted information – it becomes less about SPAM and more about information we actually wanted.

The tricky part lies in where that fuzzy line of ‘worth it’ is drawn. Is it worth it for me to give my information to a company so I can get a free burger or $5 off my next box of detergent? For most consumers, the answer is clearly yes – or we wouldn’t continue to see these types of offers.

A quote from Alison Black:

Getting inside people’s decision-making, to inject caution before commitment is likely to be extremely difficult (even with well-understood hazards, such as smoking and alcohol, health educators have difficulty getting their message across). But given that there is a likelihood that many people will continue to act humanly and, therefore, incautiously, there is an opportunity for companies to commit openly to respectful data handling. It may cramp their style for trading data in the future, but as more companies commit themselves to rigorous standards, those that don’t will stand out. Maybe this contrast could pique people’s consciousness just enough for them to ask ‘whatever they’re offering, do I want to hand my data over to them?’

When things like Facebook Beacon force us to realize what is happening behind the scenes, we’re more likely to have informed opinions in the future (which is a good thing). That said, I’m not holding my breath for when we’ll see all these companies go with opt-in as their default. In today’s market, it just doesn’t pay nearly as well.

I have been watching and reading about social network portability and data portability and OpenID and facebook beacon and doc searls’ vendor relationship management and Obama’s call for open formats and Google Drive and Jon Udell’s hosted lifebits scenarios (another post just today).

And Chris Messina has been hanging around this space for a while as well and posted two solid write-ups this past week – on data portability and data brokers.

All of these things seem to scream for some integration, for a system that plays by all the rules and ‘just works’ for the simplest of use cases today, and is ready to scale up and handle the use cases of tomorrow.

I’m envisioning a wrapper – a specification that defines how data should be held and managed for an individual. At first, this should be a single human – later, perhaps organizations or groups of people.

It should be the bucket where our digital stuff lives and the vehicle through which we interact with vendors and each other.

I see three parts – at least for now.

1. Data Repository

This is the heart of the matter. A solid datastore on which to build. This can be a collection of approved document formats – ones that are found to be open and/or well understood. Archival quality stuff here. These need to last for a long time and not be rendered incompatible or unreadable in the future. Really, this is nothing more than a well-defined filesystem or collection of files.

I think it’s most useful at this point to consider the different types of data and simply list the types of formats that meet these criteria. If we don’t have such a format at this time, document the gap and hope that the next few years provide standards that match up.

• ICS/iCal – Calendar/Event Data
• MPEG – Video Data
• Ogg – Video and Audio Data
• TXT – Text, preferably UTF-8
• PDF – Portable Document Format
• ODF – Open Document Format (Word Processing, Charts, Spreadsheets, Presentations)
• vCard – People Listings, AddressBooks
• JPEG – Photographs / Images
• SVG – Scalable Vector Graphics / Images
• PNG – Portable Network Graphics / Images
• KML – Keyhole Markup Language – Mapping Data
• FOAF/XFN – Relationships between people
• OPML – Subscriptions
• GEDCOM – Geneology Data (has limitations)
• PHR/EHR – Personal/Electronic Health Record – complicated, lots of standardization attempts
• APML – Attention / Interest Data
• Financial Data – records, transactions, balances, gets complicated quickly, OFX, GnuCash

2. Data Channels

This is the second piece – getting data in and out of the repository. Open protocols are the key here and it seems we have quite a number of them already being pushed around the live web. Let’s name some and find some gaps…

• XMPP – Messaging – does voice, text, images, this is the Jabber protocol
• HTTP – The web protocol – very handy
• RSS/Atom – Syndication
• OAuth – Authentication between applications
• OpenID – Authentication of Users
• Yadis – Service Discovery
• SMTP/IMAP – Mail protocols

3. Data Management

The third part of this specification would be focused on the management of the data that in the repository and keeping things secure and logged. This is the most complicated part and what makes OpenLifeBits the most different from anything we’ve already got today. Encryption should be at the heart of keeping things well secured (having a brokered encryption market (managing access to secret keys) is another task altogether). Additionally, the dataset should have the capability to be split/merged at will. If you don’t want your medical history stored near your financials, so be it.

• Metadata – describe the data in the repository – using open standard METS
• Permissions – access control – does an open standard exist, Unix permissions?
• Encryption – variety of standards, definitely should have good, strong defaults
• Backup – needs to be atomic, automatic, and recoverable (versioned, even)
• Logging – a full record of what has happened to the life of the dataset

Interfaces

A fourth piece that is really beyond the scope of the definition of any spec is the interface(s) into this data and how a person actually interacts with the data and the outside world via the dataset. A comprehensive list will not be possible to create today, but a solid look at what is available today should force a flexibility of thinking to allow future innovators to do what they do best.

• Mac
• Windows
• Linux
• API
• smartphone
• star trek communicator

Brokered Digital Identity Management

The entire infrastructure/dataset should be portable. Most people will not want to worry about the intracacies of managing this kind of data. We already do it for banking – we get a broker. We outsource and allow experts to manage our stuff for us. We let them worry about the details and there is a marketplace to encourage them to behave well. If they do not, we can move our stuff. This should be the case with our lifebits as well.

Big Picture

There is a large amount of momentum (and cash) behind today’s corporate model (companies own data about you). Inverting the system to be beholden to me and my permission model is not something that will happen overnight. Additionally, the legal questions around ownership of data and the contractual obligations of those you share your information with remain unanswered questions. I have a hunch though that a lot of these types of questions have precedent – just not with the specifics of personal data archives.

As we move into a more digital existence, we will need tools that begin to manage this type of stuff on the personal level. Do you think we can start small and simple and grow into the more complicated models later? Is anyone going to see any value in this OpenLifeBits model besides the geeks among us?

Next week’s IIW in Mountain View should have quite a few people willing to talk about an OpenLifeBits. Please come and find me if you want to hash some of this out further.