Liminal Existence

AccountChooser

2012-12-06T00:40:00-08:00

Tim Bray recently posted about AccountChooser, a project that’s come out of Google and made its way into the OpenID foundation. Go read that post first, as this post is explicitly a response (as requested). Against my better judgement, I’m compelled to say something, because damn it, I actually care about this stuff and I think it matters. And I think AccountChooser is a terrible, counter-productive approach to solving the increasingly large problem of “identity”.

The problem, stated succinctly, is “how can we allow users to sign in easily, without requiring passwords?” The existing solutions are, simply: email+password (I’m not going to get into why passwords suck), Sign in with Facebook, Sign in with Twitter, and Sign in with Google. I’m not sure if anything else works in practice (maybe LinkedIn? Does anyone use that? Simon/Nat?). The latter three use open standards, but lack mechanisms for discovery and thus end up with a “NASCAR” sign-in interface. AccountChooser is an evolution of the XAuth idea (which was riddled with bad security problems, updated to address the security problems, but not the fundamental questions). It’s related to Mozilla’s Persona, but uses OpenID instead of Persona’s custom infrastructure.

Preamble finished, I think there are several key issues with AccountChooser, and I believe each one is sufficient to thwart adoption.

Design matters: AccountChooser hijacks your site’s design intent by placing an AccountChooser-branded page in every sign-in interaction. You can customise it to some extent, but the account buttons remain the same. Website owners aren’t going to be happy about giving up this level of control – I’m not, and I won’t implement AccountChooser for this reason alone.
It doesn’t work: When I tried to sign in to Tim’s demo site with two separate Google accounts at the same time, AccountChooser (not Tim’s demo, but actually accountchooser.com) failed. I didn’t even try to do anything weird! This is obviously fixable, but not exactly inspiring of confidence for the future, given that they’ve had well over a year to make this simple and primary integration work.
Browser independence matters: AccountChooser is premised on the idea that people can’t remember anything, and the browser can remember everything for them. Despite having a work computer that’s mine, a laptop that’s mine, a phone that’s mine, and a tablet that’s mine, each of those devices sometimes is used for others’ logins (guests, friends with dead/forgotten phones, coworkers, etc). AccountChooser doesn’t provide an easy path to temporary sign-in, and it demotes the user’s own sense of agency when signing in. Which of my six accounts did I use to sign up to example.com? Not sure? The solution: sign in to each in turn with AccountChooser, because the computer has helped me forget.
It’s run by the OpenID Foundation: accountchooser.com, the necessary gatekeeper domain to make AccountChooser work, is run by the unaccountable, corporate, 90% white, 90% male OpenID Foundation. There’s no option to change this, and there’s no story for why this is OK, or explanation for why it’s not. By centralising identity in a single domain, AccountChooser effectively thwarts user choice, and does so by placing control in the hands of people and organisations who are not user-focused and whom I actively distrust. I’ve made similar comments about Mozilla Persona, but at least I kind of trust the Mozilla foundation, and they have a story for how you don’t need to be stuck trusting a single domain that they own.

There are ways to fix this; most of them involve being smart about discovery and making things easy for users without locking those users in to any one solution. I’m trying a strategy that I think already works well at poetica.com, and I’m still improving it. In fact, most of the issues I’ve had are down to shoddy OpenID / OAuth implementations (and their implementors not listening to their customers).

I remain doggedly hopeful that we can fix all these things.

Response

2012-04-12T00:40:00-07:00

Private Webhooks. Private Feeds.

2011-03-27T16:00:00-07:00

This post is for people who want to be able to subscribe to private feeds, or people who want to be able to communicate from one site to another using webhooks. I’ve talked a number of times on the subject at various conferences, but haven’t posted publicly about the approach.

Thankfully, it’s simple. You can see the whole thing here, in this nice set of slides:

Or, you can look at this diagram that illustrates the protocol flow. Note that all the curl commands needed to make a secure, private connection are included in the diagram.

The goal is to allow crypto-less communication across sites while retaining a familiar user experience. This approach achieves that, I think. What do you think?

Pipe Cleaners

2010-06-24T16:00:00-07:00

London’s not a clean city, as anyone who’s ever spent more than a day there knows very well. The black crap that builds up in your nose after a tube-heavy day is one of London’s most striking features to the new visitor, and apparently it’s not getting any better.

There’s probably an opportunity here:

Paperback Web

2010-06-07T16:00:00-07:00

“The only way to get authors and publishers to embrace this device is to sell 20,000,000 of them. You either become the best and only platform for consuming books worth buying or you fail. And the only way to create that footprint in the face of an iPad is to make it so cheap to buy and use it’s irresistible.” — Seth Godin

This statement is total bollocks. If there’s only going to be one best and only platform for consuming books, it’s not going to be some chintzy app made by Apple or Amazon and without meaningful social features. If there’s only going to be one best and only platform, it’s not going to be a DRM solution, unless something’s changed and DRM is now suddenly viable for books where it wasn’t for movies and music.

If there’s going to be one best and only platform for consuming books, it’s going to be the web. The reality is more complicated, of course, and we’ll probably have as many platforms for reading books as we do types of paper. Those platforms will also have learned from the internet, unlike Seth’s suggestions (which are good nonetheless).

Beautiful Lines

2010-06-06T16:00:00-07:00

Update: This was written just before the iPhone 4 came out, with Apple’s new 326 ppi display. With screens that vary from 75 to 326 ppi (and no doubt, beyond), this stuff matters now. Go and make your sites resolution independent. If you don’t care about the critique of a designer’s blog, scroll to the bottom to learn how to make your site look amazing on all these very shiny new devices.

Typography on the web is ugly. Ragged-right is an abomination, a carry-over from when text rendering was done by Netscape Navigator on 486s with 16 MBs of RAM. Oliver Reichenstein writes at length about how Wired Magazine’s typography looks terrible on the iPad, but his own design blog has some not-so-subtle typographic issues. I’m going to quote Oliver by way of a screen shot:

Oliver’s lines are between 80 and 90 characters long, 50% longer than what he recommends here. While he has clear paragraph breaks, it’s actually impossible to usably increase the font size on his site since everything is done with relative scales — a larger font means that the left gutter grows like a tumor, pushing the text off the right edge of the canvas, while the text container grows, too keeping the line lengths extra long.

More problematically, the iA blog doesn’t adapt to devices with different pixel densities. They have an iPhone-specific stylesheet, but that only looks good for the portrait orientation — flip to landscape, and words-per-inch drops to about one or two. On the iPad, Apple’s reasonably smart scaling saves them, but the margins are horrific:

It’s a little hard (but easier than it should be) to tell that the visual effect of the text running up against the iPad’s right bezel is incredibly distracting, and unnecessary given all that white space to the left. Never mind the fact that the font size is too big on the iPad in landscape mode, and actually a little too small in portrait.

