BBC Digital Planet podcast featuring OpenID

Update: The BBC has posted a write-up of the report called Easy login plans gather pace.

Digital Planet album artworkI was interviewed by Gareth Mitchell last week about OpenID for the BBC’s Digital Planet podcast.

Our conversation lasted about 10 minutes — of which only about two minutes survived (mirrored here as they currently do not keep an archive of previous episodes).

It was a familiar conversation for me, since the primary concerns Gareth expressed had to do with privacy, identity and the notion that “someone else” could “own” another’s identity on the web. His premise sounded familiar: “Won’t OpenID make my identity more hackable?”

The answer, of course, isn’t that straight-forward, and depends on a lot of mitigating factors. However, the fundamental take-away is that OpenID really is no more insecure than email, and even then, provides a future-facing design that that leads to many kinds of protection that email, in practice, does not.

. . .

I’ve also noticed over the past several years that Europeans harbor much greater sensitivities to privacy issues while Americans tend to concentrate on matters concerning “property” (physical, personal and intellectual). This is evidenced by yesterday’s blow up around Facebook’s changes to their Terms of Service. On the one hand, there’s this weird American outcry against Facebook owning your data (in common, at least) forever. From the European side, it seems like the concern is centered more around what the changes mean to one’s privacy, rather than whether Facebook can perpetually “make money” off your stuff.

I bring this up because it’s immensely relevant with regards to the conversation I had with Gareth (given that he’s based in the UK).

With the current case, I’m sympathetic to Facebook, because I know that this will be the year that people have their “mindframes” bent around new conceptions of personal privacy and control and ownership of data. I believe (as Facebook purports to) that people’s desire to share will overcome their desire for control over their personal data, and that they will gradually realize that sharing will require letting go. It is this reality — the reality of networked data in the cloud — that necessitated Facebook’s change to their terms of service — not some nefarious desire to steal your first born (or your data).

In other words, the conditions and kind of thinking that lead to the backlash against Plaxo known as Scoblegate will cease to exist in the future. Facebook’s change is merely a recognition of this new environment.

It remains unclear to me whether the pundits in this space realize that this shift will occur, and will occur naturally (as it has already begun — consider the integration of Facebook and Flickr in iPhoto ’09), or whether they just want to scream and holler when they notice something that seems astray.

. . .

Last December, I spent time talking to Boaz Sender of HTML Times at length about several of these topics (including discussing the intellectual property issues surrounding many of the technologies that are helping to ensure that the web remain an open playing field) in an interview about Identity in the Network. In juxtaposition to my interview with the BBC, I think this interview gets into some of the deeper issues at work here that must also be considered when it comes to the future of online identity, privacy and data control and (co)-ownership.

Advertisements

What really happened at Ma.gnolia and lessons learned

http://vimeo.com/moogaloop.swf?clip_id=3205188&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1

Citizen Garden 11Larry (@lhalff) and I have been recording a podcast for the past year called Citizen Garden that covers various topics related to the web, technology, and social networking.

Well, given Ma.gnolia’s recent catastrophe, we decided that episode 11 would dedicated to exactly what went down and why, and what lessons Larry has learned that others should heed in order to avoid facing a similar crisis.

I think the basic take-away is that, four years ago, when Larry started Ma.gnolia, your IT options were pretty much to use commodity shared hosting or to do it yourself. If you used Ruby on Rails — in which Ma.gnolia is written — your options were even more limited. And so Larry chose to do it himself.

Today, with services like Amazon S3 & EC2, Joyent Accelerators and Google AppEngine, reliable, scalable hosting is no longer as much a problem, as these services have risen to meet the needs of applications like Ma.gnolia. But these are services that Larry did not take complete advantage of and the burden of taking care of over half a terabyte of data eventually caught up with him.

All is not lost necessarily, and Larry hopes that Ma.gnolia will someday return, perhaps as an invite-only service to start, in order to give him time to earn back people’s trust and scale the service slowly. I’m also confident that he’s decided to completely outsource his IT, taking the lessons from this current situation deeply to heart.

This episode is also downloadable as an MP3.

Where data goes when it dies and other musings

I’ve been wanting to write about Ma.gnolia’s catastrophic data loss last week ever since it happened, but wasn’t quite sure how I wanted to approach it. Larry (Ma.gnolia founder and the sole person who maintained the site) is a good friend of mine, and Ma.gnolia was one of Citizen Agency’s first clients. It’s been painful to see him struggle through this, both personally and professionally, and it’s about the worst possible [preventable] thing that can happen to a Web 2.0 service.

