From the abstract:
Mashups are the most interesting innovation in software development in decades. Unfortunately, the browser's security model did not anticipate this development, so mashups are not safe if there is any confidential information in the page. Since virtually every page has at least some confidential information in it, this is a big problem. Google Gears may lead to the solution.I'm not particularly interested in what leads to the solution because I write few, if any web applications. That's mostly because, as Doug said, writing Ajax applications (and subsequently, mashups) is really hard. But I do use them. Recently there has been a trend to write web applications that let you supply credentials (e.g. supply your AIM login/password, or gmail login/password, et cetera) which the service will use to access your contact list. This is a convenient and quick way to build your social network within that application. Unfortunately, it involves way too much trust. I did this just once, I supplied my login/password for one service, and have regretted it ever since. What if my password was stolen? Does trusting this service mean I am now more likely to trust a shadier, less well-established social networking site next time? The discomfort doesn't come from discovering that someone attempted to access my account illegally, but because it shows how easy it is to succumb to sacrificing trust for convenience. Every time I connect to the application to which I gave my login and password, the remnants of that trust appear. "You seem to know the following people," the application tells me. "Why not ask them to sign up for our service?" It makes me feel like someone knows my secret, like the day in high school when I had a hickey on my neck. (Do kids still do that?
Of course I changed my password immediately after I came to my senses.
Incidentally, this underscores Doug's point about the "Blame the Victim" security model, where the entire security model is the end-user's responsibility, and frankly, most people just don't understand that model.
So let's revisit this contact list vs. social networking problem. Doug suggests a mechanism through which my contact management application and social networking application can trade information through a limited conduit: neither learns each others credentials, and you give a more explicit approval: "Would you like to share your contacts from mycontacts.com with mynetwork.com?" That's definitely better, but not the ideal.
First, I need to trust that the contacts will only be used to identify if my contacts exist in my network. Is there an implicit step where mynetwork.com can use my contact list to build what I am sure is their gigantic map of everyone's relationship on the web? This, unfortunately, comes down to website privacy policies. Hopefully when you are asked to share contacts in the context given above, it should be a short step to a very clear usage policy: "These contacts will only be used to find existing matches in mynetwork.com. The relationships will not be stored. The email addresses will not be harvested." This would be much better than "To see how we use your information, please visit http://mynetwork.com/policies/privacy_policy.asp". But the truth is, at some point, you need to decide the level of trust based on criteria like the size and reputation of the data consumer, the risk of sharing such information, and your general comfort level.
Second, I don't want to give mynetwork.com access to all my contacts. I surely don't want mynetwork.com to have access to the email addresses of my niece and nephew. I don't want to scare the new woman I just asked out. (This is fictional, I am happily married, and hope to keep it that way!) This requires a contact management tool that allows you to accurately and easily categorize your contacts, and it means I get to pick and choose which contacts I allow mycontacts.com to share with mynetwork.com, either by group or by individual.) One small problem with this is that I really don't want to spend my life categorizing my contacts. If I wasn't going to organize music for my ipod, I'm surely not organizing my contacts for this. If only I could use the relationships stored on social networking site to help categorize my contacts on my contact management site. And there we have the feedback loop that requires bidirectional trust. There's the web, building on the web, building on the web.
There are some very interesting and related things associated with moving toward the next big integrated web:
- Joel Spolsky is looking for the environment that will lead the next big leap forward for web applications.
- Friendfeed is written by some Very Smart former Googlers, which serves as an aggregator of the several social networking services (including those where the network is secondary, like Flickr and PicasaWeb.) In this case, a trust issue remains. I haven't looked at Friendfeed yet, but I look forward to it.
Now I see that we are like the Egyptians that built the Great Pyramid of Giza. We're the Egyptians, and the huge interconnected social network is the Pyramid. (This isn't really anything new. Substitute 'World Wide Web' for 'Social Network', and you get the same thing. The underpinnings of this social network and mashup aspect is pretty much what seems to be The Semantic Web.)
Incidentally, it turns out that the Pyramids at Giza were not built by slaves, but by the Egyptian citizens themselves. Thus, "we are like the slaves that built the Great Pyramid at Giza" doesn't really fit, I can't liken us to slaves. This idea merits further study. Meanwhile, see http://www.touregypt.net/featurestories/gizavillage.htm and http://weekly.ahram.org.eg/2004/684/he2.htm