I don’t mean to harp on iA or Oliver — text across the web looks roughly like the visual art equivalent of MS Paint. Hell, this blog is using a fixed-width layout that looks terrible on low-resolution screens without the saving grace of content zoom. The iA site is better than most, but the work of Knuth and Bringhurst and so many others isn’t being honoured.

We can do better.

It’s not hard. The tools we have available to us today are amazing. HTML rendering engines are wicked fast, support letter-spacing and word-spacing and all forms of justification and hyphenation and drop caps and indents, oh my! In the past year, we’ve finally gained the ability to render custom fonts across browsers, basically bringing typography on the web up to L^aT_eX or Microsoft Word standards. Ahem.

A simple extraction of some of the work I’ve been doing with rePublish, here’s an unobtrusive approach to presenting properly sized text for any reading device that might happen upon your carefully written text. Don’t worry about your layout; Any approach is fine, whether fluid or fixed, grid or not. It’s the job of this approach to work around your constraints, making your text more readable and lovely.

First, if you’re not already, drop everything and size all your text in ems. Your text should be 1.0 em, everything else in ems as appropriate.

* { font-size: 1.0em }
h1 { font-size: 1.5em }
small { font-size: 0.75em }

The strategy from here is to determine how big the text needs to be (at 1.0 em) in order to fill a given text with a desired number of characters. In the “olden days”, this was done with rulers and text sizing charts. In the modern era, we’re going to do exactly the same thing, except that we’ll build our text sizing chart every time we want to display text.

To do this, we take a string that will give us the average number of characters per pixel. A lower-case alphabet will do, but a closer approximation takes the letter frequency into account: “aaaaaaaabbcccddddeeeeeeeeeeeeeffgghhhhhhiiiiiiijkllllmmnnnnnnnooooooooppqrrrrrrsssssstttttttttuuuvwxyyz”. Next, we’ll measure how many pixels wide that string is in the default font size:

var sizer = document.createElement('p');
sizer.style.cssText = 'margin: 0;
                       padding: 0;
                       color: transparent;
                       background-color: transparent;
                       position: absolute;';
var letters = 'aaaaaaaabbccc
               ddddeeeeeeeeeeeee
               ffgghhhhhhiiiiiiijkllll
               mmnnnnnnnooooooooppq
               rrrrrrssssssttttttttt
               uuuvwxyyz';
sizer.textContent = letters;
document.body.appendChild(sizer);
var characterWidth = sizer.offsetWidth / letters.length;

The characterWidth variable is an approximate measure of the per-character width in pixels for the default font size.

Next, we need to know how much horizontal space we need to fill. Get out your rulers, and let’s start measuring! The specifics here will vary for every design, but the approach is always the same. First, find the space in which the main body text lives and get its width in pixels:

var contentWidth = document.getElementById('content').offsetWidth;

Now we can find out how many characters long our lines are by dividing contentWidth by characterWidth to obtain actualMeasure. Dividing that by our ideal number of characters per line gives us the relative factor by which we need to scale the default font size. For example, if our target is 66 characters per line, but the current font size produces 85 characters per line, then we need to scale up the font size by 85/66 or 129%.

In order to do the last step, we obtain the current body font size like so:

var measuredFontSize = parseFloat(
                         document.defaultView.
                                  getComputedStyle(document.body, null).
                                  getPropertyValue('font-size').
                                  replace('px', '') );

And putting it all together, we find our desired base font size with the following formula: desiredFontSize = measuredFontSize x actualMeasure / targetMeasure. Armed with that knowledge, we can circle back around and update the base font size:

var actualMeasure = contentWidth / characterWidth;
var targetMeasure = 66;
document.body.style.fontSize = 
               (measuredFontSize * 
                actualMeasure / targetMeasure) +
               "px";

That’s it! No matter what device your visitors are using, they’ll have an easy time reading your carefully written text. Add hyphenation using the unobtrusive (and fast) Hyphenator.js, turn on justification, and you’re publishing texts that have the same careful and consistent rendering exhibited by virtually every paper book published today.

To round out the approach, it’s absolutely possible and desirable to set maximum and minimum font sizes. Large, high density displays may produce oversized fonts if the content area is flexible, and constrained devices will favour very small fonts. For small displays, this is enough since displaying less text on a small display just makes sense.

For larger displays, displaying smaller-than-ideal text will leave more white space or leave more characters per line, which may or may not be acceptable. If it isn’t, there are a number of options; moving to columns might be a good one — this is what newspapers do, to good effect. A 30” high pixel density screen isn’t that far off a broad-sheet newspaper, and a series of columns is a far more appealing idea than a website that forces me to scroll down to continue reading a tower of text.

The simpler option would be to use relative sizes for the content container, sizing in ems rather than pixels, and guaranteeing that your content can reach the ideal number of characters per line. For this to work, you need to key the font size off the available pixels or the device’s native resolution, rather than the area into which you’re sizing text. This blog uses a fixed pixel design, and I’m not currently in a position to rework the design at the moment, but this latter approach is the one that I’d use in the future, and is in effect the technique I use in rePublish to ensure that the text is properly sized regardless of device resolution.

The code to do all this is posted here: https://gist.github.com/428898/e882078f10a06e55fa905a89a6ae65f30331746a

To use it in your site, just paste it into script tags in your template and call it from your onload handler.

I’m releasing it into the public domain, so please modify to suit and share with anyone and everyone. If you create a plugin for jQuery or any other JavaScript framework, please leave a comment here so others can find it.

A Comment, Republished Here for Posterity

2010-05-13T16:00:00-07:00

In-Reply-To: Let’s Implement the Open Pile! It’ll Be Great! by Johannes Ernst.

You’re absolutely right. Try, as a new commenter, to leave a comment on your blog. Seriously. It’s horrendous. Here’s my approach:

Act 1: First, I saw the WordPress logo. So I tried to enter my WordPress username and password. Oops, I guess I shouldn’t have told you that, since now you can dig into your logs and pretend to be me on WordPress.com hosted blogs. When that didn’t work, I thought, well, maybe I’ve forgotten my login info. So, I tried a few other options, none of which worked. I guess you could probably log into a few more sites as me now, assuming you’ve been keeping careful logs…

Act 2: Giving up on the username / password option, but not wanting to go through the login dance for what was now clearly “just your blog,” I tried to use my OpenID login, for which Google has chosen a not-totally-unreasonable URL: http://google.com/profiles/romeda - but, of course, that didn’t work. So I tried again, this time using my experience as a web developer to change the URL to http://www.google.com/profiles/romeda, just in case http://www.google.com was returning something more useful than google.com, or in case your OpenID library wasn’t following a redirect or something. Fail.

Act 3: Now, since I *really* wanted to leave a comment on your blog, I clicked the dreaded ‘register’ button. And, to my delight, I saw that it wanted a username and an email address. Right, because I’m going to remember my username for the WordPress install at netmesh.info/jernst. Ha! Thankfully, I got my first choice. I guess the kids haven’t started lining up around the block…

