Greetings. Yesterday Google announced their research toward increasing the speed of Web communications by essentially replacing the existing HTTP protocol -- used to pass data between servers and user Web browsers -- with a new, more optimized protocol.

While this announcement was generally well received in many quarters, some critics were quick to jump on Google's SPDY work as an effort to create a non-standard Web protocol that would unfairly benefit Google's own services and their Chrome Web browser (despite Google's making available SPDY specs and code).

I found myself flashing back to ARPANET days at UCLA, at a time when all of our remote access to the PDP-11/45 Unix minicomputer was via Bell 103-type dial-up modems -- that had a top speed of a blinding 300 bits per second! In fact, even though UCLA was served by Verizon ancestor General Telephone, our ARPANET basement machine room featured a number of bulky AT&T 103's (Western Electric) Model 113 modems (known by Ma Bell as "Data Sets") -- since GenTel's Automatic Electric manufacturing arm (unsurprisingly) didn't make their own modems. The 113's came complete with noisy mechanical ringers and dandy rotary dials. As I recall they were rather heavy as well.

By that time, I had built an IMSAI 8080 microcomputer at home -- the model later made infamous in the horrendous film WarGames, which featured an extensive LED register panel and the famous blue and red rocker switches (yes, I still have it somewhere, but I wouldn't dare fire it up with those massive old power supply capacitors likely leaking all of these years).

Since I was already using character-based display editors at home on the IMSAI, with comparatively high local speeds (up to 9600 bps!) I found the limitations of 300 bps dial-up back to the ARPANET Unix to be a serious pain. But at that time, while faster modems (the 1200 bps full-duplex Vadic) existed, they were priced way out of reach from both the standpoint of our facility and most individual users.

But I still thought that 300 bps royally sucked. So, I modified a Unix device driver to incorporate a relatively straightforward (Huffman) text compression system, and wrote 8080 asm code on my IMSAI side to decompress. The result averaged around 600 bps from Unix to me for typical data, and felt a whole lot better than 300 bps!

Most people who saw this setup in operation thought it was a pretty nifty hack, and of course I openly shared the code with everyone who wanted it. But a few folks seemed uneasy with what I was doing. They expressed the view that I shouldn't share such a non-standard communications system, that the spread of such "ah hock" concepts would somehow bring disorder, gloom, and perhaps an acceleration of universal entropy. "Wait for something standard!" they told me.

Which brings us back to Google's SPDY.

I like this project. In general, so long as the results are open sourced (and so non-proprietary), I'm definitely in favor of -- and enthusiastic about -- these sorts of research efforts.

Actual deployment of such systems brings in a number of issues, including that fear expressed by some critics involving the potential for skewing users toward browsers that support "advanced" non-HTTP transports in conjunction with particular service providers, vs. browsers without such support.

But to the extent that relevant information necessary for implementation in other browsers (and/or browser plugins) is made available in an essentially contemporaneous time frame (as Google is doing with SPDY), I do not feel that it is necessary for everyone to be "locked" into official HTTP standards all of the time. Also, choice of browsers is based on many factors other than speed (including but not limited to cookie handling controls and other privacy-related features), so these decisions are not generally tied to any single criteria.

Standardization tracks for new protocols of this kind are of course to be encouraged in due time, and any concerns that some parties may harbor regarding possible anticompetitive issues will need to be addressed appropriately, but these should not be show-stopper issues by any means.

By the way, I have long advocated the exploration of alternative mechanisms for routine Web server<->user encryption -- that would potentially carry less overhead than existing SSL/TLS mechanisms -- toward the goal of a pervasive, routine Internet encryption environment. My hope is that research into HTTP alternatives such as SPDY, in addition to its other benefits, will provide valuable insight and potentials in this important privacy and security aspect as well.

--Lauren--