Twitter had some issues this weekend with folks sneaking Javascript code into profiles to effectively create self-replicating Twitter worms. These worms were exploiting a hole in which Twitter was not doing enough scrubbing of user inputs for the CSS customization of a profile page. While this was clearly a security flaw and had to be fixed, it does result from a basic philosophy which aims at maximum flexibility in how people use Twitter. This stands in fairly stark contrast with the very tight control over usage and use cases that Facebook is attempting to exercise.
I got some firsthand experience with that yesterday afternoon as I was playing around with the Facebook Connect API. For instance, if you want your Connect application to publish to the feed, you must first submit story templates for approval to Facebook (there are separate templates for one-line, two-line and three-line stories). This means you need to plan in advance what messages your application wants to send and then wait for a review by Facebook. Oddly, no such constraints apply when updating someone’s status. There instead, you need to ask the user for a separate permission to update the status. If you want to be able to do any of this even when the user is not logged into Facebook at the time (for instance because it reflects an action taken via email) you need to ask for another separate permission (“offline access”).
Facebook is putting these hurdles upfront in an attempt to control the experience and prevent such things as spamming of feeds. But there is a tradeoff. Hurdles like this also limit innovation. I believe the better approach would be to have fewer up front hurdles and rely more on enduser behavior and automated filtering. For instance, when Susan rolled out Twitter integration for DailyLit, the initial version did not provide enough control and some folks promptly unlinked their accounts (and complained about it on Twitter). That resulted in a new version which provides detailed control over what will be tweeted and how many tweets will be sent. I am pretty sure that Facebook users would exercise the same type of discretion with respect to Connect apps. But even when users don’t, there is a lot that can be done automatically to suppress what would otherwise be feed spam. Twitter, for instance, already has extensive duplicate suppression in case an external app is in some kind of loop and spits out the same status repeatedly.
This reminds me of Clay Shirky’s “Publish First, Filter Later” chapter. In the digital age, the cost of upfront hurdles in terms of diminished innovation and adoption seems to far outweigh their benefits. We would all get less benefit from Google if it included only sites in their index that conformed to a bunch of upfront criteria, instead of relying on ex-post filtering and user behavior to identify spam. This is not to say that the latter is easy. Much work remains to be done for Google and Twitter (and everybody else), but I believe the long term results will be better.