Act 4: Being a good piece of software, WordPress did not ask for my password. So, off I go to my inbox to retrieve the password, which thankfully is sitting right there. It’s a horrendous mess (‘*QOj9rc8D$%X’ fwiw) and Chrome doesn’t like the idea of neatly selecting it, because it’s not really a word, y’know? I manage nevertheless, and go back to the other tab (whatever did we do before tabs?!).

Act 5: Now I enter my password, eager to make my blog post. Click enter, and *bam*, I’m pushed face-first into my brand-new netmesh.info/jernst WordPress profile page. W00t!

Wait.

Oh, right. I was trying to make a blog post.

Act 6: So, back I go to netmesh.info to find the post that I wanted to comment on. No, wait, wrong page. Rewind. Back I got to netmesh.info/jernst to find the post that I wanted to comment on. The post footer says I’m logged in as romeda (oh, wait, I guess I didn’t get my first choice - why did I use ‘romeda’ instead of ‘blaine’? D’Oh!), so I click on the textarea, and away I go!

Now, Umm, What was I going to say?

Oh, yeah:

Facebook Connect is the best experience for both parties, because chances are the commenter has a Facebook account (and if they don’t, do you really want to hear from them?) so that’s good for the site, and it’s really just one click on that pretty blue Facebook Connect button and then one click to approve the connection (nevermind the privacy implications, pshaw), so that’s great for the user.

But that only works if you trust Facebook. You Dumb Fuck.

So, if you’re like me, and try not to be a Dumb Fuck, you should just skip all the bullshit and use email addresses. That do automagical discovery, thanks to Webfinger. Which is a shitty name, but do you have a better idea? (no really, if you do, PLEASE tell me) Tantek’s called it RelMeAuth; I think we should forgo HTTP URLs altogether for this, simplify, simplify, simplify, and just use email addresses. Whatever happens under the covers doesn’t fucking matter one iota. You start from the user experience and then, as web developers, we make it work. Period.

So to say it again, you’re absolutely right. The Open Pile is a totally useless heap of marketing buzzwords. The only thing that matters is user experience (well, the experience of developers building this stuff matters, too, but it’s a secondary concern. We wouldn’t be in this business if we didn’t enjoy at least a little pain). Except that the Open Pile has some real gems in it, and I very much look forward to mining for them with you next week [at the IIW]!

Facebook Is My New Boatcar

2010-05-12T16:00:00-07:00

Facebook’s relentless drive away from privacy has garnered a lot of attention lately. For those of us who have been working towards building decentralised networks for some time now, the attention heaped upon Diaspora comes as no surprise. They’ve done a fantastic job raising the need for open alternatives to Facebook.

Matt Asay’s post yesterday, Facebook has problems, Diaspora isn’t one of them, argues that being free and open isn’t enough. The end-user experience of social networks is what matters, he says. Because a great user experience isn’t at Diaspora’s heart, it’s doomed to fail. His argument is persuasive and, as anyone who’s ever built a user-facing application knows, it’s absolutely correct.

Here’s the thing: while Diaspora’s aim is freedom, that doesn’t mean that open alternatives to Facebook are all prioritising the same thing. The biggest challenge that Facebook is facing, above privacy, above the threat of falling out of fashion, above up-and-coming competition from Twitter or Foursquare or that-social-network-you’ve-never-heard-of, is this:

Facebook is building a Boat-Car.

Boat-cars seem seem like a pretty awesome idea, but the fundamental challenge of combining a sealed hull with external wheels means that boat-cars will never be able to match the performance or aesthetics of cars or boats. Pursuing the entire social market, Facebook has attempted to adapt itself to every new feature of the social web. They started out as a Friendster-alike that emphasised intentional communities, and did it well, providing elegant social utilities to university students. But since then, they’ve systematically bolted on features in an attempt to build a vehicle that does everything that Flickr, Twitter, Foursquare, Email and IM do, to name a few examples. Increasingly, they’re trying to become a framework for the web in general so that everything a web user does is done through Facebook. Instead of offering a carefully constructed vehicle that offers amazing social experiences, they have a created a clumsy boat-car that can never truly compete with more focused sites.

What Facebook does have, fundamentally, is the social graph. Where Flickr has a careful treatment of photo sharing, Facebook has photo sharing built on an expansive substrate of communities. Where Twitter has an insane ability to capture and amplify the low-level hum of human communication, Facebook has an insane ability to execute at scale unlike anyone since Google. Where Google has an intimate understanding of the flows of data on the web, Facebook has an intimate understanding of how to keep their users engaged. Most importantly, Facebook has hundreds of millions of users, and the network effects are in full force.

While no one will ever be able to overcome Facebook’s advantage on Facebook’s terms, just as no one was able to defeat Microsoft on Microsoft’s terms, it’s downright easy to create better social experiences than Facebook’s. It’s easy to create better tools than Facebook’s. It’s also easy to imagine a better social environment than theirs. Logging into Facebook is for me like walking into a room where everyone I’ve ever met is standing around, talking to each-other. My bosses, my family, friends old and new, co-workers, acquaintances, everyone! It’s like attending a nightmare wedding in hell.

The challenge isn’t social network portability; I regularly fly all the way around the world just to reconfigure my social network and have different conversations than the ones I normally have. I’ll gladly log into a different site if it means I can see just work-related conversations, or just family photos. The challenge is that the only viable place for those activities today is Facebook. Their network effects are of so much larger a magnitude than anyone else’s that creating a new social site without leveraging Facebook’s network is a downright crazy idea. Therein lies Facebook’s weakness, and the weakness of every dominant but “closed” network.

This is where open, decentralised alternatives come in. Instead of relying on Facebook’s social graph, social web tools can be built on top of the one true social network: everyone. Instead of building boat-cars — ugly tools that try to do too much — developers could focus on building the best photo sharing site in the world, or the best recipe sharing site, or the best book sharing site. In this world, if someone wants to come along and compete, they do so on features and execution, without first having to steal away all the users from the site that got there first. We’d end up with better experiences and tools instead of just dominant ones.

Facebook’s tools might be the very best for right now, but it’s frankly ridiculous to think that Facebook will be able to provide either the tools or even the infrastructure for the next five or ten or twenty years of development of the web. The job of serious web developers today is to ignore the siren call of Facebook, Twitter, Apple, Adobe, or any other comers that would define the parameters of the web for them, and instead build the best experiences possible. If you protest, and say that Facebook allows you to connect your users with each-other more easily than any alternative, ask yourself if Facebook’s interface is the best you can imagine, or if you feel closely connected to your network on Facebook (or Twitter, or any “platform” provider), or if your network on Facebook represents all of your social interactions. If the answer isn’t emphatically YES!, then it’s worth your while to consider the alternatives.

Hell, if you work at Facebook and you can’t emphatically answer yes to those questions, then it’s worth your while to consider the alternatives. After all, if you can’t beat ‘em, join ‘em. And trust me, you can’t beat the web, because in the long term, the web isn’t subject to anti-trust suits, doesn’t have financial constraints, and can keep evolving until something works.