Still, kept in context, it’s made me reconsider some things about the nature and value of open, networked data.

I. How I Learned to Stop Worrying and Love the Bomb

According to Google’s cache of my profile on Ma.gnolia, I had accrued 5758 bookmarks and 6162 tags since I first started using the service August 08, 2004. That’s a lot of data capital to have instantly wiped out. You might think that I’d be angry, or disappointed. But I’m surprising zen about the whole thing. Even if I never got any of my bookmarks back, I don’t think I’d be that upset, and I’m not sure why.

If Flickr went down, I’d be pretty pissed. But Ma.gnolia for me was primarily a tool for publishing — something that I used to broadcast pointers to things that I took a momentary fancy in. There’s a lot of history in my bookmarks, no doubt. In some ways, it’s a record of all the things that I’ve read that I thought might be worth someone else reading (hence why my bookmarks are public), and clearly is a list of things that have affected and informed my thinking on a broad array of topics.

But, the beauty of bookmarks is that they’re secondary references to other things. The payload is elsewhere and distributed. So in some ways, yeah, I mean, there’s a lot of good data there that’s been lost (at least for the moment). But, the reality is that the legacy of my bookmarks are forever imbued in my brain as changes in how my synapses fire. The things that I can’t remember, well, perhaps they weren’t that important to begin with.

II. Start over; the blank slate.

Leopard Blank Slate

With the money I won from the Google/O’Reilly Open Source award last summer, I decided I’d break down and by myself a new MacBook Pro. As I was initially setting it up, I figured I’d transfer my previous system setup over from my Time Machine backup and just pick up from where I left off.

I did this, but once I logged in, the new MacBook lost it’s feeling of newness, and I felt encumbered. What amounted to bit-for-bit data portability left me feeling claustrophobic and restricted. I wanted the freedom of a clean system back; somehow buying a new machine wasn’t just about better performance, but about giving myself license to forget and to start over and to make new mistakes.

I wiped the hard drive and reinstalled OS X with the minimum options. I’ve installed about ten apps so far, and I intend to hold off on anything that I don’t feel an absolute need to install, taking a hint from Ethan Kaplan:

Twitter / Ethan Kaplan: @factoryjoe only install a ...

III. And the band played on

While I love the form-factor of my MacBook Air (now my previous system), the first generation just isn’t fast enough or beefy enough for the way that I use a Mac. It’s great for email and traveling and it really is the machine that I want to be using — just with better performance (though I hear the new models are much better).

Because the hard drive on the thing is pretty miniscule by today’s standards (80GB), I quickly maxed it out with music, videos, photos and screenshots. I was down to about 6GB of space, and OS X crawls when it can’t cache the shit out of everything so I decided to take aggressive action and deleted my entire 30GB iTunes library.

Command-A. Command-Delete. Empty Trash.

And then it was done.

Now, I still need iTunes for iPhone syncing, but now I have no local music store. With the combination of Spotify, SimplifyMedia and Pandora (using PandoraJam or PandoraBoy), I’ve got a good selection of music wherever I’ve got wifi.

The act of deleting my entire music library (okay fine, I do have a complete backup on my Mac Mini media center) was cathartic. All that data… in an instant, gone. All those ratings, all that metadata, all those play counts revealing my accumulated listening habits. Gone (well, except for my Last.fm’s profile).

Of course, it’s not like I had original, irreplaceable copies of these tracks. There are copies upon copies out there. And knowing this, I intentionally destroyed all this data without really worrying about whether I’d ever be able to re-experience or relive my music again. In fact, I didn’t even give it a thought.

But my system sure seems a bit faster now.

IV. Microformats are the vinyl of the web

Vinyl is 4 Ever by Bruce Berrien

The first thing that I thought about when I heard that Ma.gnolia had had “catastrophic data loss” was that Google and Yahoo probably had pretty good caches of the site, especially given its historically high PageRank. The second thing that I thought about was that, since the site was microformatted with XFN, xFolk and other formats, recovering structured data from these caches would likely be most reliable way of externally reconstituting Ma.gnolia, in lieu of other, more conventional data retrieval methods.

Though Larry is still engaged in a full out recovery process, it gave me some sense of pride and optimism that we had had the forethought to mark up Ma.gnolia with microformats. Indeed, this kind of archival purpose was something that Tantek had presaged in 2006:

