[535] in Privacy_Forum
[ PRIVACY Forum ] Google's SPDY Project Triggers Ghosts of Critics
daemon@ATHENA.MIT.EDU (privacy@vortex.com)
Fri Nov 13 23:23:56 2009
Date: Fri, 13 Nov 2009 20:05:51 -0800
To: privacy-list@vortex.com
Message-ID: <20091114040551.GB31878@vortex.com>
MIME-Version: 1.0
Content-Disposition: inline
From: privacy@vortex.com
Reply-To: PRIVACY Forum Digest mailing list <privacy@vortex.com>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: privacy-bounces+privacy-forum=mit.edu@vortex.com
Content-Transfer-Encoding: 8bit
Google's SPDY Project Triggers Ghosts of Critics Past
http://lauren.vortex.com/archive/000635.html
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
( http://bit.ly/1N8Rvf - Google Research Blog ) 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
( http://bit.ly/1AGlJJ - WilliamBader.com ). 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
( http://www.imsai.net ) 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--
Lauren Weinstein
lauren@vortex.com
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR
- People For Internet Responsibility - http://www.pfir.org
Co-Founder, NNSquad
- Network Neutrality Squad - http://www.nnsquad.org
Founder, GCTIP - Global Coalition
for Transparent Internet Performance - http://www.gctip.org
Founder, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Twitter: https://twitter.com/laurenweinstein
_______________________________________________
privacy mailing list
http://lists.vortex.com/mailman/listinfo/privacy