Three simple things that browser developers can do today to make HTML5 Apps real.

2010-05-06T16:00:00-07:00

I’ve had this draft sitting around for a while now, but prompted by Tim’s and Ben’s posts on HTML5 and the web as pertains rich applications and such, herewith some thoughts based on fighting with HTML5 Apps in the context of rePublish.

Cross Domain, Already

The largest barrier to HTML5 as a viable platform is cross-domain AJAX. Full stop. If you think I’m wrong or just whining and that I should just use JSONP or CORS, go try building any of the following without relying upon a server-side component and all the privacy, cost, and maintenance issues that such a beast entails:

A .doc editor.
An ePub reader.
An image editor.
A multi-protocol IM client.
A P2P client.

The short answer: you can’t do it. Yes, there are HTML5 Offline Apps which helps in that apps can work offline until they can sync to a server, but it’s not a complete answer. Solutions exist (WRT, Widgets, etc) but they’re for widgets, not apps, and in any event they’re not a single-serving approach. You still need to repackage your app for each new runtime environment.

If we’re going to build applications that read documents in HTML5, we need cross-domain requests. JSONP doesn’t cut it. CORS doesn’t cut it. Downloadable applications don’t need CORS headers in order to make HTML requests; why should installable HTML5 Apps be subject to this crippling restriction, based fundamentally in a stupid policy decision around cookies?

With the advent of the FileAPI, client-side development can finally read local files (though not directories or recursive paths). So there’s that.

Web Protocol Handlers

Once upon a time, when faced with a link like this one: mailto:riley@example.com, the operating system or browser would do the right thing, which is to look up the application that the user has chosen to handle mailto URIs in a system registry, launch it, and create a new message addressed to riley@example.com.

Email links don’t work for me across all the browsers I use, because there aren’t hooks to tell browsers (or the OS) to use a web URL as the handler instead of some application in my path. This is stupid, and based entirely in technology decisions made over twenty years ago. Thinking about the future, for example, wouldn’t it be awesome if Delicious or Digg could register a ”share” protocol handler, so that instead of having a horrible NASCAR mess of social sharing links, we could have our browser fill in the blanks with the site we use — “share this using your preferred tool” rather than “share this with any of these tools you’ve never heard of.”

… and Content-Type Handlers

Likewise, when clicking a link like this one: http://example.com/zipfile.zip, the browser would check the Content-Type header for a mime-type (in this case application/zip), look up the application designated to handle application/zip files, and launch it with the file in question as an argument.

There’s a W3C / WhatWG proposal based on a feature added in Firefox 3 to add both protocol and content-type handlers that can be fielded by HTML5 Apps, but all you get at the other end is a URL - there’s explicitly no way for your HTML5 app to do anything with the URL, because of cross domain restrictions.

Sure, you can refer your app to your server component or build a “native app” for every OS to which you’d like to deploy, but there are a whole bunch of issues that arise if you’re not trying to lay your dirty hands on every bit of your users’ UGC. Privacy, performance, UX, policy, bandwidth, costs; these are all non-trivial factors that are much easier to deal with in the context of client-side applications than they are in the context of a vendor-owned website.

So, Browser Developers

This is the era of platform independent client-side web apps, right? Applications that are web-native, weaving and linking and knitting the strands of information and communication together, doing so using the underlying technology of the web. Cocoa apps can’t carefully represent the sorts of information flows that happen on the web, nor can Windows apps or any traditional desktop app. The conceptual advantage that working in HTML and Javascript has over so-called “native” code is immense.

But, we need tools to build these things. CSS Animations are great, Canvas is amazing, but how about some low-level tools? Mobile Safari already has the “add to home screen” button, why not add something similar to the desktop browsers? “Install this [web] application [with extra permissions]” would be an amazing boost for the web, fill in missing pieces in Tim O’Reilly’s Internet Operating System, and give us some real alternatives to the multifarious app stores that lurk in every corner.

tl;dr: HTML5 Apps need cross-domain requests, protocol handlers and content-type handlers in order to be first-class citizens. Browser developers can and should make this happen, sooner than later.

Identity

2010-04-25T16:00:00-07:00

The web is facing a serious identity crisis. Many have written about it but, having thought a lot about this problem over the past few years, I can’t help but feel that something important has been missed in most discussions.

Aza Raskin cuts to the heart of the matter:

“Your identity is too important to be owned by any one company.
Your friends are too important to be owned by any one company.”

I’ll go one step further, and say that the centralisation of identity is stifling innovation on the web. Kellan recounts a quote from a friend, on the subject of Facebook’s f8 announcements: “Well, [Facebook] gave Foursquare a 6 month reprieve.” This is not a hopeful view.

So what’s the alternative? What’s missing from the conversation? I think it’s important to take a view from the perspective of usability; how are we going to use this new conception of identity? The answer is simple: exactly as we do today. The fundamentals of social networking haven’t changed from day one. There’s a website, you log on, and you add friends so that you can share content with them. This basic model applies to every successful social internet technology, from email to IM to Friendster to Facebook to FourSquare.

Logging On

Logging on is easy. Whether it’s a password, OpenID, @anywhere, Firefox Contacts, or Facebook Connect, the principle remains the same: the user proves to their server that they are a particular individual. In that sense, any protocols or approaches beyond username and password are just icing on the cake. They’re ways to make logging in easier, to increase conversion rates (at least, in theory), but they don’t fundamentally change what we can do on the web.

So once we’ve logged on, how do we add friends?

Adding Friends

This is the part that’s missing from the conversation. How does it work today? Well, you have two options: either you find someone’s profile page and click “add” (which doesn’t work across sites, or if you can’t find your friend’s profile page), or you find other users on the site by entering their email address. Often the latter approach is achieved by the site opening up your email address book and looking for friends in bulk, but fundamentally it boils down to “Find email address of friend, search users database for that email address, add friend.”

OpenID doesn’t help, because I don’t even know my OpenID URL, let alone my friends’ OpenID URLs. The “ID” in OpenID is a bit of a misnomer. OAuth doesn’t help – Twitter and Facebook use OAuth under the covers for @anywhere and Facebook Connect, but that only helps me, the site using @anywhere/FB Connect, and Twitter and/or Facebook themselves. It also doesn’t help us get away from Aza’s point, that your identity remains in the hands of a single company.

The solution, as I said to Tim O’Reilly, is Webfinger. Indeed, webfinger was born out of struggling with exactly this problem of representing multi-faceted identity on the web in a way that can’t be controlled by any one company. The approach is essentially to invert the currently-closed user databases, and put social network affiliation in the hands of the users, in our hands, all while keeping the user experience the same as with current and past social software.

I won’t go into the technical details here, but in essence the workflow from a site builder’s perspective looks like this:

