July 9, 2013

The Beginning of the End of the Web

Slashdot just announced that HTTP 2.0 will be a binary protocol. This is a big shift. I don't think it's a good one.

HTTP, invented back in 1991 by Tim Berners Lee, is the computer protocol that mediates the delivery of data across the Web. Its invention transformed the Internet from a specialized tool used mostly for military and academic purposes, to a mass pop-culture medium open to anyone with a pet and a digital camera. HTTP was the catalyst for the largest technically-driven socio-cultural shift in humanity since the printing press. (Well, maybe the birth-control pill had a bigger impact, but I digress.)

So far, HTTP has been a human-readable, plain text protocol. This has given rise to associated technologies that are transparent, shareable and easy-to-learn. "View source," for example, is a common feature of web browsers and is the basis for most of the learning and retransmission of technical knowledge around the Internet. It was a small technical detail that allowed the web to be a radically open learning medium. And the "view source" pattern grew out of the decision to design HTTP as a plain text protocol.

By making HTTP 2.0 a binary protocol, future web technologies may be faster, more efficient, but they will be more complex, less open, less transparent, and will require more custom support tools to be built around it. HTTP 1.1 was great because you could rely on broadly-available generic tools to interact with it. (Nerds will know what I mean when I say "telnet localhost 80".)

On an abstract level, the Web is built on the assumption of openness and visibility. Security and opacity are optional. Text, writing, and conversations are at the metaphors that drive this protocol -- video and audio are afterthoughts. The HTTP 2.0 binary protocol wants to put video at the center of the web and make openness optional.

One Slashdot comment goes into more technical depth: "[The HTTP 2.0 spec] reads almost like they reimplemented all of TCP inside of HTTP, complete with stream set-up and teardown, queuing, congestion control, etc. Why not just use... TCP to manage multiple streams?"

Good question.

Now that new web browsers are beginning to adopt WebSockets, there's no reason to change HTTP. The current division of responsability between HTTP and TCP is simply good software design.

Okay: so HTTP 2.0 is a bad thing. But why does this matter?

As far as technologies go, the Internet is very democratic (most technologies are elitist and opaque). Insofar as democracy is worth protecting, it's worth protecting everything that makes the Internet open, friendly, easy-to-use, easy-to-learn, easy-to-modify, easy-to-reuse and, well, meritocratic. By transforming HTTP into a binary protocol, we risk eroding of the basic foundations of what makes the Internet an open system.

By adding complexity and opacity to HTTP, we're in danger of losing a technology that has helped create a flatter, more accessible and more open world.

I say: keep it simple and keep it plain text.

No comments :