Greetings. Egads, it's time for the next installment from my archival video extraction project -- and an interesting item it is.
In the debut segment, 1983 Video: "Captain Crunch" and "Computer Hacking" (TV Interview), we saw an interview triggered by network TV news' fascination with the then recent Milwaukee "414s" penetrations of computers at Memorial Sloan-Kettering Cancer Center and Los Alamos National Lab.
Today we explore how a different television network in 1983, also using the "414s" story as a hook, explored the question of whether the scenario portrayed in the film WarGames -- coincidentally from that same year -- had any possible basis in fact.
As with 1980 Video: "Telefuture" - Everything Old is New Again!, I have sandwiched this new video segment with a pair of hopefully amusing, unrelated very short clips (not necessarily from the same year as the main interview) that were also recently extracted from my video archive -- including a remarkable bit of political insight (?) in the closing clip.
The "WarGames" interview features a designated computer expert who uses as "props" a TeleVideo computer and a modem near and dear to many of our hearts, the venerable 300 bps Hayes Smartmodem (raise your hand if you owned one!)
The computer and modem never really do much during the interview -- we don't even get to hear any Touch-Tone dialing.
While the guest correctly and firmly disassociates the reality of U.S. missile systems from the fantasy scenario of the WarGames film, he oddly glosses over the "wardialing" aspects of (then current) microcomputers and modems, and instead suggested that it was "simple" with this equipment to iterate through all possible nine-digit "social security number" passwords to break into computer systems.
Hmm. There are several comments I could make about that assertion, but let's just say that plowing through nine-digit numbers (assuming nothing stops you after a few incorrect attempts) still isn't much fun even at modern Internet speeds, much less over 300 bps dial-up modems. Like the lost Flying Dutchman, I fear that the particular TeleVideo system shown may have been dialing continuously since that interview was broadcast decades ago, still searching for its first "hit" -- oh the pain, the pain.
So without further ado:
1983: "WarGames Movie" Hacking Fears TV News Interview
Blog Update (November 24, 2010): How to *Bypass* the Blocking of Google TV by Hulu and Other Networks
Greetings. The day started badly. All he wanted was a piece of toast. Yet instead of creating a crispy slice of goodness, his General Electric toaster ejected the still soft slice, and flashed a bizarre admonition on its display (odd, he didn't even remember it having a display) -- informing him that due to an ongoing dispute with Van de Kamp's bakeries, he was blocked from toasting that particular brand of bread until further notice. How droll.
At least he could head out and pick up something to eat elsewhere. But he was low on gas -- better buy some first.
More trouble. The pump refused to operate. What's this flashing on its screen? A list of acceptable car brands that have made deals with ARCO. His old car wasn't on the OK list. So -- no gas. Amazing. What's the world coming to?
Back home, at least he can watch some TV. Now what? Instead of shows, messages are popping up hot and heavy. CBS says they will only allow viewers using SONY televisions to tune in. FOX demands Toshiba or Samsung. The DuMont network insists that you use a Farnsworth set.
DuMont? Farnsworth? What the blazes is happening today? Somebody help! HELP!
And he awoke in a cold sweat from the nightmare.
Phew. Just a bad dream. Better calm down and watch the new Google TV -- go relax with some Web shows on the big screen. He settled comfortably in his easy chair to wind down -- and his face twisted into a maniacal grin as he discovered that Hulu and the major broadcast networks have blocked much Web viewing by Google TV users.
Reaching for the heavy hammer on the table to his side, he slowly approached the array of electronic devices stacked before him ...
There has been much speculation about motivations for the blocking of most full episode Web programming from Google TV users -- first by Hulu, then by the conventional broadcast networks.
Some observers suspect that disparities in ad rates between broadcast and Web versions of programs are the primary cause. Others have suggested that it's payback to Google for refusing to censor search results to try "hide" sites that offer pirated programming.
Google itself has offered a diplomatically worded statement noting that it's up to program suppliers to decide which users they're willing to service. Understandably, Google doesn't want to burn any bridges, especially before they've been fully built.
But in my view, the purposeful blocking of particular viewing platforms for other than legitimate technical reasons (e.g. genuine, serious display incompatibilities) is unacceptable -- and should be illegal.
What we're seeing now is partly a spillover from the increasingly heavy-handed tactics that have resulted in the ongoing "carriage wars" between TV channels/networks and cable/satellite providers -- with users having channels cut off when these groups couldn't agree on terms.
Now this has escalated even further. Program providers are exploiting Web technology in what can't help but appear to be attempts to demand (extort?) fees related not to which cable system a user is on, but to what product they're using to access Web programming.
What's the difference between this situation, and that toaster and gas pump from our friend's nightmare above? Not one hell of a lot.
And from a technical standpoint, this gets even sillier. Odds are (though I don't know this for a fact) that the Google TV blocking may be based on client identification information that Google TV is honestly passing to the associated servers. If Google TV didn't self-identify in a distinct manner (or if it allowed users to set identity strings as they wished -- a common feature in some browsers), it seems likely that Google TV viewers could look like users of ordinary PCs that aren't being blocked. Of course, Google providing such a feature would likely be considered a provocative action by the very networks involved in this dispute.
Even more bizarrely in this respect, many conventional PCs (both tower and laptop) now include outputs (e.g. HDMI) that permit users to view Web programming on large TV monitors without even needing to obtain DVI adapters -- and there'd be no indication to the networks that viewers weren't using smaller displays. That's all most TVs are now from a display standpoint -- just generally larger versions of the same technology that we use at our PCs, or in our laptops -- every day!
My assumption is that ultimately Google will come to terms with the various networks involved in this dispute -- but by all rights Google shouldn't have to make any sorts of deals for users of Google TV to have the same access to Web sites as any other Web users.
If we continue to allow this bullying of viewers -- by networks trying to micromanage the hardware that we use to access their Web sites -- it is likely to only get worse over time with escalating demands for ever more control.
And then all of us -- the viewers -- will really be ... toast.
Blog Update (November 24, 2010): How to *Bypass* the Blocking of Google TV by Hulu and Other Networks
Greetings. The next historical artifact from my archival video extraction project is a particularly fascinating short news report called Telefuture -- I'm dating it to the late 1979 to 1980 time period. I've also bracketed the beginning and end of this report with a couple of other hopefully interesting/amusing clips (from a bit later than 1980) that I've recovered from the archive.
This video segment looks forward to the predicted world of television-based information services, and in so doing demonstrates the fascinating "arc of technology" that so often is visible with the benefit of 20/20 hindsight.
As you'll see, the report concentrates on Teletext -- and Viewdata (aka "Videotex") services -- the former delivered as vertical blanking interval data on broadcast signals, the latter over telephone modems.
While Teletext systems (e.g. the BBC's Ceefax) remained popular in Europe (the BBC system is reportedly still operational, scheduled to end with the termination of analogue TV broadcasting in 2012), Teletext never really got beyond the experimental stage in the U.S. (I do still have a working Teletext box from my work with the system -- but of course there's nothing for it to display!) Meanwhile, Viewdata was largely supplanted by PC-based dial-up services and the like.
Various hybrids were also proposed, including the use of touch-tone telephones to request Teletext pages, which would then be delivered to the particular subscriber via the broadcast data stream. My own Stargate system, that I installed at the "Superstation WTBS" uplink to experimentally transmit Usenet netnews data many years ago, was actually a Teletext technology system, though in my case decoders fed received data to PCs, rather than using television displays.
That "arc of technology" I mentioned is especially noteworthy today, as we watch efforts to "converge" Internet applications back to home televisions, via devices such as TiVo, Google TV, Apple TV, and various others. Viewed in this light, those predictions from three decades ago don't look silly at all.
Finally, you'll note from the report that even back then, concerns were already being expressed that these new technologies could threaten traditional newspapers and other related media outlets.
Indeed, everything old is new again.
1980 Video: "Telefuture"
Greetings. With much fanfare, sites around the Net have trumpeted word that Google is no longer collecting Wi-Fi location data via their Street View vehicles -- in the same breath usually emphasizing the continuing controversy over Google's accidental collection of Wi-Fi payload data (an overblown story that I've previously discussed: "Highly Illogical": The Hysteria Over Google's Wi-Fi Scanning).
The various parties who condemned Google either for collecting Wi-Fi location data alone, and/or for the inadvertent (and self-reported) collection of associated payload data, are now presumably patting themselves on their backs, oh so proud of putting "Big Bad Google" in its place.
What these groups have actually achieved is causing Google, the firm that has been in the most effective position to process openly broadcast Wi-Fi beacon location data for the public good, to be threatened out of providing an extremely useful service for the public at large.
Meanwhile, all those Wi-Fi hotspots are still out there. You can drive down the street with virtually any laptop (or many phones) and plot the Wi-Fi hubs in their multitudes.
And if you're so inclined, you can also gather the payload data from the many open, unsecured Wi-Fi networks -- perhaps purposely and with genuinely evil intent. This in stark contrast to accidental payload data collection -- the data never to be exploited or abused -- as was the case with Google.
Software to capture Wi-Fi payload data is all over the Net. Even the makers of the wonderful (and inexpensive) little Chumby "Internet appliance" posted code for using the Chumby to "sniff" and display captured Wi-Fi packets.
Now obviously, the Chumby folks weren't suggesting that such capabilities should be used for illicit purposes. And that's a key point -- not only is it easy to capture open Wi-Fi data, but there are completely legitimate testing-related reasons to do so -- essentially the situation that led to Google's accidental wider collection of such data.
There are of course some hotheads and conspiracy theorists who are still convinced that Google was purposely collecting Wi-Fi payload data, had a secret plan to earn vast profits from that data, and perhaps also operates a kitten-crushing facility at the Googleplex. There's no point in arguing with such folks -- it's like trying to carry on an intelligent conversation with a bag of marshmallows.
But when you do travel from place to place, don't forget those vast numbers of unprotected Wi-Fi signals permeating the air around you -- that can continue to be criminally exploited by crooks -- but will no longer be useful to society at large via legitimate Google-based services.
Score one for the blockheads.
Greetings. As I've continued extracting video from my previously declared "dead" videocassettes, I've been searching for some of my treasured long-lost recordings, mostly just faint memories at this point.
I hit pay dirt yesterday, and successfully recovered one of my favorite clips. It has nothing whatever to do with technology, computers, privacy, or the Internet, but it's certainly making me smile -- an increasingly challenging task these days -- so I hope you'll forgive my off-topic posting in this case, as I hope to bring a smile to you as well.
Dating from October 2, 1975 -- almost exactly 35 years ago -- it's a segment from the late Tom Snyder's eclectic late-night Tomorrow Show (aka Tomorrow Coast to Coast). During my period of youthful, intense nighttime code hacking, Tomorrow was on my regular viewing agenda.
This wonderful video segment features Snyder playing a taped performance (that he claims he had not seen previously) recorded by three members of the legendary Credibility Gap comedy group -- Harry Shearer, Michael McKean, and David L. Lander.
The performance is (for me at least) a hilarious send-up of Snyder and the Tomorrow show itself, with Shearer playing Snyder, McKean a UFO researcher, and Lander a very poorly disguised CIA operative.
A few words of warning about this particular video. First, it is not "politically correct" by 2010 standards (or by 1975 standards, for that matter). Also, at a "critical" juncture of the "interview," the audio briefly drops out and there appears to be a video cut. These effects were apparently indeed part of the joke itself, and have been present since the original transmission several decades ago.
Finally, this material was extracted from among some of my oldest personal tapes, and even after dousing this segment with a great deal of processing "CPU Juice," it begins abruptly and still is in fairly ragged shape as you'll see (especially near the beginning). Please be patient, it settles down considerably during the course of the presentation. But believe me, the original unprocessed source video makes the posted version look like near perfection by comparison.
I hope you'll find this small slice of comedy history as entertaining as I do.
"The Credibility Gap" - Tom Snyder - UFOs - and CIA Poisons!
Greetings. While continuing to process material as part of my Ancient Videotape Extraction Project, I literally ran across a very short but fascinating item earlier today.
This January 1983 television report dramatically and forcefully describes President Reagan's abysmal poll numbers (two years into office) mainly due to concerns over the economy.
Reagan of course went on less than two years later to a landslide popular and electoral vote victory -- winning 49 out of 50 states.
Just a bit of archival history for Team Obama -- and all of us -- to remember as we approach the same juncture of the Obama presidency and a similar bemoaning over polling data.
Greetings. A couple of days ago, in Technology History -- Courtesy of the Betamax Videotape Extraction Lab, I explained some of the nitty-gritty aspects of my new project to extract viewable video (especially related to technology and science topics) from my collection of ancient videotapes, long since declared to be unviewable on any available equipment due to serious deterioration of the tapes over time.
Using the techniques described in that posting (with the most deeply recalcitrant specimens helped along with an additional secret weapon that I'll explain in detail sometime), plus some rather computationally intensive post-processing, some of the results are looking far better than I originally thought would be possible.
There will be a variety of interesting/amusing items appearing as I have time to process them fully, but let's look now at a genuine period piece, chock full memories for those of us who lived through that time, and hopefully an educational slice of life for younger folks.
We begin with this "Computer Skulduggery, Break-ins, and Piracy" television interview from almost 30 years ago -- of once notorious phone phreak Captain Crunch (John Draper), conducted by reporter Sam Donaldson.
I've dated the piece to 1983 -- coincidentally the year often (but still with some controversy) cited as the "official birth year" of the Internet (at least in terms of the transition to TCP/IP from the precursor ARPANET NCP and other protocols). This was also the year that the rather insipid film WarGames was released, resulting in everyone who saw my IMSAI 8080 micro kit at the time to exclaim, "Hey, Lauren, you have the War Games computer!"
The 1983 interview video segment was apparently particularly inspired by the then recent FBI busts of the Milwaukee "414s" -- accused of a large number of computer penetrations including most famously Memorial Sloan-Kettering Cancer Center and Los Alamos National Lab.
The interview also includes an anonymous 15-year-old "software pirate" who explains how the DOS "copy" command functions -- utterly confusing his interviewer. (C'mon kid, you don't have to hide now. You're grown up and the statute of limitations should have run out ages ago.)
It's interesting to note that the once venerable, honorable, and completely legitimate term "hacker" had not yet completely fallen from popular grace by this point in time. During the entire segment, the term "hacker" is actually only used once -- and that's in a Chyron banner identifying Draper as a "telephone hacker."
The old video is replete with quaint technology references and can't help but elicit quite a few smiles viewed from this distance. The video quality even after all my processing is very far from perfect, and as you'll see in the future there will be other items that will fall way short even of that level. But I'm striving to get them all into the best condition that I can.
I hope that you enjoy this initial offering from my archive.
1983 Video: "Captain Crunch" and "Computer Hacking" (TV Interview)
Greetings. It's always fascinating to view technology through the prism of many years ago. What did we think would happen? What actually did occur? Which predictions were on the mark? Which products were heavily hyped, only to go poof?
In the long ago days before the empire, I rather compulsively videotaped all manner of technology-related (yes, and other) goodies, on the theory that they might be interesting or useful some day in the far future.
Unfortunately, as former videotape aficionados know all too well, the half-life of videotapes (both Beta and VHS) can make CD and DVD physical decay seem positively charming by comparison.
This was especially true for many of my oldest tapes in Sony Beta (Betamax) format, many of which are now over three decades old. Over ten years ago, I discovered that these old tapes were not playable at all in any equipment available to me at the time, due to the tapes' long period of deterioration. The situation looked rather hopeless.
However, I very recently obtained a number of ancient Beta decks that were about to be trashed by their owners, and I decided that if the tapes were going to be saved for posterity (and my own amusement), now was the time. Any further delay in this process would likely have resulted in the tapes being completely unplayable on any equipment anywhere ever -- without resorting to a pact with Satan that is. And while I love YouTube, there's only so far I'll go in the name of content creation.
This is the setup I'm using to extract video from my grizzled Betamax tapes.
I've hobbled together this nightmare arrangement from three different Beta VCRs. The resulting hybrid deck (as shown) includes a number of major modifications (definitely not in the service manuals and possibly hazardous to the spacetime continuum) that I've been forced to improvise, resulting in a mechanism more or less capable of tracking decayed tapes -- at least with the help of some manual assistance -- that no individual VCR deck could track at all.
In fact, frequently during the transcription of these tapes, I'm actually mechanically riding the tape path tracking adjustments with a long screwdriver throughout playback to maintain tracking sync lock -- the trick to this is both the visual video cues on the monitor screen, and listening to the sound of the drum rotation servo lock oscillators as they go in and out of phase. Yeah, the technique is something of a lost art, to say the least.
[ Update (10/17/10): To deal with some of the most intensely damaged tapes, I additionally deployed this secret weapon with significant positive effects -- full explanation some other time! ]
Even with all this, while I could then display the videos on a monitor, my usual video digitizing cards would not reliably sync and track most of these tapes at all. Can anything else go wrong? So I switched to feeding the video output to a very stable camcorder A/D that also provides direct DV data -- rather than trying to encode to MPEG on the fly. This provides for maximum quality archivals for later processing. Years ago disk space costs would have made this prohibitively expensive. Now disk space just isn't an issue.
Interestingly, some of the oldest tapes are in somewhat better condition (relatively speaking) than newer ones. The reason is that the former were L-500 tape stock (2 hour tapes) instead of the later, more popular L-750s (3 hour). The 500s had thicker oxide backings, and so time/temperature/humidity-related stretching, print-through, oxide damage, and other effects were somewhat reduced -- a bit at least. Also the conventional linear audio tracks on all these tapes, though of comparatively limited fidelity, have held up much better than the Beta Hi-Fi audio that was encoded on subcarriers via the video heads. The latter are now much more subject to continuing dropouts.
If anyone is interested in more information about this entire process, feel free to drop me a line.
The results of this work should start appearing on YouTube soon. The collection of technology and other segments likely to materialize is perhaps somewhat eclectic -- but much of it is now pretty rare or likely one of a kind. Some will be in pretty poor condition, but at least should be watchable, and hopefully will be informative and enjoyable.
I'll notify as interesting items go online. Stay tuned.
Greetings. Late last June, in "VidMe" Announces Private Video Sharing -- But Fails Big Time, I expressed concerns regarding the privacy technology claims and business model of the "VidMe" video sharing service (announced at that time with great fanfare in the New York Times and other venues).
After my posting, the CEO of VidMe contacted me and we had a pleasant chat, he said that they'd be modifying their privacy claims, and that he'd keep me up to date on developments.
So I was somewhat surprised to receive an email from VidMe just now announcing the termination of the service, less than four months after it went live:
Thank you for being an early user of VidMe's beta video sharing service. Unfortunately, the consumer-facing site has not generated enough use to continue the service. As a result, we've made the difficult decision to discontinue this part of our business and focus on other applications of the technology. As of today, we are disabling the ability to upload, share, and view videos.
If you would like to download transcoded copies of videos you have previously uploaded, please email us at support at vidme dot com by 5 pm EST on Tuesday, October 12.
Good thing I didn't have any videos to download from VidMe -- the date of the notification message was already after 5 pm EST today! (What's this? A new email just popped into my inbox from VidMe, changing the deadline to obtain previously uploaded videos to October 19. At least now you don't need a time machine to ask for copies of your vids!)
I'm sorry to see any genuinely innovative project fail, but VidMe's model just didn't seem practical from the word go, and their privacy claims (initially at least) simply didn't make sense.
Promising more than you can deliver with these technologies is always very risky.
Something to remember ...
Greetings. Link shortening services have always been controversial to one extent or another. By injecting a third party into user interactions with Web sites, questions of reliability and privacy are frequently raised. And now, questions of religion have joined the fray, and Google has been drawn somewhat indirectly into the controversy as well.
Reliability is a factor since the failure -- or disappearance -- of a link shortening service would on its face appear to trigger the immediate uselessness of all links that have mapped through the associated shortening service throughout the service's lifetime.
Privacy questions enter the mix since the shortening service is typically in a position to capture significant information regarding the source and destination of the transaction, in the course of forwarding a user click to that ultimate destination.
Yet it is undeniable that link shortening provides important benefits, especially when dealing with email and other media where long links are ugly, inconvenient, or actually will not function properly.
I use link shortening extensively and routinely in my own email, where experience has taught me that long URLs cause a variety of problems for various recipients of my mailing lists, both due to MTA (Message Transport Agent) and MUA (Mail User Agent) issues. I get asked about this frequently enough that I have a chunk of boilerplate text I typically send in response. I sometimes joke that I see URLs that are so long that you can practically read the contents of the entire Web page from the URL itself without clicking through.
Long URLs can cause a real mess in email -- and including them along with a shortened version can cause the same problems as including them alone. In Web pages themselves, long links are much less problematic, and use of shortened links within such pages suggests primarily an interest in gathering click statistics on the part of the page author -- a practice that some observers condemn, but that I feel can be quite acceptable given appropriate privacy policies.
It would have seemed bizarre even a few weeks ago to suggest that religion would play a role in link shortening, but the Net is all abuzz about the disconnection of an adult-oriented link shortening service using the .ly (Libya) top level domain (TLD), due to the perceived impropriety of the service in the opinion of the associated TLD registry, essentially on religious grounds.
While fundamentally this sort of situation actually points to the increasingly dysfunctional nature of the Domain Name System itself, the more immediate side-effect of this action by the .ly registry has been to call into question the future stability of the extremely popular bit.ly link shortening service (to this point my choice for most link shortening).
Could the same thing happen to bit.ly that happened to the adult-oriented link shortening service? In the short term, the answer would appear to be no. The latter was explicitly aimed at adult sites, while bit.ly is a general purpose shortener with official Terms of Service that would seem to provide it considerable cover in this respect.
Also, bit.ly is actually an entire family of domains. There's bit.ly of course, but also j.mp, and a whole slew of "custom" domains that you may have seen such as nyti.ms, gizmo.do, wapo.st -- and innumerable others that are run by bit.ly and are actually interchangeable with bit.ly URLs (that is, you'll reach the same page with gizmo.do/foobar as you will with bit.ly/foobar). Obviously, many of these are related to statistics gathering and "vanity" addresses -- but note that virtually all depend on TLDs that are controlled by one or another non-U.S. countries, just like bit.ly itself.
Even Google's excellent goo.gl shortening service, which has very recently been opened up for general link shortening use by the world, is based on the TLD controlled by -- can you guess? -- Greenland.
The upshot of all this is that -- at least as long as we're saddled with the current domain name environment -- international registries and potentially their domestic government policies will be an integral part of most popular link shortening services.
In the wake of the recent moves by .ly, some observers have suggested that bit.ly (that's bit.ly proper, presumably not the various other bit.ly-controlled domain names not in the .ly TLD) should be viewed as unstable.
This may or may not be true in the long run, but tends to beg the question of how best to protect the reliability of shortened links against all manner of possible disruptions, including the potential for changes not only associated with international conditions and domestic governments, but also potential changes in business conditions and business operations on the part of link shortening services themselves.
To address this, almost a year ago the Internet Archive created 301works.org as an independent location for the "escrowing" of shortened link mappings, as protection against the disruption of any individual link shortening service. (Why "301" you ask? The Web HTTP status code for "Moved Permanently" is -- ta dah! -- 301.)
In fact, bit.ly is a founding member of 301works.org, and bit.ly's policy of escrowing their links is a major reason why I've been using them for my own link shortening.
It is both appropriate and desirable for every significant link shortening service to escrow their shortened links with 301works -- or some similar third party -- on a routine basis. To do so doesn't suggest that anyone expects the shortening service (or its "parent" firm) to vanish anytime soon. But having a copy of the link mappings in the hands of a trustworthy, independent third party makes enormous sense on general principles, and shows a willingness to put reliability -- even if the chances of disruptions seem vanishingly small -- above proprietary data principles.
I've urged Google on several occasions to consider escrowing their goo.gl links -- ideally with Internet Archive's 301works. There has apparently been some interest at Google in this suggestion, but no definitive movement to actually escrow those links (as far as I know).
Given that link shortening reliability is back in the spotlight, and goo.gl has now opened up for routine and broad use, I'm again renewing my call on Google to take proactive steps to protect their goo.gl link mappings through a third party. It's just the right thing to do.
Link shortening services possess various qualities of the proverbial double-edged sword -- both positive and negative aspects. They are extremely useful when used appropriately, but can be abused. And their reliability over time -- potentially very long spans of time -- is naturally of great concern, since if link mappings are lost, the value of vast numbers of pages will be decimated.
That's, uh, the long and the short of it.
Greetings. Well, it's official -- every firm involved in the mobile industry is suing some other company (or multiple companies) involved in cellular telecommunications technology -- or at least it seems that way.
I got bogged down trying to explain the various players to someone yesterday, and was inspired last night with the obvious solution -- a song!
So, with apologies to the great Tom Lehrer, I offer this extremely super-quickie parody with my own satirical take on his classic National Brotherhood Week.
I call my version, the Cellular Telecom Rush:
"Cellular Telecom Rush"
Lyrics Copyright © 2010 Lauren Weinstein. All rights reserved.
Oh Oracle's now suing Google,
But in the cellular telecom rush,
Oh Kodak's suing Apple,
Yet in the cellular telecom rush,
Microsoft sued Motorola,
But in the cellular telecom rush,
Greetings. An article published yesterday is mischaracterizing the situation with Android and the new T-Mobile (HTC) G2 by claiming the phone includes a "malicious root kit" -- a very scary (but false) assertion.
This sort of hyperbole does nobody any good. Here are the facts as I understand them.
First, it's important to know that while Android is an open source operating system, it does not require (as far as I know) that any given hardware manufacturer (or cell phone carrier) permit user modifications of the OS itself. In fact, carriers and manufacturers have considerable latitude regarding the degree to which they wish to "lock down" their hardware.
And indeed, most Android phones to date have been locked down to one degree or another, resulting in various tricks being used to bypass those locks to allow rooting (for installation of custom OS builds [ROMs], etc.) But the point is that most Android phones did not come out of the box with the ability to openly install such modifications (the N1 can be viewed as an exception).
Now, I really like rooted Android phones. I want to have complete control over my phone whenever possible -- just like PCs. I still use a very long-in-the-tooth Android G1 that is on its last legs -- I rooted it way back and I run the "CyanogenMod" custom ROM (which I highly recommend).
What's going on with the G2 (essentially the HTC Vision, it appears) is that initial experimentation suggests that HTC is using a firmware rewrite system to replace "/system" mods with the "official" firmware upon reboot. It is too early in the hacking process for anyone to state definitively that this mechanism will not be defeated -- it's fascinating how many ways cryptographic signature locks can be "incompletely" implemented.
If the G2 is actually using this kind of firmware protection system, it will be very similar to modern TiVos, which employ a (very difficult but not impossible to replace) PROM chip to create a "chain of trust" that eradicates attempts to modify the system. Obviously, the likelihood of a practical "chip replacement" solution (as far as most potential users are concerned) for devices at the cell phone integration level is fairly small -- but I would dare not say impossible.
The good news is that "temporary" root access on the G2 has been achieved -- the problem is that associated system changes get wiped the next time the phone is started. Temporary root may however be adequate for running of certain programs that need root access for best functionality (like backup programs) -- though much more is indeed required for the running of alternative system builds.
This trend toward locked-down systems is being driven both by support concerns (users who have screwed up their "unlocked" devices may still want support, want to return for refunds, etc.) and by security concerns.
Note that the latter issue in particular is reportedly already being discussed by Intel and others in terms of creating CPUs and systems for PCs that would operate in the context of cryptographically-signed software, potentially bringing a similar level of lock to the PC world (at least in theory).
Personally, I find this trend to be very disturbing. It has serious negative implications for user freedom and (perhaps surprisingly to some observers) major negative implications for privacy and security as well -- since users will no longer necessarily be able to run the OSes and applications of their choice, vetted to their own standards against security and privacy exploits.
In any case, I am unsure if I'd be willing to use an unrooted G2 on a routine basis -- but the calculus on this score can be different depending on expected usage patterns and other factors for any given individual. I don't necessarily expect the same level of modification friendliness on a cell phone as on a PC -- even if I'd prefer them to be similar in this respect, all else being equal.
But calling what's apparently going on with the G2 a "malicious root kit" is simply wrong. We can use the Wikipedia definition of "rootkit" for now, which is on the mark:
"A rootkit is software that enables continued privileged access to a computer, while actively hiding its presence from administrators by subverting standard operating system functionality or other applications."
This clearly does not apply to the G2's OS protection system as currently understood. In fact, one could argue that the G2 may have implemented an "anti-rootkit" -- since the mechanism appears designed to prevent the installation of "nonstandard" OS functionality by protecting the "official" code from modification.
So let's try to at least keep this discussion in the realm of reality. I don't like locked-down systems. I like user choice. I'd prefer the G2 be fully modifiable, and I'm (wait for it ...) "rooting for it to be rooted."
But it's inappropriate to be referring to the G2's (or TiVo's, for that matter) OS protection systems by the term "malicious root kits" -- and the use of such inaccurate terminology in such cases does not advance the cause of user software freedom.
Even when -- especially when -- we disagree with a technology policy approach, it's very important that we attempt to avoid hyperbole and less than rigorously accurate statements -- both of which can be used by others as weapons against our points of view.