Kate (kate@inktopaper.com) meets Fiona (fiona_z_342@gmail.com) at APE, and the two exchange email (re: webfinger) addresses.
Kate wants to stay in touch with Fiona, so she logs on to her social network of choice (“ZineSpace”), and enters Fiona’s address.
ZineSpace supports photos, microblogging, and calendaring, and discovers via a webfinger lookup that Fiona has a photostream at Sketchr, tweets at identi.ca, but doesn’t share a calendar. ZineSpace uses PubSubHubbub to send subscribe requests to Sketchr and identi.ca on behalf of kate@inktopaper.com.
Sketchr and identi.ca look up Kate’s webfinger profile, and use her published photo to show the incoming friend/follow request to Fiona.
Fiona uses her identi.ca microblog for work, so she declines that invitation, but approves the friend request on Sketchr, and adds Kate as a friend (asymmetric follow) on Sketchr.
Even though she declined the identi.ca request, Fiona wants to keep up with Kate’s life, and has a personal Tweetter account that’s not published on her public webfinger profile. She logs in there and adds fiona_z_342@gmail.com as a friend.
Tweetter sends a subscribe request to ZineSpace (discovered via the webfinger profile) on behalf of kate@inktopaper.com. ZineSpace knows that Fiona wants to see Kate’s microblog posts, so auto-approves the request and sends a reverse-follow request (which is again automatically approved).

Now, five things are important to keep in mind when thinking about this process:

Shareable Addresses are what make this exchange possible. Kate and Fiona can’t be reasonably expected to remember all of their various profile URLs, nor can they be expected to remember each other’s profile URLs. Their webfinger addresses act as mnemonics for their distributed identities.
Webfinger is just a discovery mechanism. HTTP remains the transport mechanism for this approach, which means that everyone can participate.
We have not exposed any personal information about Kate or Fiona, and more importantly, we haven’t exposed any information about Kate or Fiona’s relationships. They can do that if they wish (e.g., by linking to a FoAF or XFN profile from their Webfinger profiles), but the approach doesn’t make any assumptions about what information must or must not be shared.
Subscription = Relationship. The underlying approach doesn’t say what kind of relationship the two are creating, but rather allows protocols or data transports on top of the exchange to do so. Fiona could decide that she doesn’t like Kate’s sketches, or that Kate posts too much, and simply tell Sketchr to hide Fiona’s posts. As far as Kate’s concerned, Fiona is still subscribed, and still viewing her photos. Alternatively, Fiona could send an unsubscribe request to Kate, signalling that the relationship no longer exists. The semantics are up to the application developer at either end.
No Passwords are involved in the exchange. Kate and Fiona don’t need to exchange PGP keys, either, or rely on some complicated “Web Of Trust.” All they need to do is trust the servers they use (zinespace, sketchr, identi.ca, and their email providers); if they can’t do that, then they have bigger problems. This one’s really important, because RSS and Atom were meant to be the future of content exchange. RSS and Atom have completely failed to enable private feeds, because they require passwords to do so. That sucks, and webfinger offers a workable solution to this persistent problem.

Sharing Content

Once relationships have been established, sharing content is entirely up to the individuals and sites involved. Obviously, we need common protocols for this, but we can use Atom and PubSubHubbub, some domain-specific protocol (e.g., Portable Contacts/ActivityStreams), or we’ll figure it out as we go along. Direct or private messages are just special forms of general distribution content (i.e., the subscriber has asked to receive content from the publisher, whether that content was broadcast or is a directed message).

There are a lot of things that I haven’t covered in this post. The technology is simple, but not trivial, and it is still very new. There aren’t yet tools that make this easy (if you’d like to work on building them, contact me!)

Hot Code Loading in Node.js

2010-01-29T16:00:00-08:00

Reading through Fever today, this post by Jack Moffitt caught my eye. In it, he discusses a hack to allow a running Python process to dynamically reload code. While the hack itself, shall we say, lacks subtlety, Jack’s post got me thinking. It’s true, Erlang’s hot code loading is a great feature, enabling Erlang’s 99.9999999% uptime claims. It occurred to me that it wouldn’t be terribly difficult to implement for node.js’ CommonJS-based module loader.

A few hours (and a tasty home-made Paella later), here’s my answer: Hotload node branch.

Umm… What does it do?

var requestHandler = require('./myRequestHandler');

