Follow by Email

Sunday, October 07, 2007

Thoughts on "Gears and the Mashup Problem"

... in which I meander through my mind while the TV is off.

Yesterday I watched a recording of a talk given at Google in the past month called Gears and the Mashup Problem. It's only 45 minutes long and worth the time. The speaker, Doug Crockford, was both interesting and funny. He is listed as "The world's foremost living authority on JavaScript". (Has JavaScript been around long enough to have a prior foremost authority that is no longer living?)

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.
  • I remember the launch of Yodlee in 1999. Back then it wasn't just a financial services aggregator (as it seems to be today), but a general purpose aggregator, an aggregator of bank accounts, credit card accounts, airline mileage accounts, car rental memberships, et cetera. Talk about trust. I haven't used Yodlee in many years, so I can't really comment on it, other than recalling a security policy that theoretically prevented Yodlee employees from accessing your trusted data. Granted, 8 years is old. It's as old as JavaScript.



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

2 comments:

mbostock said...

In this regard, I think Flickr sets a great example for third-party integration. Their user authentication API allows a signed third-party application (web-based or otherwise) to interact with your Flickr account, but in a way that can be controlled by the user, and without giving your password to the third-party application. There's a tab of "Third-party applications you're using" which you can use to authorize and revoke permissions.

Jordan said...

Yodlee is still around and well. It still allows you to aggregate your bank accounts, credit card accounts, airline mileage accounts, car rental memberships, et cetera and adds a whole new level of personal financial management along with bill pay, funds transfer, account opening and others.

Security is still at the top of the list of concerns.

..Jordan, Yodlee Inc.