Microformats from the beginning in my mind are serving two very important purposes.

  1. Microformats provide simple ways of identifying larger chunks of information on the Web for easily and immediately publishing, sharing, moving, aggregating, and republishing.
  2. Microformats are perhaps a step forward in providing building blocks for the longevity of higher fidelity information as well.

In talking with Tantek about this, he pointed out some interesting things about many modern web services, lamenting their apparent lack of concern over longevity. For example, clearly there is a great deal of movement afoot to advance the state of distributed social networking, as evidenced by XML and JSON-based protocols like Portable Contacts and Activity Streams. But these are primarily transaction-based protocols, and archive poorly (another argument for RESTful architectural, certainly).

I would therefore agree with Tantek’s oft-repeated admonishment that services that are serious about their data should always start by marking up their sites with microformats and then add additional APIs to provide functionality (as TripIt did). It’s simply good data hygiene. It’s also about the separation between form and function (or data and interactivity). And with emerging technologies like , people can now build arbitrary mashups from the HTML on your homepage, without even having to know about your custom API.

It also means that, in the event of catastrophe (Ma.gnolia’s case) or dissolution of a service (as in the cases of Pownce, Journalspace or Consumating), there is some hope for data refugees left out in the cold.

When APIs go dark, how do you do a data backup? (Answer: you often can’t.) With public, microformatted content, there will likely be a public archive that can be used to reconstitute at least portions of the service. With dynamic APIs and proprietary data formats, all bets are off.

V. Death and data reincarnation

With both the intentional and unintentional destruction of data recently, it’s given me lots to ponder about in terms of the value, relevance, importance and longevity of data.

I talk about “data capital” like it matters, because I suppose I want it to, and hope that someday it does make a difference just how much of yourself you share with the world, simply because it’s better to share than not to.

And now I’m in this funny situation where, because I did share, and shared openly (specifically on Ma.gnolia), there is the very real possibility of reincarnating my data from the ether of the web. It could just be that all the private data, including messages, private bookmarks and thanks are forever gone, because they were kept private. But those things which were made available to anyone and everyone, through that simple aspect, can be reconstituted by extracting their essence from the caches of the internet’s memory banks.

You think about photographs of people who have died, and of videos and other media. In the past several years we’ve had to start thinking about what happens to social networking profiles on Facebook, MySpace and Twitter of people who are no longer with us. Over time, societies have invented symbols and rituals to commemorate the dead, and often use items imbued with the deceased’s social residue to help them remember and recall and relive.

How do that work when those items are locked away in incompatible and proprietary data stores? How do we cope when technology gets between humans and their humanity?

The web is a fragile place it turns out, in spite of its redundancy and distributed design.

Efforts that threaten to close it up, lock it down or wall it into proprietary gardens are turning the web against us, against history and against civilization and the collective memory. This is perhaps one reason of the primary reasons why the open web is so important to me, and factors in so centrally to my work. As I grow older, perhaps I won’t always have perspective on which things will be the most important to me, but it’s critical that in the future, I don’t inhibit my and my progeny’s ability to access my digital legacy.

Ma.gnolia logoI find it fitting that Ma.gnolia uses an organic symbol as its logo. It has, for all intents and purposes, died.

But there is a silver lining here, and I think Larry intuitively understands: in the Ma.gnolia Open Source (M2) project, he had already sowed the seeds for Ma.gnolia’s rebirth. Though it is lamentable that a such disaster would occur, I believe that creative destruction is absolutely necessary to natural systems, as forest fires are critical to the lifecycle of forests.

I also believe that things happen for a reason and that the soil of this tragedy will lead to a new start and new growth. It’s not accidental that the design of M2 called for a distributed, redundant mesh of independent bookmarking service endpoints. If anything, this situation provides Larry license to start anew, proving the necessity of death, and the wisdom of genetic inheritance and variation.

Inaugural Jelly! Talk this Friday: OpenID vs Facebook Connect

Jelly TalksThis Friday, I’ll be joined by Dave Morin (my good friend from Facebook) at the first ever Jelly! Talk at Joe and Brian’s loft in San Francisco.

If you’re not familiar with Jelly, you should be. I call it the “gateway drug to coworking” — but it really has its own culture and identity independent of coworking, though both movements are rather complementary. Amit Gupta got Jelly started at House 2.0 in New York City back in 2006 (about two months after I initially expressed my desire to create a coworking space in San Francisco). Since then, like coworking, it’s grown into a self-sustaining movement.