process.watchFile('./myRequestHandler', function () {
  module.unCacheModule('./myRequestHandler');
  requestHandler = require('./myRequestHandler');
}

var reqHandlerClosure = function (req, res) {
  requestHandler.handle(req, res);
}

http.createServer(reqHandlerClosure).listen(8000);

Now, any time you modify myRequestHandler.js, the above code will notice and replace the local requestHandler with the new code. Any existing requests will continue to use the old code, while any new incoming requests will use the new code. All without shutting down the server, bouncing any requests, prematurely killing any requests, or even relying on an intelligent load balancer.

Awesome! How does it work?

Basically, all node modules are created as sandboxes, so that as long as you don’t use global variables, you can be sure that any modules you write won’t stomp on others’ code, and vice versa, you can be sure that others’ modules won’t stomp on your code.

Modules are loaded by require()ing them and assigning the return to a local variable, like so:

var http = require('http');

The important insight is that the return value of require() is a self-contained closure. There’s no reason it has to be the same each time. Essentially, require(file) says “read file, seal it in a protective case, and return that protective case.” require() is smart, though, and caches modules so that multiple attempts to require() the same module don’t waste time (synchronously) reading from disk. Those caches don’t get invalidated, though, and even though we can detect when files change, we can’t just call require() again, since the cached version takes precedence.

There are a few ways to fix this, but the subtleties rapidly complicate matters. If the ultimate goal is to allow an already-executing module (e.g., an http request handler) to continue executing while new code is loaded, then automatic code reloading is out, since changing one module will change them all. In the approach I’ve taken here, I tried to achieve two goals:

Make minimal changes to the existing node.js require() logic.
Ensure that any require() calls within an already-loaded module will return functions corresponding to the pre-hot load version of the code.

The latter goal is important because a module expects a specific set of behaviour from the modules on which it depends. Hot loading only works so long as modules have a consistent view of the world.

To accomplish these goals, all I’ve done is move the module cache from a global one into the module itself. Reloading is minimised by copying parent’s caches into child modules (made fast and efficient thanks to V8’s approach to variable handling). Any module can load a new version of any loaded modules by first removing that module from its local cache. This doesn’t affect any other modules (including dependent modules), but will ensure that any sub-modules are reloaded, as long as they’re not in the parent’s cache.

By taking a relatively conservative approach to module reloading, I believe this is a flexible and powerful approach to hot code reloading. Most server applications have a strongly hierarchical code structure; as long as code reloading is done at the top-level, before many modules have been required, it can be done simply and efficiently.

While I hope this patch or a modified one will make it into node.js, this approach can be adapted to exist outside of node’s core, at the expense of maintaining two require() implementations.

Simple Addressing for the Web, Part 1

2009-05-04T16:00:00-07:00

Addressing is important. It’s something that many people have tried to solve.

I’m interested in addressing because it’s an important piece of web-scale messaging, and of the federated social networks that are an emergent property of verified cross-site communication. In order to communicate with someone, you need to be able to route your communications to them.

The URL is the thing. Except when it’s not.

The URL was supposed to become the way that we negotiated identity. We were supposed to have a “home page,” a place on the internet to call our own. It didn’t quite work out that way, and at the same time as Geocities is shutting down, we’re finally facing the need for a strong conception of identity on the web.

It goes without saying these days that everything we do, everything we interact with, has an associated URL. I can give you my blog URL so that you can read my posts, or my calendar URL so that you can invite me to events. However, for the vast majority of users, URLs aren’t a viable option. Fundamentally, it’s a lack of consistency (or, put another way, unbridled diversity) that makes URLs unusable as identity markers. Take the following URLs as a proof-by-example:

twitter.com/blaine
myspace.com/romeda
flickr.com/lattice
search.twitter.com/search?q=%22Swine+Flu%22+OR+Flu
home.myspace.com/index.cfm?fuseaction=user
blogger.com/post-create.g?blogID=6135683561277543562
amazon.com/gp/pdp/profile/A1GUHSGP27QA4W

All of the above are URLs which I see while interacting with sites on the web. Unlike postal addressing, phone numbers, or email, there’s no consistency. The path part of the domain may as well be line noise in the latter four examples. By association, the pattern used by Flickr, MySpace, and Twitter is a fluke. Beyond that, my username doesn’t match across the three social networking sites, and as such it’s nearly impossible for a friend, relative, or co-worker to guess what my URL is, even given a domain.

I don’t see a way to fix URLs across the web so that we can encourage people to use them as identifiers. OpenID has tried, and the results are nothing short of abysmal.

Back to the Future

If not URLs, what should our new web addressable identities look like? The simplest answer is “like an email address.” They’re universally recognizable. Billions of people have email addresses and know how to use them. All the major IM providers have moved towards email-like addresses as identifiers (gone are the integers of ICQ). Most importantly, email addresses are easy to construct and resolve.

The net result of this line of thought is that instead of @blaine for my Twitter address, I’d be blaine@twitter.com, and on Identi.ca I’d be blaine@identi.ca. I could share my Myspace identity as romeda@myspace.com, and on Facebook I could be blaine.cook@facebook.com.

The problem is that those addresses conflict with an already-existing namespace, specifically email. Which isn’t surprising, but it is problematic. Can you send me an email at blaine@twitter.com or romeda@myspace.com? What happens when you do? Unfortunately, there aren’t clear answers for those questions, and while some social networks might choose to make “Social Network Addresses” work as email addresses, it would be an uphill battle to convince all providers to do so.

Use What’s Already There

I’ve been thinking about this problem a lot lately, and while the approach of re-using email semantics to provide human-readable web addresses/identities is very attractive, the proliferation of addresses (one for each network) and namespace collisions are less than ideal. After having extensive conversations with Alexis Richardson and Tony Garnock-Jones, the general approach for discovery became clear to me, but I didn’t have a more generally applicable form for the addresses themselves.

Eventually, talking over the problem with John Panzer and Breno de Medeiros at Social Web Foo, the solution was there, blazing as bright as the California Sun; Google Profiles means that Google is now providing links to all my social network profiles. They’re also my email provider.

My email address is romeda@gmail.com. If you transform that to http://www.google.com/profiles/romeda, you get my profile data, and away we go. Every email provider these days has a website, and Eran’s LRDD, new on the scene, provides a discovery mechanism that everyone (i.e., every mail provider, even if they’re only hosting static content) can implement in just a few minutes.

This is an important, exciting transformation. Now, with one identifier, I can share all the social bits of myself to anyone I please.

Where are my photos? romeda@gmail.com.

Where’s my calendar? romeda@gmail.com.

What’s my phone number? Look it up with romeda@gmail.com, and I’ll give you permission to see it and store it in your address book.

They’re all the same.

If I want to share a different set of social interactions, say, my work identity, I can give my Osmosoft or BT addresses, blaine@osmosoft.com and blaine.cook@bt.com, respectively. Now just photos of conferences come up, and the calendar that you’ll find is my work calendar, not my social calendar.

Talking about this problem with others unearthed a post last year by Brad Fitzpatrick and EAUT, which were both aimed at solving the OpenID problem, but both take the same approach as the one that I outline here. EAUT seems to have been lost in the swamps of XRDS-Simple, and Brad’s post was probably too early to the races, in true Brad style (if you want to know what’s coming to the internet in five years, just read his blog posts).

With a swift and general agreement-in-principle, there’s been some very positive movement towards promoting this concept as a way to bring the power of strong identity that email provides to the web. John has an excellent post on the subject, and it seems like a name for the project has emerged: WebFinger.

Part Two (coming tomorrow) goes in depth about how this all works on the tech side. Bits on the wire, as Tim Bray says.

Easy Android

2009-05-04T16:00:00-07:00

Let me start by saying that I’m very impressed with Android, and the ease with which I was able to scratch an itch was impressive. The fact that I’m not locked into Apple’s app store world is nice; I don’t know what the specific terms are for Google’s marketplace (I haven’t signed up yet), but frankly I trust them more than I do Apple.

Full Disclosure: at Social Web Foo, Joshua very kindly gave me (and about 50 others) a free Android Dev Phone. He gave strict instructions to actually write something for it, and I probably wouldn’t have bought a dev phone (nor written <shudder> the Java against the emulator), so the fact that I have done so worked out.

I hadn’t written a line of Java before. Shock, horror. It’s just as annoying as everyone always said, but developing for Android with Eclipse is pretty straightfoward. The documentation is good. I started with the basics, and pretty quickly moved to example code. Most notably, the NotePad application that comes bundled with the Android SDK.

Once the Eclipse and the SDK was downloaded and installed, it only took about five minutes to get my first app up and running. Getting a list view of hard-coded data took another ten minutes, and modifying the code to display a different view when one of the items was clicked took about two hours (keep in mind that I was learning Java with the patience of a Ruby programmer here).

The Bad

Honestly, there’s not a lot that I was upset by. Coming from Rails, defining table structures and setters and getters and all the explicit typing is pretty annoying. Cutting and pasting code meant that I had a few mismatched data structure definitions, and the error messages were less than useful, since all that fancy type matching means that when something doesn’t match up in your XML configuration file, Java can’t tell you where to go to fix it. Figuring out where I had mismatched strings in XML config files easily took another couple of hours, which sucked, but it seems like the kind of thing that you’d get used to. Functional brain damage, I suppose.

The Good

Android is a developer’s platform. The way that content, and well, everything is addressed is fantastic. There are hooks for everything, and the tutorials encourage you to do the right thing out of the box. The documentation really only makes sense once you get it, but for the really simple app I’ve been working on, the examples were more than sufficient to get things going.

Basically, every data source is addressable through a ”content://” URI scheme. What that means is that any application can provide hooks (if they know about your data source) to view, edit, or list bits of data. I expose a set of short recipes (from @cookbook) at content://org.romeda.provider.Cookbook/recipes. That means that as long as, say, Tweetie knows that there’s the provider exists, they could add a hook to allow people to add any tweet as a recipe. It also provides hooks for other applications to know when new recipes are published (or, for example, I could tie into a Twitter provider on the phone and piggyback discovery of new updates to that, rather that running my own polling process), in addition to hooks to view, edit, or any action you can imagine.

The best thing about this is that the whole system works the same way. You register an “Intent”, and the OS lets you know when something in the system is relevant. The simplest (but seriously awesome) example of this is if you want to intercept an outgoing call and rewrite the number (or just make the call over a voip stack, for example). You just register your intent to handle ACTION_NEW_OUTGOING_CALL, and away you go. A simple data passing interface lets you receive and attach data to the messages.

The other thing that’s great about Android that I noticed right away is that the default views are extremely simple to use and customize, and they save their own state. Without writing any special code to remember where a user is in the scroll buffer, and without doing any work to remember which view a user was in (e.g., list or item view, edit, etc), the default behaviour is to remember. It’s the embodiment of everything Google’s been doing on the web lately — don’t save, ever, because saving is stupid. Either you’ve published/archived/sent/deleted something, or it’s in a draft form. The draft is implicitly persistent, and avoids the user ever losing work. This is in stark contrast to the iPhone, where Safari’s horrible constant reloading of pages boggles the mind, and burns through roaming data minutes like there’s no tomorrow.

The Code

So it’s not fancy, and it doesn’t even fetch the recipes yet, but I’m posting the code here since it’s pretty damned simple at this point, and demonstrates making an app with two views. I’ll update it as time allows.

Automatic Bootstrapping of rev=canonical

2009-04-12T16:00:00-07:00

Kellan’s work on making URL shortening not suck is great, but killing bit.ly and tinyurl just isn’t going to happen. Sadly for Joshua, this is the way the internet works, and if he doesn’t like it, tough shit.

So far I’ve only seen one site that (awesomely) shortens URLs with rev=canoncial (I’m sure there are more, but I haven’t seen them. So there.) Simon Willison has done some great work on his blog, and throwing http://simonwillison.net/2009/Apr/11/revcanonical/ at Kellan’s shortener results in http://swtiny.eu/EZa. Brilliant!

Except no one will use it, because, well, bit.ly is useful for doing things like tracking how far that link you sent got, and there’s a degree of muscle memory involved. This is the sort of vi-versus-emacs argument that just isn’t going to go away. Also, here’s the same post shortened by bit.ly, tinyurl and this Simon-Willison’s-post-about-rev=canonical specific URL shortener that I just linked to in the previous paragraph. So why fight it? You really can’t win.

There is hope, though. I live in the dark ages, and Blogger publishes my posts as static HTML over SCP or FTP or some other totally inappropriate protocol. Since there’s no <$BlogItemShortURL$> tag in Blogger’s template syntax, I’m completely unable to do what Simon’s done, without migrating to a self-hosted blogging system (contrary to popular belief, not all programmers are compelled to write their own blogging systems (erm, on second thought, ignore twitter)).

Anyhow, it turns out that I can be as cool as Simon, just with one step of indirection:


<link rev="canonical" href="http://bit.ly/?url=<$BlogItemPermalinkURL$>"/>
<link rev="canonical" href="http://tinyurl.com/create.php?url=<$BlogItemPermalinkURL$>"/>

Strike that, Blogger fucking sucks and so I’ve created a shell script that converts a placeholder into rev=canonical links. Man, that was a pain in the ass. Why do I still use Blogger? Anyhow, the point stands if your blogging software doesn’t totally suck and will give you a permalink anywhere in the template engine. Which is probably true unless you’re using Blogger. Ugh.

So this is great. Now my blog posts are rev=canonical™ compliant, and I you didn’t have to change anything at all, beyond shoving a couple of lines of HTML into your blog template. People that use bit.ly and tinyurl are happy, because they don’t need to change their behaviour, and people that use rev=canonical are happy, because they can just by following the links provided for them.

Now of course this doesn’t address two of Joshua’s concerns. First, I still have no idea where my traffic is coming from, because I don’t run my own URL shortener. I don’t want to run my own URL shortener. What I see here is an opening for bit.ly and/or tinyurl to allow me to see the stats of redirects (Dear FeedBurnerGoogle: Please purchase bit.ly or tinyurl or build your own), which they should be able to do easily since all I would need to do is prove that I own romeda.org by sticking some secretly named file at the domain root or otherwise.

The second concern that remains unaddressed is what happens when the URL shorteners go away? Well, we have the same problem on the web. The answer to that was/is The Internet Archive, so herewith The (Tiny) Internet Archive.

Currently it’s just a proof-of-concept. I don’t guarantee in any way that the links posted there will persist. That said, the free quotas that come with Google App Engine allow enough space to store around two million links, and $0.15 per month for every additional two million links, so I’m sure it won’t be a problem. Who knows, maybe archive.org will take it over?

The code that’s up is available on github here: TinyArchive. If you have suggestions, please send them my way or fork the code and send me patches. It was just a pre-coffee morning hack, my first stab at App Engine, and my first Python code in what seems like forever.

Facebook is Closed for Anything

2009-02-16T16:00:00-08:00

From Mark Zuckerberg’s post responding to the criticisms of their new ToS:

“We think this is the right way for Facebook to work, and it is consistent with how other services like email work.”

If that’s the case, then why the onerous licensing? I’m quite sure that people running email servers don’t need to negotiate licenses to send and receive email to and from one another. Asymmetrical persistence is a feature, not a bug, of email.

Facebook couldn’t figure out how to replicate email in a closed, centrally controlled corporate environment (hint: you can’t). Resorting to legalese is a by-product of their broken closed model (yes, this includes their support of OpenID and their Facebook PlatformPlantation).

“There is no system today that enables me to share my email address with you and then simultaneously lets me control who you share it with and also lets you control what services you share it with.”

That’s because you can’t control such things. At the end of the day, I can write down a phone number from a screen, and paste it up on telephone poles anywhere I please, shout it out at the top of my lungs. There’s no law that prevents me from doing that, and even if there were, it would be completely unenforceable.

The music and film industries have been fighting this losing battle for years, and frankly it’s depressing to see a major web property co-opting the notion of openness while playing essentially the same DRM game.

With legalese like this, I’m expecting the big announcement at f8 to be OpenFacebookHappyDRM. Code name: Hotel California.

You can OpenID in any time of day, but you can never leave…

Velocity

2008-05-11T16:00:00-07:00

If you’re interested in scalability and performance as it pertains to internet applications, or if you’re involved in or looking to build a reliable internet-based system, go to Velocity.

I was fortunate enough to attend the O’Reilly Velocity Summit back in January, which was a Foo-Style event designed to provide some context leading into the actual conference in June. If the conference is one tenth as good as the summit, it will be amazing. Jesse is an amazing organizer and a man with a vision.

Anyhow, instead of reading my off-the-cuff posts about obvious things that are much more fun to talk about while drinking in Miami, go to Velocity and learn this stuff for real.

Scalability

2008-05-11T16:00:00-07:00

Updated: Go read Steve’s Dynamic Languages Strike Back. It’s a longer read, but it’s much more interesting, and he’s much smarter than I am.

LOL. <– this is a link. Read Ola’s post, first.

For all those who don’t get it, languages don’t scale, architectures do.

Now, some languages are faster than others. That means that to complete a given operation, it costs less, everything else being equal. Costing less is a good thing. But developers also cost money, so if you have to spend money on developers’ time porting from one language to another then you might not be saving any money at all, and really you’re just treading water.

Once upon a time, Shell Scripts were used to write CGI applications. With the correct architecture, and enough money, you could build Google with tcsh. No, really. It wouldn’t be fun, and you’d be dumb, because there are much cheaper ways to do it. But then again, if you stuck with it, perhaps you’d optimize tcsh to be really fast at spawning and serving up web requests. Faster than Java, faster than <insert your favourite language here>. Faster means cheaper, it doesn’t mean more scalable.

I point to exhibit A. Perl used to be slow. Now it beats JoCaml with the bestest concurrency (re: “Scalability”) around. What was Perl built for? Parsing text. Lots of it. All the time. It’s fast. Does it mean that you can’t build Wide Finder with another language? Absolutely not. Does it mean that you couldn’t build Wide Finder to scale out to a trillion documents with gawk? If you answered “yes”, go back to the start of this post and read again! :-) If you’re still answering “yes,” try reading some more. Leonard, Ted, Joe, Cal, and Theo are good places to start.

