Saving the Internet

June 20th, 2007

arrow

In an article in Harvard Business Review Johnathan Zittrain takes a look at the risks facing the Internet in the immediate and medium term and how best to tackle the issues.

It’s interesting to me that his argument can be boiled down like this:

  1. Technologies that can be used unintentionally by others to build useful things (generative technologies) are great.

  2. The PC is great because of this. So is the Internet.

  3. Because they are so generative people are able to create technologies that are actually harmful.

  4. In order to avoid harmful software being run on their PCs connected to the Internet, users may choose to use less generative technologies, and move to appliance-like systems or services (e.g. iPhone, or only ever staying within Google/Yahoo sites)

  5. We need to stop them adopting appliance-like systems in order to keep the Internet strong.

He goes about spelling that out in a few thousand words, but his ideas on how to do all this are a little light and tucked up at the end almost like an after-thought. It’s ideas though that I’m most interested in here, so here they are:

  • Netizenship

    He suggests that all code should be subject to a Wikipedia-like editorial process where self-chosen experts vouch for whether the code you download and run on your system is harmful or not.

    This sounds novel, but I’m concerned about how such a system could be gamed by nefarious types. It may be that you would need to establish a trust network with certain users, but this would require you to expose information about the software you’re running: giving up your privacy to people who can name you is considered a greater threat by many than giving it up to criminals.

  • Virtual Machines

    You download software and you put it in a special “container” on your machine where it can destroy what it wants to: it can’t get out to destroy your precious data. Once it has been running for a while and you trust it more and more, you can move it over into the “special” area where it has more rights.

    One question: why would I ever want to run the software outside of the container? Why not just provide a proper security model for all applications running on the system and take it from there? Unix sorted this one out better than Microsoft ever has in the 1970s, and with jailed/container environments from the BSDs and Solaris likely to hit the desktop Unix market within a couple of years, this might have some traction.

  • More help from ISPs

    Zittrain argues here that ISPs turn a blind eye to zombie machines because they don’t want to help their users. This is completely and totally wrong.

    About a year ago I was in the ops center of a major multi-national ISP, sat with their abuse team watching how they worked. I was being considered for a contract to help them automate their processes (a contract cancelled as it was announced the ops team was to be relocated down South shortly afterwards).

    One of the jobs they took on was handling the automatic e-mails sent to them by AOL informing them of spam received by a machine on their network. They would then cross-correlate the IP address to customer records by hand, and give the customer a call and talk them through de-zombie-fying the machine. This *is* industry standard practice. ISPs who didn’t do this would eventually just find themselves being disconnected by their peers as they became more and more of a harbour for zombie machines.

    What would be better is more ways for ISPs to handle this automatically and to establish better trust frameworks. I also think that ISPs could relatively trivially prevent the most common spyware passing through their transparent reverse proxy cache boxes without causing major damage - the problem would be whether such action would be legal.

    I also think one area that ISPs could improve is education: a lot of people are pretty naive when they first get online and it’s only once the real story is told (or experienced first-hand) that users wise up. I think that at current rates enough people will be clued up enough to stop downloading spyware within a decade, but that’s a dangerous prediction, and there’s nothing stopping ISPs getting into the mix.

  • Network neutrality for mashups

    This is an idea that sounds simple in practice, but actually defeats the point of generative technologies being adaptable, flexible, unregulated and novel.

    The premise is simply that if you write an application for a an API, your application is locked into that API’s vendor. They could withdraw service completely or just for your API key, or they could decide that they want to change the API at any time thereby breaking your application. In other words, if you invest time in developing to Google’s code base, you are suddenly beholden to Google: you can’t switch to Yahoo! or Microsoft APIs instead. This appliance-like style of development suddenly makes the “generative technology” of the Internet look quite stale compared to say the PC revolution.

    Zittrain argues that certain basic functions should be standardised so that once you write the application, it can work with similar services from other providers. If you write a Google maps mashup, changing it to work with Yahoo! should be as simple as changing a URL and an API key reference.

    It sounds simple, and standardisation is sure to come about over the next five years, but it’s actually a major undertaking. It would require all the major players to agree a baseline set of functionality, and that’s unlikely to happen with a group of commercial players.

    Where standards have arisen on the Internet - the IETF or the W3C - it has been a group of people acting in the spirit of non-commercial interest. Sure, the IETF meetings are dominated by Cisco, Juniper, Nortel and the ilk, but they are adopting a process first initiated by academics and amateurs: they’re second to the party, and are kept in their place by the tradition of open collaboration the IETF encourages.

    To create a standards body for web APIs now would require open source developers to somehow subvert the progress made by the commercial guys, or for the companies to stop behaving the way they have done for the last decade or so. It is an onerous task.

I think the error Zittrain is making here is that he believes these are problems that need to be solved in a way that is 100% efficient, or near 100% efficient. He also seems to be forgetting the human factors.

In terms of protecting users from harmful software, I believe this problem will go away within the next five years. It’s a dangerous prediction, but I believe that once users become more aware of the risks of software they are more likely to question where they source it from. It could be argued that without some kind of trust metric start-ups might find it hard to get traction, but start-ups have always benefited from the attention of early adopters who are clued up enough to know how to assess the risks of software like this.

In other words: if it’s getting good blog press, it’s OK to download. Most companies have woken up to the fact that you can lose every shred of credibility on the Internet within a day or less now, and credible company are not likely to push code that is going to harm your machine. By 2012, companies prepared to compromise their credibility will likely have no future. Zittrain’s assumption is a little like that of Cold War game theory: everybody is out to harm you, and the only right course of action is trust with verification, or outright suspicion.

As for the issue around APIs, again I think Zittrain is missing the human angle here. Yes, Google or Yahoo! could shut down their APIs at any point in time. Google have in fact stopped supporting an API or two in the past, but were careful in how they did so: they just stopped taking on new users for that API. If they were to leave developers high and dry, developers would feel the trust they had in the company had been broken, and they would make the effort to switch. Switching might be a pain, but it’s not impossible: most mashup apps out there right now are almost toy-like in their simplicity and can be recoded to a new API within a few hours. Once that happens, Google may as well drop all their APIs, and they know that.

I think eventually some form of standardisation is going to have to emerge, but all I can say about that with any degree of certainty is that it is unlikely to come from the commerical players.