Jelly! Talks is an interesting expansion on the concept — where Jellies distributed throughout the world can tune in to hear interesting and relevant talks and interact with speakers, similar to what the 37 Signals guys do with their “Live” show.

This first show I’ll be talking with Dave Morin about the relationship between OpenID and Facebook Connect — and where the two technologies are headed. This should be a pretty interesting conversation, since I’ve long tried to convince the folks at Facebook to adopt OpenID and other elements of the Open Stack (hey, they’ve got hcard already!).

Apparently the event is physically booked up, but you’ll still be to tune in remotely this Friday at 11am PST.

(Tip: The next Jelly! Talk will feature Guy Kawasaki).

What PayPal’s member in the OpenID Foundation could mean

PayPal logoBrian Kissel announced this morning that PayPal has joined the board of the OpenID Foundation as our sixth corporate member, with Andrew Nash, Sr., Director of Information Risk Management and a longstanding advocate for OpenID, as their representative.

That PayPal has joined is certainly good news, and helps to diversify the types of companies sitting on the OpenID Foundation board (PayPal joins Google, IBM, Microsoft, VeriSign and Yahoo!). It also provides a useful opportunity to think about how OpenID could be useful (if not essential) for financial transactions on the web.

For one thing, PayPal already relies on email addresses for identification, and one of the things that I’m strongly advocating for in OpenID 2.1 is the use of email-style identifiers in OpenID flows.

Given that PayPal already assumes that you are your email address, things become more interesting when a company like PayPal starts to assume that you are your OpenID (regardless of the format). With discovery, your OpenID could be useful not just as an indicator of your data resources across the web (essential in cloud computing), but could also be useful for pointing to your financial resources. Compare these two XRDS-Simple entries (the latter is fictional):

<!-- Portable Contacts Delegation -->

    http://portablecontacts.net/spec/1.0
    http://pulse.plaxo.com/pulse/pdata/contacts


<!-- Payment Gateway Delegation -->

    http://portablepayments.net/spec/1.0
    http://paypal.com/payment/

From this simple addition to your discovery profile, third parties would be able to request authorization to payment, without necessarily having to ask you every time who your provider is. And of course no payment would be disbursed without your explicit authorization, but the point is — sellers would be able to offer a much more seamless payment experience by supporting OpenID and discovery.

The pieces are more or less in place here, and with PayPal on board, I think that we’re starting to see how OpenID can be used to smooth the on-boarding process for any number of routine tasks — from specifying where you store your photos to pointing to the service(s) that you use for payment.

I commonly use the metaphor of credit cards for OpenID. One thing that makes credit cards convenient is that the 16-digit unique ID on each card is embedded in the magnetic strip, meaning that it’s trivial for consumers to just swipe their cards rather than typing in their account number. OpenID and discovery, combined, provides a similar kind of experience for the web. I think we need to keep this in mind as we move the state of the art forward, and think about what can be accomplished once people not only have durable identity on the web — but can use those identifiers to access other forms of real-world value (and can secure them however they see fit).

TheSocialWeb.tv #25: “An ‘Open’ Letter to the Obama Administration”

http://www.viddler.com/player/95214990/

Last Friday, Joseph, John and I recorded episode #25 of TheSocialWeb.tv.

Besides shout outs to 97bottles.com and Janrain for their stats on third-party account login usage, we discussed how the Obama administration might better make use of or leverage elements of the Open Stack — specifically OpenID.

Twitter can has OAuth?

Twitter / Twitter API: Call for OAuth private beta participants ...

Twitter API lead Alex Payne announced today that Twitter is now accepting applications to its OAuth private beta, making good on the promises he made on the Twitter API mailing list and had repeated on the January 8 Citizen Garden podcast (transcript by stilist).

It’s worth pointing out that this has been a long time coming and is welcome news, especially following Alex’s announcement to limit Twitter API requests to 20000/hr per IP.

But it’s important to keep in mind that, in light of the recent security breaches, OAuth in and of itself does not, and will not, prevent phishing.

It does, however, provide a way for Twitter to better track the use of its API, and to enable higher quality of service for trusted (paying?) applications and to surface them through a Facebook-like application directory. It also means that Twitter users will have finer grained control over which applications have ongoing access to their accounts — and will be able to disable applications without changing their password.

I’m on the beta list, so I’m looking forward to seeing what their current UI looks like — and what lessons we can extract for other services going from zero OAuth to a completeld delegated authentication model.