If you answered “no,” congratulations! Pat yourself on the back for knowing what scalability means.

FoWA Miami Rocked.

2008-03-07T16:00:00-08:00

I’ve been busy getting [Twitter] ready for SXSW, and have completely failed at email and, well, everything except work, since then. Before I actually land get drunk in Austin, I wanted to make a quick post about how great FoWA Miami was.

After giving my workshop, I attended Joe’s workshop on scalability, which was an amazingly thorough discussion, and I highly recommend attending anything that Joe does in the future (including the panel that he, Cal, and others are on at SxSW. I didn’t catch many of the session talks on Friday, as I spent much of my time talking to attendees, but the “Building a Web App in 45 minutes” panel was a fun experiment, and both Cal and Gary were energetic, brilliant, amazing, all that good stuff. If you get a chance to see either of them speak, don’t pass it up. Especially Gary, as you’re likely to get free wine, even if he makes you eat dirt beforehand.

I had some hiccups during the demo / discussion portion of my workshop, but the first part went well, I think, and I’m looking forward to some great applications that incorporate Jabber soon. My talk, “Bringing your web app to the masses” went well, except for the part where Twitter went down in the middle of it, and I got a call from work (which I waited until after the talk to answer).

Some heckling ensued, but I was happy to be able to address the audience’s questions about Twitter in an open and honest way. The atmosphere that Carsonified has managed to foster at FoWA helped a ton.

Mel, Ryan, Lisa, Keir, and Elliot did a fantastic job organizing everything, and Tantek and Brian put together an amazing lineup of speakers and workshops. Seriously inspiring stuff.

If they’ll have me, I’ll definitely be going to any conferences they hold in the future. They’ve come a long way since the FoWA San Francisco in Fall 2006, and it looks like they’ll just keep getting better.

Google Entaglement

2008-02-20T16:00:00-08:00

I’ve done a fair bit of security work, and generally try to care about the finer details of privacy and security. However, one of the things that I’ve learned is that more often than not, no amount of digital security past a certain point is going to help, since usually the threat model isn’t an advanced technological attack, it’s a social one.

Thus far, Google has done a pretty good job of keeping private things private and public things public. I’ve spoken to people on the Google Reader team, and the main reason they haven’t added support for private feeds is their acute concern for privacy.

Today Google announced a limited trial of storing health records online. This seems reasonable and doable in a secure way, but I’m sure they’ll get lots of unwarranted flak for the long-awaited project.

However, there will and should be some warranted flak. It turns out that they’re using your regular Google account to store this information, and will provide access to it using your regular password, no doubt through yet another Google login page. I’ve heard concerns that OAuth supports phishing (from Google people), but project infighting and power struggles at Google that result in tens of login pages, all slightly (or dramatically) different, all using the same credentials supports phishing much moreso.

I strongly support patients’ rights to access their medical information, and Google is probably one of just a handful of organizations that can do the necessary coordination work and stand up to invasive organizations at scale. However, they need to stop thinking of this data as theirs, because it’s not — it’s your data. Using the same password as your email to access your health records is something that should be actively discouraged. If Google wants to present a unified interface, they should expose an API and use OAuth or AuthSub, just like any other third party that would consume the data.

Now, I may be over-reacting, but I had an interaction yesterday that suggests to me that I’m not. Someone using GTalk sent a chat request to blaine@twitter.com; this email address has an MX record that resolves to mail.twitter.com, and the corresponding JID resolves to jabber01.twitter.com. However, I have claimed my blaine@twitter.com address on GMail, and associated it with my primary GTalk ID (romeda@gmail.com). When I accepted the chat request, the response came from my GTalk account, romeda@gmail.com.

In effect, Google had done something clever, and in so doing broke the Jabber spec, ignored my own self-hosted Jabber server, and exposed my personal email address without asking my permission.

In this case, it wasn’t a big deal, I don’t care, etc. Others might, though, and I only knew that it was happening because the person on the other end of the chat was tech-savvy enough to realize what had happened. Also, email addresses and connections between them are hardly closely-guarded secrets. The thing I take away from this is that Google is being sloppy. There’s a lot going on, and it’s hard to keep track of it all. That your health records are being tied to your Google account just reeks of some power struggle where the Google account people want to bolster their product’s internal importance (or have managed to do so that they get veto power where they shouldn’t have it), and it’s simply not a pragmatic choice. There’s a reason your health records aren’t stored at the DMV, and it’s not out of convenience. Just sayin’.

FoWA Miami

2008-01-20T16:00:00-08:00

Just a quick note that I’ll be giving a workshop on building real-time web applications using Jabber at the Future of Web Apps in Miami, on February 28th. The conference runs from the 28th to the 1st of March, and should be a lot of fun.

We’ve been gradually improving the Jabber stack on Twitter, and we’re now sending millions of messages every day, doing things that just don’t fit into the polling-based world of Atom feeds. There are a ton of extremely awesome things that can be built, and so far we’ve just scratched the surface.

More to come; if I don’t start blogging these things in small pieces, they’ll never come.