‘Prince McLean’, writing for AppleInsider:
Data transaction security in MobileMe’s web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple’s cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser’s SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.
If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats.
It’s pretty clear to me from this description that (a) McLean doesn’t know much about data security or HTTP, and (b) the system he’s describing would be patently insecure. And unfortunately, the actual system is just as insecure as I was afraid it was.
The most glaring problem is that, since the main page resources (HTML and JavaScript) aren’t loaded over SSL, there’s no way to tell whether they’re genuine. By now everyone ought to be aware of DNS forgery attacks ; if the coffeeshop where you’ve gone online has an infected WiFi router, it would be nice to know whether its DNS record for “me.com” points to Apple’s servers or to a phishing site. But without SSL there’s no way to tell. Obviously, if you’ve loaded a hacked forgery of me.com’s web-app, any assurances made about “authenticated handling of JSON exchanges” are completely pointless, because your JSON exchanges are probably going straight to a pwned server in Uzbekistan.
(You may object that the initial login page is SSL-protected. It is, but unfortunately it’s at a completely different domain, auth.apple.com. A DNS attack on MobileMe would operate by leaving auth.apple.com alone, so you’d be handed off to the fake server after logging in.)
After writing the above, I got curious enough to dissect the traffic myself. So I used HTTPScoop to sniff while I viewed a couple of emails. Not only is there no SSL authentication, but the requests and responses aren’t even encrypted at all. I could easily read the plaintext of the email messages right in HTTPScoop, which means anyone else on my LAN (or any admin at my ISP or workplace) could easily have read them too. Oops.
The takeaway from this is that MobileMe’s web apps (at least email) are quite insecure — they won’t protect you against DNS forgery or phishing attacks, and they leave your email traffic wide open for others to read. I would avoid them if at all possible and access your MobileMe content via good old SSL in real desktop mail and calendar clients (such as Mail.app and iCal), rather than blindly trusting Apple’s pretty-looking web apps.
(You may raise a second objection, that most email traffic is sent across the Internet unencrypted anyway. But even with unencrypted email, it is much, much easier to eavesdrop on (or alter) traffic over a LAN, especially wireless, than it is to intercept Internet backbone traffic between ISPs. It’s the difference between attacking weak, easily accessible infrastructure plugged in by some baristas with little computer experience, vs. hacking into large commercial routers secured in data centers and run by experts.)
[Disclaimer: I am not a security guru. But I’ve spent quite a bit of time over the past year studying data security and cryptography, and implementing some of the techniques; and honestly, it doesn’t take a Bruce Schneier to simply run a packet sniffer and notice plaintext email traffic.]
I’m fooling around with Soup, a newish micro-blogging service I just discovered. I’ve never signed up for tumblr or its other clones, but I’m kind of smitten with Soup, so I set up my own:
beautiful snej soup, yum
I’ve got it aggregating stuff from my del.icio.us, flickr and last.fm accounts, as well as this blog. And I’m directly posting some things I’ve run across today, via its very nice bookmarklet.
Part of the reason I got sucked in is that Soup has the single best new-user experience I’ve ever seen on the web. You just click the “try it” button on the home page, and you get your own soup blog. No signup, no registration, just instant gratification. Then you can slide open the control panel (that slider itself is a beautiful piece of UI), import from your other social sites, and fool with the settings, all in privacy. Only after you’re hooked do you need to press the Create button and choose a username and password, whereupon your soup goes live. It’s brilliant — the web equivalent of the “untitled document” UI introduced in the ‘70s by the Xerox Star.
Anyway, please take a look and join me! (It’s not obvious from the untitled-blog experience, but Soup has friends and groups like other social networks.)
I just discovered that there is an ECMAScript 4—better known as JavaScript 2.0—in development. As a shameless language slut, I immediately dove into the language overview, and it’s pretty neat.
This turns JavaScript into a much more useable language, that I could see doing serious development in. I’m well aware that today’s JS isn’t a “toy”, that it’s got an interesting prototype-based object model under the hood; but I’ve found the language so loose as to be difficult to use. This new version adds a full class model, much better support for iteration, a form of generators/coroutines, and more.
Intriguingly, it also offers type-checking, which has been absent from most mainstream dynamic languages. I know it’s trendy to use “duck typing”, but I find that languages with no compile-time type-checking frustrate me because I make so damn many mistakes that aren’t caught until runtime; which means things I could have fixed in two minutes in C++ or Objective-C take half an hour to fix as I run the program over, and over, and over, discovering and fixing one problem at a time.
Given the concurrent developments in Apple’s JavaScript interpreter, I’m getting pretty excited for JavaScript. I hope that in addition to making it blindingly fast, Apple will also add ECMAScript 4 support, and make it easy to access the language outside of a WebView.
I hope some of you reading this are Ruby On Rails experts and have a moment to help me out …
What Rails generator/plugin should I use to create a user account / login system, preferably with OpenID, in a new app?
I haven’t done any Rails work in quite a while. The app I was working on was circa Rails 1.0. I’ve now updated all my gems so I have Rails 2.0.2. Of course the app doesn’t work: it crashes and burns immediately with Ruby errors in the generated code. Not surprising since I’m sure a lot has changed since 1.0.
So I thought I’d start over by generating a fresh Rails app, and then start moving pieces of my app over. But I’m immediately stuck at the first step, setting up a user account/login system.
(Which is a hurdle every newbie runs into, right? Because nearly every web app needs this, but it’s strangely the one area where DHH, the Man With An Opinion On Everything, didn’t have enough of an opinion to settle on a standard account system. So instead, chaos reigns.)
What I’ve done so far is —
1. Looked in my brand new copy of The Rails Way. There’s a whole chapter on Login and Authentication, yay. They say that the best authentication plugin is Acts As Authenticated. (Actually they say there are two best ones, but then they never reveal what the other is.)
2. Typed “script/plugin install acts_as_authenticated” as it says in the book. And get an error, no such plugin.
3. Looked up Acts As Authenticated online. The readme on the author’s website starts with a big warning that it’s deprecated and not maintained. Huh? Why is my $50 hot-off-the-press Rails book pushing an obsolete library?
4. I really want OpenID support anyway. There’s an openid-login-generator gem, so I installed and ran that. All it did was create one (1) migration file, nothing else. WTF?
5. After much searching I found that the ruby-openid library, which I already have, contains in its examples subdirectory a Rails generator. I just have to copy it into the right place, and run the “generate” script. So I did that. It generated scaffolding and such. Hooray.
6. I tried to run my app and, as the directions say, went to /account/login. Blam. Ruby errors. First it complained about “end_form_tag”, which it turns out was deprecated in Rails 1.2 and removed in 2.0; I found out how to fix that, and next it died in the generated AccountController scaffolding itself, saying OpenID::FilesystemStore doesn’t exist. Which it doesn’t—looks like that class was renamed OpenID::Storage::Filesystem. So the example code isn’t even compatible with the library it’s part of! Looks like no one’s updated it in quite some time.
7. I look at the clock (11:30PM), sigh, and decide to give up and ask Teh Lazywebz for help. But my battery dies while I’m typing this, so I don’t actually post it till the next morning.
I don’t want to make a habit of replying on my blog to posts on other blogs, because (a) it’s dorky in an autistic way, and (b) it only encourages the annoying practice of blogs that stick their fingers in their ears.
But I’ve seen a couple of references now to Dean Allen’s complaint about sites that offer multiple RSS feed formats, but no place to post a comment about it; and since it directly relates to my past job monkeying with feeds, I feel like I should answer.
There are two reasons why a web page would link to multiple feeds.
The problem for a client like Safari is that there isn’t a clear way to tell the difference between those two cases. When a site offers multiple feeds (by including multiple LINK tags in its HTML) do they have the same human-readable content or not? Answering that would require, at a minimum, downloading and parsing both feeds and trying to match the contents of the entries.
The first version of Safari RSS (in Mac OS X 10.4) went for simplicity, by indicating in its UI only that there was a feed available, not how many. If the user pressed the “RSS” button, it would pick one of the feeds to switch to. The heuristic was to give priority both to order (picking the first feed listed) but also to format (preferring Atom to RSS, because the format is much better-defined and less prone to nasty ambiguities and parsing problems.)
But some people complained that, on sites that offered multiple feeds with different content (like articles vs. comments) you couldn’t use the button to pick which one you wanted. So in Mac OS X 10.5 we decided to make the button into a pop-up if there were multiple feeds listed.
The problem now is that you more commonly end up being offered a choice between two formats with identical content, which is what Dean and others complain about, because most blog engines are configured to offer both Atom and RSS (and sometimes multiple flavors of each.)
Here’s where I could talk about the design problems of the feed auto-discovery mechanism, and describe better ways it could have been designed to support multiple feed formats [hint: HTTP 1.1 already supports content-type negotiation] or even future improvements that could be made to reduce this annoyance in the future. But you know what? I don’t care about Trendy XML-Based Syndication Formats anymore. OK, all right, I clearly care enough to write a multi-paragraph explanation and post it to my blog. But not any more than that.
Continuing from Unstealthing, Incrementally…
I have many ideas for applications, but most of them seem to rely on similar kinds of infrastructure, in particular a distributed, secure application-level messaging system. Unfortunately, this doesn’t really exist yet, at least not in any form that meets my needs.
What am I talking about here? More colloquially, it’s a mechanism for letting applications all over the network send messages to each other, without requiring a central server, and without allowing messages to be eavesdropped upon or faked.
Let’s take it one buzzword at a time…
I don’t know about you, but I’m getting fed up with centralization. It happens because it’s the path of least resistance: buy a domain name, rent a server, buy more servers and stick a load-balancer up front as your user base grows. It’s solving problems by throwing hardware at them. The end result can certainly work fine, but too often it’s fragile: both technically (site goes down, ten million users get pissed off) and politically (just one domain for China to censor, one company for France to file lawsuits against.)
In social software especially, there’s an additional type of cultural fragility, since the owners, implementors and users of a big social site have different goals and massively different levels of power. Many examples have shown that this creates sites that scale up into the equivalent of planned communities, shopping malls, theme parks, marred periodically by the protests of an angry minority of users against what they see as privacy intrusions or censorship.
Unfortunately it’s hard to use the Web architecture in a distributed way. This would involve lots of small groups (or individuals) running their own Web-based services that interoperated seamlessly. There are certainly technologies that help with this interoperability, such as OpenID and web services (whether REST or SOAP), but the bottom line is that setting up any kind of Web based system is a task that’s way beyond nearly all end-users, just as it was in 1994. It just never got any easier! You still have to know about FTP uploads and file permissions and CGI-BIN directories and Apache logs and MySQL configuration, even to set up something trivial like a damn blog.
So the options for Web-based social software end up being (a) Install it yourself on your vanity domain, if you’re a total geek and don’t mind doing your own tech support; or (b) Patronize some hosted service that will take care of it for you. What happens then, as popularity of this medium increases, is that the hosted services get bigger and bigger, money pours into them, they go into arms races of feature creep and marketing, they get even bigger, and voila! It’s MySpace and FaceBook all over again.
So that leads me to distributed non-Web-based systems. Which are completely untenable because the only way you can run custom oddball software on a real server is to rent your own private server (or virtual one), which costs orders of magnitude more than the regular web hosts that just let you run CGI scripts. Or if you want to run server software on your computer at home, you find that your consumer broadband connection comes with throttled upload bandwidth, no fixed IP address, and terms of service that forbid you from running servers.
Do you see where I’m going? Peer to peer. It’s the ultimate decentralization. If you resolve the scaling problems at the protocol level, then none of the network nodes need unusual amounts of horsepower or bandwidth, and the total supply of both naturally increases along with the user base. Installation of software on desktop computers is a cut-and-dried problem: it’s as easy as downloading and double-clicking an app. And the content is completely in the hands of its creators and users: no Disneylands, no thought police, no ad beacons.
“Secure” means a lot of things. In a messaging system, no legit user wants messages to be spoofed, tampered with, censored, read by the wrong people, or sent by the wrong people.
In the Good Old Days, no one worried about this because the net consisted of a few thousand geeks with Ph.Ds who pretty much trusted each other. (And that’s why email is so pathetically vulnerable to all the attacks I just listed.)
In the present day, developers focus on making their big monolithic servers secure from intruders, and the end users mostly trust that the developers are (a) doing a good job of that, and (b) not doing anything unethical themselves with the customers’ data. It mostly works out, I guess, although there are daily reports of embarrassing security holes, crazy new types of cross-site-scripting attacks, “creative” uses of sensitive customer data for marketing purposes, and backup tapes of millions of customer credit card numbers being accidentally left behind on the bus.
The more you think about that, the less crazy it seems to trust a peer-to-peer system where there are no authority figures handing out accounts or enforcing access privileges. Because in such a system you have to actually make everything secure by design instead of just trusting people. Want to create an identity that no one can steal? Generate your own key-pair (and keep your private key safe!) Want to keep the wrong people from reading something? Encrypt it. Want to prove you wrote something and keep anyone from altering it? Digitally sign it.
It’s not like there aren’t any known solutions to this stuff. It’s just that applying them can be tricky, and so far it’s generally been easier to just lock your big server up in a data center instead.
What I mean by this is that the messages sent between users’ computers are not necessarily directly human-readable. Unlike emails or instant messages, they might not be delivered right to the screen, but rather to an application that presents them differently. For example, a message might represent a move in a chess game, a revision of a shared document, or a notification of new content stored elsewhere. Sending these as emails or IMs is awkward and relies on having the user intervene by opening file enclosures or URLs.
Next: How Cloudy Does These Things.
Cabel Sasser, of indie developer Panic, reports from Japan:
“Within minutes of riding on the first trains in Japan, I notice a significant change in advertising, from train to television. The trend? No more printed URLs. The replacement? Search boxes! With recommended search terms!” [*]
He goes on to note how common it is for people to type URLs or domain names into their browser’s search box instead of the address field. To American geeks this seems clueless, but Cabel points out that in Japan it makes more sense, since URLs are in a foreign alphabet, so search words are much more memorable.
First off, this instantly reminded me of two favorite jokes:
But seriously: This is another example of Zooko’s Triangle, which basically says “names cannot be global, securely unique, and memorable, all at the same time”. URLs are global and unique, but not memorable, especially not in Japan; search terms are global and memorable, but not unique. Japanese advertisers are betting that you’re more likely to reach their site through keywords, even if nine competing sites show up next to it on Google, than if you forget the URL before you even get to a browser.
Marc Stiegler, on that page, predicted this:
“A good example of a nickname management system is Google. Type in a name, and Google will return a list that includes all the entities Google knows, to which the name refers. Google makes a mapping between these nicknames and their keys (if we think of the url of a page as a trusted-path-style key, which will be discussed later). Often enough to be interesting, the first item in the list will be the one you wanted. But it fails often enough, and endless pages of other choices appear often enough, to never leave us in doubt that these identifiers are not unique mappings to single keys. As is already true in the current world, in a world filled with petname systems, a key goal of marketing would be to get your nickname listed at the top of the Google rankings for that nickname.”
I wrote about this earlier, somewhere in the middle of my post FaceBook And Decentralized Identifiers”.
Famous Hacker Paul Graham on his new LISP dialect, Arc:
“Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don’t want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that’s almost offensive [...] But the kind of people who would be offended by that wouldn’t like Arc anyway.”
That last bit [emphasis mine] sort of flummoxed me. Is he saying that LISP only appeals to native English speakers?[1] Or that no one in their right mind would use LISP to write software for end-users?[2] Or maybe that internationalization is just some sort of abstract feel-good political-correctness issue, since none of those third-worlders even have computers anyway?[3]
He makes similarly eye-opening assertions about HTML, too. Arc has HTML-generating libraries, but they “just do everything with tables” instead of CSS. Why? Because apparently CSS-based Web designs are less agile than ones made out of tables. Somehow I don’t think most people who’ve done web design both ways would agree—those old-school layouts made with infinitely-nested tables were about as agile as a house of cards.
Anyway. Normally I’m a big slut for new programming languages, but it would probably take me a couple days to figure out Arc, and I don’t want to spend even one day on Yet Another LISP Variant that won’t even let me write code I could use in the real world.
Wait—let me not end on such a snarky note. Since I’m such a big smarty, what would I have done differently? I would simply have made the language’s “character” data type 16 bits wide instead of 8, and provided four trivial library routines to convert such strings to and from UTF-8 and CP-1252 encodings for I/O purposes. That’s about an hour’s work, and all you need for really basic Unicode support; once you have that, you can add further Unicode niceties (and there are admittedly a zillion of ‘em) a few at a time without completely breaking old code.
[1] And only those native English speakers who don’t care about foo-foo details like “curly quotes”—or emdashes—or other Arcane Symbols™. Remember, to the true old-school hacker, even lowercase letters are an inessential frill.
[2] Like, say, Reddit.com. From SecretGeek’s awesome overview of LISP:
“Reddit is proof that lisp is really powerful. Paul Graham originally wrote reddit, in lisp, on the back of a napkin while he was waiting for a coffee. it was so powerful that it had to be rewritten in python just so that ordinary computers could understand it. Because it was written in lisp it was almost no effort to rewrite the entire thing, and the rewrite was completed in-between two processor cycles.”
[3] I’m reminded of a meeting between Apple and Sun (JavaSoft) back in 1996. I was there to discuss OpenDoc and JavaBeans, but each company also had text and I18N engineers there, who were talking about Unicode and text-layout technology for the upcoming Java2D graphics engine. There was an exchange that went something like this:
Apple engineer: …and the layout needs to take into account ligatures and contextual forms, where adjacent letters change glyphs depending on neighboring characters, or even merge into a single glyph.
Sun engineer: C’mon, is this important? How many people need advanced typographic features like that, anyway?
Apple engineer: [after a pause] Well, there are over 900 million of them in India alone, and another 200 million or so in the Arabic world>
There’s a fascinating post on DreamHost blog about how frustrated they are with trying to make Ruby On Rails work for their bread-and-butter market of shared web hosting. I’ve run into this intermittently ever since I first tried out Rails two years ago. It’s fun to develop in, it works great on my local machine, but it’s been impossible to get any Rails app to run correctly on my DreamHost-ed web site. I’ve been told by experts that you pretty much have to step up to an expensive virtual-server solution (although I just heard about HostingRails.com, which is quite cheap.)
As already pointed out in comments, this issue is not specific to Rails, or to Ruby. The same problems apply to any complex web-app (including Python and Java ones, and probably some of the larger PHP-based frameworks too) that has a large amount of set-up overhead. By running a separate app process you amortize the setup costs across large numbers of requests.
This is a more complex model than a simple CGI or mod_whatever, but it’s a straighforward engineering problem and there’s no reason it shouldn’t be workable in a shared environment, without having to make every user rent their own server. I really hope this gets fixed — I was surprised to hear that it isn’t considered a big deal by the Rails dev community.
I finally made myself a Facebook account, mostly to see what it’s like. Overall, I’m pretty impressed: the UI is nicer than most such sites, particularly the still-antiquated LiveJournal and the disaster that is MySpace. The biggest issue there seems to be that the main profile page absolutely doesn’t scale up to handle the exploding number of apps/widgets people are stuffing into it, so you end up with mile-long profiles containing box after box of junk.
But the most interesting thing I noticed is how the service has no visible identifiers for user identities. Unlike most centralized services, there’s no unique username to pick. I assume that, internally, each account requires a unique email address, but that address plays very little role in the user experience, apart from its use in helping people find their existing contacts’ profiles. The service does assign a unique number to every profile, and this shows up in profiles’ URLs, but it never seems to appear in the page itself. So there’s no obvious way to say “this is my Facebook ID”, other than pasting in the completely non-mnemonic URL of your profile page. And conversely, the visible identifiers you see for other members are simply their real names (plus photos/icons.)
This makes sense, since Facebook is all about the social network. It may have eight hundred million members (assuming the account IDs are assigned serially) but there’s generally no need to know about, identify or refer to some random member, since it’s almost certainly someone you don’t know or care about. The people in your social network can be referred to by real name, because at that scale the number of name conflicts is so much lower, and you or your friends presumably ruled out spoofs before friending that person. Real names work for the same reason that they work in real life social interactions.
This avoids a lot of problems. Unique usernames, while deliciously old-school-geeky, don’t scale well to the modern Internet, as has been apparent since the rise of AOL 15 years ago. A username like “snej” or “JohnWilson” has great mnemonic value, but after a while everything’s already been taken but “fuzzi_bunney_37327” or “JohnWilson9284”, which are far less useful.
Using email addresses as IDs adds more room with a second level of namespace, and removes the need for people to make up new IDs for every site, but in practice it exposes the existing flat-namespace problem of the big ISPs and portals. “fuzzi_bunney_373@gmail.com” isn’t much of an improvement. There’s also the privacy and spam problem of exposing those emails to others.
It turns out there really isn’t any good solution for universal unique personal identifiers. This has been one of the factors blocking the utopian goal of a global Public Key Infrastructure (PKI): to be useful, a certificate has to assure you of its owner’s identity, which means it has to contain some signed identifier that you can associate with a real person (or persona). But, as argued convincingly by Carl Ellison in his paper Improvements on Conventional PKI Wisdom, there isn’t any such identifier that always works. Real names don’t work because they’re not unique enough, not globally or even in any large organization. Ellison calls this the “John Wilson problem”, named after eight Intel employees with that name, who kept getting misdirected email. (I think of it as the “Steve Smith” problem, after an old co-worker of mine at Apple.) Adding middle initials doesn’t help, of course, because most people don’t know their friends’ or co-workers’ middle initials. Ellison concludes:
“Human beings do not use names the way we want them to. … Computer developers … think of names the way we do variable names or path names. That is, a name is some string, unique within its block or directory or context, that unambiguously identifies some object. … Compilers and operating systems may behave this way, but human users do not.”
Of course, the certificate can include more forms of identification. A photo would help a lot, or email address. So would the name of your employer and (for co-workers) what department you work in. So would your hometown and phone number. Or your SSN or driver’s license number. But no one form of ID is sufficient for everyone: I don’t know most of my co-workers’ home phone numbers. I have personal friends whose current employment I’m not sure of. I have online friends who are nonetheless pseudonymous enough that I don’t know what they look like.
And you can’t just put in all (or even most) of those forms of ID, or your certificate becomes a privacy nightmare, a dossier worthy of a police state. The conclusion? There’s really no good way to prove identity using a self-contained certificate. QED.
This quandary has been expressed as Zooko’s Triangle, which in textual form says: No single form of identification can be simultaneously globally unique, decentralized, and human-meaningful. It can only have two of those attributes.
The best approach to identification seems to be to give up on having the identifier try to prove its own relationship to a “principal” (person or entity). Instead, the relationships are given as external statements made by other principals. The identifier itself can then just be a random unique number (such as a public key, which is easy to generate) with no intrinsic mnemonic value.
So for example, if I get a message from F837CA77B6, I have no idea who that is. But if I already know Karen, and Karen makes a signed assertion that F837CA77B6 is her new husband Michael, then I can trust that the message is from Michael. I can add him to my address book as “Michael Jones”, and never have to see that random number again. It doesn’t matter if there are thousands of other Michael Joneses in the world, because I only know one. Even if some of my friends know another Michael Jones, I just have to refer to him as “Michael Jones, my sister Karen’s husband” to disambiguate.
In a nutshell, this approach uses the social network to manage identity, by reducing the size of the problem space by about seven orders of magnitude. It’s perfectly feasible to keep track of the identity of a few hundred people using familiar attributes like names, faces and personal relationships: humans have been doing it for literally millions hundreds of thousands of years. Evolutionary biologists argue that managing social relationships in tribes was a key factor in the development of human language: in other words, gossip was the killer app for the neocortex.
Steve Dohrmann and Carl Ellison’s 2002 paper Public-key Support for Collaborative Groups describes a prototype system that uses such a distributed identity system to implement a peer-to-peer collaborative space that provides access control and trust without needing any centralized PKI.
Marc Stiegler, in his 2005 essay An Introduction To Petname Systems, has coined the term “petname” for such a private mnemonic name each person locally assigns to their contacts; for example, the Michael above might be “Michael” to me, while I’d refer to my friend Michael as “Mikey”. Petnames are (locally) unique and memorable, and make it easy to work with identifiers that are intrinsically just long strings of digits. The use of petnames and raw identifiers together gets around the limitation of Zooko’s Triangle.
Bryan Ford et al, in Persistent Personal Names for Globally Connected Mobile Devices (2007) describe an ongoing project called Unmanaged Internet Architecture that provides a more general naming, discovery and communications protocol for people’s multiple networked devices and those of their friends and colleagues; it’s a bit like Apple’s Bonjour, but it follows your social network, not Ethernet.
Facebook, of course, is centralized. (Well, the add-on apps aren’t, but even they get proxied through facebook.com.) But since a central aspect of its data model — user identities — works in much the same manner as these distributed systems, I believe that implies that a very Facebook-like social network could be built as a distributed architecture that didn’t rely on a central server or organization. It might not even look that different; you’d just notice (or not) that, as you surfed from one friend’s profile to another, the domain name in the address bar changed.
So what? Why does this matter if it doesn’t change the user experience, since existing monolithic sites can already do this, without any need for fancy new protocols?
At this point the elite members of the “blogosphere” [sorry] will be nodding smugly. You don’t need these monolithic services with all their problems if you just set up your own blog on your own website. All you need is a little bit of skill with FTP, and MySQL, and PHP, and HTML, and CSS, and that’s it! You’re free! No more being hassled by The Man.
Standalone blogs just don’t have the social features, though — they’re too standalone. I’ve had this blog for years, and it feels like a soapbox in a big city, where I can occasionally rant about something. I’ve also had accounts on one or two social-network sites for years, and those feel very different: they’re deeply personal, and the presence of friends (and their friends) is always very apparent. They’re like town squares, or big cocktail parties, where I can talk with a few friends or listen in on the buzz going on nearby.
The standalone blogs just don’t have enough protocols to enable the kind of rich interpersonal interaction that centralized social-network sites have. The venerable protocols like RSS/Atom, ping, and trackback are the kind of stuff described as the simplest thing that could possibly work (if you’re charitable) or “something scrawled on the back of a napkin in crayon” (if you’re not.) More recently, OpenID is a big step forward in making identities transportable between sites. Google’s OpenSocial might help; I confess I haven’t yet examined it closely enough to tell if it’s useful for more than just creating yet more Facebook-style widgets.
In any case, there’s more work to be done to bring social networking into the decentralized blogging environment. I think we may be at a tipping point now — people seem to be increasingly aware of the problems that centralization brings, and in their aftermath I keep running across discussions of how it should be possible to do this stuff without pesky corporate overlords messing it up. So there may be enough demand, now, to balance out the intrinsic difficulty of building open standards. I’m hopeful!
