Saving the Web: Should we sacrifice generativity for safety and security?

Posted on August 31, 2007

Generativity - or the ability for all people, some with no qualifications at all, to use and share a technology - is the both the best and worst thing about the PC and internet combination. This open access allows for unparalleled participation and innovation but it also means the system is vulnerable. Let’s open up by taking a look at the good side of generativity.

Disruptive innovation is crucial. Without it human progress stalls. For disruptive innovation to happen the innovators need to be able to reach users with their new products. With PCs and the internet the user is easy to reach since the user controls what programs they will run and what products they will use. This leaves the door open for crucial new technologies and applications of technologies to permeate.

Generativity also allows smaller firms to emerge and grow. Without generativity there would be no start-ups since large firms, who would own proprietary systems in a world without a generative internet and generative hardware, would effectively be able to block out smaller entrants into their markets. Without those smaller entrants - a.k.a. the disruptive innovators - progress is stalled.

In a June 2007 Harvard Business Review article (I am telling you, you need to read HBR - very, very good stuff) entitled “Saving the Internet” written by Jonathan Zittrain uses some great examples to describe the disruptive innovation made possible by a generative system.

For example, Zittrain looks at online auctions and posits that the market would have been ripe for the picking for someone like Christie’s or Southeby’s but eBay beat them to the punch. There are also a host of other applications (web based e-mail, personal web pages, IM software, etc.) that may have never been born if the internet and the PC were not generative.

Of course that is what is so exciting about technology, and in particular, the internet. A level playing field (systems wise) has been created where a few guys in a garage with an idea can disrupt large corporations who, by nature, are typically unwelcoming of new ideas created by outsiders or even their customer.

While it is great that the system is open and users can try new things at their leisure the issue remains that there any many computer and internet users who do not know enough about PCs and the internet to know they are doing something wrong or harmful. Essentially users are in control of what code they ultimately run which leaves them vulnerable to unknowingly running bad and harmful code.

Due to this unfortunate byproduct of open and generative systems we have experienced a large influx of what Zittrain refers to as “appliances” - or devices and systems that are not generative. Some examples of appliances are TiVo, hand held devices, etc.

Users enjoy the fact that these devices are convenient and will limit the damage the user can inflict. That said, it seems that users are not valuing the ability for them to modify and add new functionality to these devices like they can with their PCs. As Zittrain mentions, this turn toward appliances is a slippery slope. Once the PC goes out in favor of devices the ability for new software, like skype, to emerge is far less likely.

Zittrain also mentions that:

A shift to smarter appliances, ones that can be updated by - and only by - their makers, is fundamentally changing the ways in which we experience our technologies. They become contingent: Even if you pay up front for them, such appliances are rented instead of owned, subject to revision by the maker at any moment.

Unfortunately this is also true of APIs. While they are an agent of generativity their generativity is at the sole discretion of the company that created them. It makes complete sense that a company who created something and put APIs in place to allow for generativity would want to control the APIs use in some way. However, the company that built the API is not the only thing standing in the way of the APIs generativity. Back to Zittrain (he uses the Google Maps API as an example):

But this puts within the control of Google, and anyone who can regulate Google, all downstream uses of Google Maps - and maps in general, to the extent that Google Maps’ excellence means other mapping services will fail or never be built.

Zittrain goes on to make another interesting point this time around Web 2.0 and generativity:

… what some have applauded as Web 2.0 - a new frontier of peer-to-peer networks and and collective, collaborative content production - is an architecture that can be tightly controlled and maintained by a central source, which may choose to operate in a generative way but is able to curtail those capabilities at any time.

Of course this situation has been covered before. The MySpace and Photobucket example comes to mind where MySpace temporarily disabled the ability for Photobucket widgets to run on their platform. Facebook is another great example.

Facebook is a closed system which recently opened up by allowing people to create applications that live inside Facebook. However, those applications have to be built in Facebook’s framework and Facebook could potentially limit the applications they accept at any time including turning off applications like MySpace did to Photobucket. I hope Facebook will remain open but we’ll have to wait and see how it plays out.

Back to the question at hand: should we sacrifice generativity for safety and security?

I would argue based on all of the information above that we absolutely should not. What we should do is look for create ways to create security without compromising generativity. Zittrain lists four things in his article that we can do to keep the web and PCs generative while working to better secure them from threats.

Netizenship: Allow small groups of people to moderate (i.e. Wikipedia). It’s like neighborhood watch for the web.

More help from ISPs: The end points - ISPs - can become safety valves.

Network neutrality for APIs: The network should of course remain neutral so disruptive innovation can happen but the companies who offer APIs should also allow the APIs to remain neutral in that anyone who wants to can build on top of them (of course their are cost implications to the company offering the API that would need to be considered).

Virtual Machines: Technology that allows mission critical apps to be cordoned off from other apps essentially creating two separate machines in one is on the horizon. This will allow for a test bed to be created on a PC and that test bed, if infected, would not be able to harm the other crucial apps on the PC.

I’d like to jump into a little more detail on the last item - virtual machines. I just read yesterday in the latest edition of MITs Technology Review about an even more interesting idea around virtual machines. Ivan Krstic, one of the 2007 Technology Review Top Innovators under 35 (he’s only 21! - I feel like such a slacker), developed a system for the OLPC project called Bitfrost. Here’s TR’s explanation of the system:

Instead of blocking specific viruses, the system sequesters every program on the computer in a separate virtual operating system, preventing any program from damaging the computer, stealing files, or spying on the user. Viruses are left isolated and impotent, unable to execute their code. “This defeats the entire purpose of writing a virus,” says Krstic.

Fascinating stuff. The system is not quite ready for consumers yet but Krstic is working on helping programmers write “wrappers” for their programs that will allow them to communicate with the Bitfrost system. That is the first step toward getting something like Bitfrost out to the general public.

I’ll close with a quote from Zittrain’s HBR article that I think is quite fitting:

… for the generative Internet to save itself, it must generate its own solutions.

Fortunately it looks like we’re well on our way to doing just that.

Side note: Zittrain’s book on the generative Internet will be released this fall by Yale University Press and Penguin UK.

Subscribe


Enter your email address:

Delivered by FeedBurner

Search this Site

Lijit Search


Leave a Comment

If you would like to make a comment, please fill out the form below.

Name (required)

Email (required)

Website

Comments