Bruce Sterling - The Hacker Crackdown

7. Placing the Document in an index took two clerks an hour each, totalling $43.

Bureaucratic overhead alone, therefore, was alleged to have cost a whopping $17,099. According to Mr. Megahee, the typing of a twelve-page document had taken a full week. Writing it had taken five weeks, including an overseer who apparently did nothing else but watch the author for five weeks. Editing twelve pages had taken two days. Printing and mailing an electronic document (which was already available on the Southern Bell Data Network to any telco employee who needed it), had cost over a thousand dollars.

But this was just the beginning. There were also the *hardware expenses.* Eight hundred fifty dollars for a VT220 computer monitor. *Thirty-one thousand dollars* for a sophisticated VAXstation II computer. Six thousand dollars for a computer printer. *Twenty-two thousand dollars* for a copy of "Interleaf" software. Two thousand five hundred dollars for VMS software. All this to create the twelve-page Document.

Plus ten percent of the cost of the software and the hardware, for maintenance. (Actually, the ten percent maintenance costs, though mentioned, had been left off the final $79,449 total, apparently through a merciful oversight).

Mr. Megahee's letter had been mailed directly to William Cook himself, at the office of the Chicago federal attorneys. The United States Government accepted these telco figures without question.

As incredulity mounted, the value of the E911 Document was officially revised downward. This time, Robert Kibler of BellSouth Security estimated the value of the twelve pages as a mere $24,639.05 -- based, purportedly, on "R&D costs." But this specific estimate, right down to the nickel, did not move the skeptics at all; in fact it provoked open scorn and a torrent of sarcasm.

The financial issues concerning theft of proprietary information have always been peculiar. It could be argued that BellSouth had not "lost" its E911 Document at all in the first place, and therefore had not suffered any monetary damage from this "theft." And Sheldon Zenner did in fact argue this at Neidorf's trial -- that Prophet's raid had not been "theft," but was better understood as illicit copying.

The money, however, was not central to anyone's true purposes in this trial. It was not Cook's strategy to convince the jury that the E911 Document was a major act of theft and should be punished for that reason alone. His strategy was to argue that the E911 Document was *dangerous.* It was his intention to establish that the E911 Document was "a road-map" to the Enhanced 911 System. Neidorf had deliberately and recklessly distributed a dangerous weapon. Neidorf and the Prophet did not care (or perhaps even gloated at the sinister idea) that the E911 Document could be used by hackers to disrupt 911 service, "a life line for every person certainly in the Southern Bell region of the United States, and indeed, in many communities throughout the United States," in Cook's own words. Neidorf had put people's lives in danger.

In pre-trial maneuverings, Cook had established that the E911 Document was too hot to appear in the public proceedings of the Neidorf trial. The *jury itself* would not be allowed to ever see this Document, lest it slip into the official court records, and thus into the hands of the general public, and, thus, somehow, to malicious hackers who might lethally abuse it.

Hiding the E911 Document from the jury may have been a clever legal maneuver, but it had a severe flaw. There were, in point of fact, hundreds, perhaps thousands, of people, already in possession of the E911 Document, just as *Phrack* had published it. Its true nature was already obvious to a wide section of the interested public (all of whom, by the way, were, at least theoretically, party to a gigantic wire-fraud conspiracy). Most everyone in the electronic community who had a modem and any interest in the Neidorf case already had a copy of the Document. It had already been available in *Phrack* for over a year.

People, even quite normal people without any particular prurient interest in forbidden knowledge, did not shut their eyes in terror at the thought of beholding a "dangerous" document from a telephone company. On the contrary, they tended to trust their own judgement and simply read the Document for themselves. And they were not impressed.

One such person was John Nagle. Nagle was a forty- one-year-old professional programmer with a masters' degree in computer science from Stanford. He had worked for Ford Aerospace, where he had invented a computer-networking technique known as the "Nagle Algorithm," and for the prominent Californian computer- graphics firm "Autodesk," where he was a major stockholder.

Nagle was also a prominent figure on the Well, much respected for his technical knowledgeability.

Nagle had followed the civil-liberties debate closely, for he was an ardent telecommunicator. He was no particular friend of computer intruders, but he believed electronic publishing had a great deal to offer society at large, and attempts to restrain its growth, or to censor free electronic expression, strongly roused his ire.

The Neidorf case, and the E911 Document, were both being discussed in detail on the Internet, in an electronic publication called *Telecom Digest.* Nagle, a longtime Internet maven, was a regular reader of *Telecom Digest.* Nagle had never seen a copy of *Phrack,* but the implications of the case disturbed him.

While in a Stanford bookstore hunting books on robotics, Nagle happened across a book called *The Intelligent Network.* Thumbing through it at random, Nagle came across an entire chapter meticulously detailing the workings of E911 police emergency systems. This extensive text was being sold openly, and yet in Illinois a young man was in danger of going to prison for publishing a thin six-page document about 911 service.

Nagle made an ironic comment to this effect in *Telecom Digest.* From there, Nagle was put in touch with Mitch Kapor, and then with Neidorf's lawyers.

Sheldon Zenner was delighted to find a computer telecommunications expert willing to speak up for Neidorf, one who was not a wacky teenage "hacker." Nagle was fluent, mature, and respectable; he'd once had a federal security clearance.

Nagle was asked to fly to Illinois to join the defense team.

Having joined the defense as an expert witness, Nagle read the entire E911 Document for himself. He made his own judgement about its potential for menace.

The time has now come for you yourself, the reader, to have a look at the E911 Document. This six-page piece of work was the pretext for a federal prosecution that could have sent an electronic publisher to prison for thirty, or even sixty, years. It was the pretext for the search and seizure of Steve Jackson Games, a legitimate publisher of printed books. It was also the formal pretext for the search and seizure of the Mentor's bulletin board, "Phoenix Project," and for the raid on the home of Erik Bloodaxe. It also had much to do with the seizure of Richard Andrews' Jolnet node and the shutdown of Charles Boykin's AT&T node. The E911 Document was the single most important piece of evidence in the Hacker Crackdown. There can be no real and legitimate substitute for the Document itself.

==Phrack Inc.==

Volume Two, Issue 24, File 5 of 13

Control Office Administration Of Enhanced 911 Services For Special Services and Account Centers

by the Eavesdropper

March, 1988

Description of Service ~~~~~~~~~~~~~~~~~~~~~~ The control office for Emergency 911 service is assigned in accordance with the existing standard guidelines to one of the following centers:

o Special Services Center (SSC) o Major Accounts Center (MAC) o Serving Test Center (STC) o Toll Control Center (TCC)

The SSC/MAC designation is used in this document interchangeably for any of these four centers. The Special Services Centers (SSCs) or Major Account Centers (MACs) have been designated as the trouble reporting contact for all E911 customer (PSAP) reported troubles. Subscribers who have trouble on an E911 call will continue to contact local repair service (CRSAB) who will refer the trouble to the SSC/MAC, when appropriate.