trouble to the SSC/MAC, when appropriate.
Due to the critical nature of E911 service, the control and
timely repair of troubles is demanded. As the primary
E911 customer contact, the SSC/MAC is in the unique
position to monitor the status of the trouble and insure its
resolution.
System Overview
~~~~~~~~~~~~~~~
The number 911 is intended as a nationwide universal
telephone number which provides the public with direct
access to a Public Safety Answering Point (PSAP). A PSAP
is also referred to as an Emergency Service Bureau (ESB).
A PSAP is an agency or facility which is authorized by a
municipality to receive and respond to police, fire and/or
ambulance services. One or more attendants are located
at the PSAP facilities to receive and handle calls of an
emergency nature in accordance with the local municipal
requirements.
An important advantage of E911 emergency service is
improved (reduced) response times for emergency
services. Also close coordination among agencies
providing various emergency services is a valuable
capability provided by E911 service.
1A ESS is used as the tandem office for the E911 network to
route all 911 calls to the correct (primary) PSAP designated
to serve the calling station. The E911 feature was
developed primarily to provide routing to the correct PSAP
for all 911 calls. Selective routing allows a 911 call
originated from a particular station located in a particular
district, zone, or town, to be routed to the primary PSAP
designated to serve that customer station regardless of
wire center boundaries. Thus, selective routing eliminates
the problem of wire center boundaries not coinciding with
district or other political boundaries.
The services available with the E911 feature include:
Forced Disconnect Default Routing
Alternative Routing Night Service
Selective Routing Automatic Number
Identification (ANI)
Selective Transfer Automatic Location
Identification (ALI)
Preservice/Installation Guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a contract for an E911 system has been signed, it is
the responsibility of Network Marketing to establish an
implementation/cutover committee which should include
a representative from the SSC/MAC. Duties of the E911
Implementation Team include coordination of all phases
of the E911 system deployment and the formation of an
on-going E911 maintenance subcommittee.
Marketing is responsible for providing the following
customer specific information to the SSC/MAC prior to
the start of call through testing:
o All PSAP's (name, address, local contact)
o All PSAP circuit ID's
o 1004 911 service request including PSAP details on each
PSAP
(1004 Section K, L, M)
o Network configuration
o Any vendor information (name, telephone number,
equipment)
The SSC/MAC needs to know if the equipment and sets at
the PSAP are maintained by the BOCs, an independent
company, or an outside vendor, or any combination. This
information is then entered on the PSAP profile sheets
and reviewed quarterly for changes, additions and
deletions.
Marketing will secure the Major Account Number (MAN)
and provide this number to Corporate Communications
so that the initial issue of the service orders carry the
MAN and can be tracked by the SSC/MAC via
CORDNET. PSAP circuits are official services by
definition.
All service orders required for the installation of the E911
system should include the MAN assigned to the
city/county which has purchased the system.
In accordance with the basic SSC/MAC strategy for
provisioning, the SSC/MAC will be Overall Control Office
(OCO) for all Node to PSAP circuits (official services) and
any other services for this customer. Training must be
scheduled for all SSC/MAC involved personnel during the
pre-service stage of the project.
The E911 Implementation Team will form the on-going
maintenance subcommittee prior to the initial
implementation of the E911 system. This sub-committee
will establish post implementation quality assurance
procedures to ensure that the E911 system continues to
provide quality service to the customer.
Customer/Company training, trouble reporting interfaces
for the customer, telephone company and any involved
independent telephone companies needs to be addressed
and implemented prior to E911 cutover. These functions
can be best addressed by the formation of a sub-
committee of the E911 Implementation Team to set up
guidelines for and to secure service commitments of
interfacing organizations. A SSC/MAC supervisor should
chair this subcommittee and include the following
organizations:
1) Switching Control Center
- E911 translations
- Trunking
- End office and Tandem office hardware/software
2) Recent Change Memory Administration Center
- Daily RC update activity for TN/ESN translations
- Processes validity errors and rejects
3) Line and Number Administration
- Verification of TN/ESN translations
4) Special Service Center/Major Account Center
- Single point of contact for all PSAP and Node to
host
troubles
- Logs, tracks & statusing of all trouble reports
- Trouble referral, follow up, and escalation
- Customer notification of status and restoration
- Analyzation of "chronic" troubles
- Testing, installation and maintenance of E911
circuits
5) Installation and Maintenance (SSIM/I&M)
- Repair and maintenance of PSAP equipment and
Telco owned sets
6) Minicomputer Maintenance Operations Center
- E911 circuit maintenance (where applicable)
7) Area Maintenance Engineer
- Technical assistance on voice (CO-PSAP) network
related E911 troubles
Maintenance Guidelines
~~~~~~~~~~~~~~~~~~~~~~
The CCNC will test the Node circuit from the 202T at the
Host site to the 202T at the Node site. Since Host to Node
(CCNC to MMOC) circuits are official company services,
the CCNC will refer all Node circuit troubles to the
SSC/MAC. The SSC/MAC is responsible for the testing
and follow up to restoration of these circuit troubles.
Although Node to PSAP circuit are official services, the
MMOC will refer PSAP circuit troubles to the appropriate
SSC/MAC. The SSC/MAC is responsible for testing and
follow up to restoration of PSAP circuit troubles.
The SSC/MAC will also receive reports from
CRSAB/IMC(s) on subscriber 911 troubles when they are
not line troubles. The SSC/MAC is responsible for testing
and restoration of these troubles.
Maintenance responsibilities are as follows:
SCC* Voice Network (ANI to PSAP)
*SCC responsible for tandem switch
SSIM/I&M PSAP Equipment (Modems, CIU's, sets)
Vendor PSAP Equipment (when CPE)
SSC/MAC PSAP to Node circuits, and tandem to
PSAP voice circuits (EMNT)
MMOC Node site (Modems, cables, etc)
Note: All above work groups are required to resolve
troubles by interfacing with appropriate work groups for
resolution.
The Switching Control Center (SCC) is responsible for
E911/1AESS translations in tandem central offices. These
translations route E911 calls, selective transfer, default
routing, speed calling, etc., for each PSAP. The SCC is
also
responsible for troubleshooting on the voice network (call
originating to end office tandem equipment).
For example, ANI failures in the originating offices would
be a responsibility of the SCC.
Recent Change Memory Administration Center
(RCMAC) performs the daily tandem translation updates
(recent change) for routing of individual telephone
numbers.
Recent changes are generated from service order activity
(new service, address changes, etc.) and compiled into a
daily file by the E911 Center (ALI/DMS E911 Computer).
SSIM/I&M is responsible for the installation and repair of
PSAP equipment. PSAP equipment includes ANI
Controller, ALI Controller, data sets, cables, sets, and
other peripheral equipment that is not vendor owned.
SSIM/I&M is responsible for establishing maintenance
test kits, complete with spare parts for PSAP maintenance.
This includes test gear, data sets, and ANI/ALI Controller
parts.
Special Services Center (SSC) or Major Account Center
(MAC) serves as the trouble reporting contact for all
(PSAP) troubles reported by customer. The SSC/MAC
refers troubles to proper organizations for handling and
tracks status of troubles, escalating when necessary. The
SSC/MAC will close out troubles with customer. The
SSC/MAC will analyze all troubles and tracks "chronic"
PSAP troubles.
Corporate Communications Network Center (CCNC) will
test and refer troubles on all node to host circuits. All
E911
circuits are classified as official company property.
The Minicomputer Maintenance Operations Center
(MMOC) maintains the E911 (ALI/DMS) computer
hardware at the Host site. This MMOC is also responsible
for monitoring the system and reporting certain PSAP and
system problems to the local MMOC's, SCC's or
SSC/MAC's. The MMOC personnel also operate software
programs that maintain the TN data base under the
direction of the E911 Center. The maintenance of the
NODE computer (the interface between the PSAP and the
ALI/DMS computer) is a function of the MMOC at the
NODE site. The MMOC's at the NODE sites may also be
involved in the testing of NODE to Host circuits. The
MMOC will also assist on Host to PSAP and data network
related troubles not resolved through standard trouble
clearing procedures.
Installation And Maintenance Center (IMC) is
responsible for referral of E911 subscriber troubles that
are not subscriber line problems.
E911 Center - Performs the role of System Administration
and is responsible for overall operation of the E911
computer software. The E911 Center does A-Z trouble
analysis and provides statistical information on the
performance of the system.
This analysis includes processing PSAP inquiries (trouble
reports) and referral of network troubles. The E911 Center
also performs daily processing of tandem recent change
and provides information to the RCMAC for tandem
input. The E911 Center is responsible for daily processing
of the ALI/DMS computer data base and provides error
files, etc. to the Customer Services department for
investigation and correction. The E911 Center participates
in all system implementations and on-going maintenance
effort and assists in the development of procedures,
training and education of information to all groups.
Any group receiving a 911 trouble from the SSC/MAC
should close out the trouble with the SSC/MAC or provide
a status if the trouble has been referred to another group.
This will allow the SSC/MAC to provide a status back to
the customer or escalate as appropriate.
Any group receiving a trouble from the Host site (MMOC
or CCNC) should close the trouble back to that group.
The MMOC should notify the appropriate SSC/MAC
when the Host, Node, or all Node circuits are down so that
the SSC/MAC can reply to customer reports that may be
called in by the PSAPs. This will eliminate duplicate
reporting of troubles. On complete outages the MMOC
will follow escalation procedures for a Node after two (2)
hours and for a PSAP after four (4) hours. Additionally the
MMOC will notify the appropriate SSC/MAC when the
Host, Node, or all Node circuits are down.
The PSAP will call the SSC/MAC to report E911 troubles.
The person reporting the E911 trouble may not have a
circuit I.D. and will therefore report the PSAP name and
address. Many PSAP troubles are not circuit specific. In
those instances where the caller cannot provide a circuit
I.D., the SSC/MAC will be required to determine the
circuit I.D. using the PSAP profile. Under no
circumstances will the SSC/MAC Center refuse to take
the trouble. The E911 trouble should be handled as
quickly as possible, with the SSC/MAC providing as much
assistance as possible while taking the trouble report from
the caller.
The SSC/MAC will screen/test the trouble to determine
the appropriate handoff organization based on the
following criteria:
PSAP equipment problem: SSIM/I&M
Circuit problem: SSC/MAC
Voice network problem: SCC (report trunk group
number)
Problem affecting multiple PSAPs (No ALI report from
all PSAPs): Contact the MMOC to check for NODE or
Host computer problems before further testing.
The SSC/MAC will track the status of reported troubles
and escalate as appropriate. The SSC/MAC will close out
customer/company reports with the initiating contact.
Groups with specific maintenance responsibilities,
defined above, will investigate "chronic" troubles upon
request from the SSC/MAC and the ongoing maintenance
subcommittee.
All "out of service" E911 troubles are priority one type
reports. One link down to a PSAP is considered a priority
one trouble and should be handled as if the PSAP was
isolated.
The PSAP will report troubles with the ANI controller, ALI
controller or set equipment to the SSC/MAC.
NO ANI: Where the PSAP reports NO ANI (digital
display screen is blank) ask if this condition exists on all
screens and on all calls. It is important to differentiate
between blank screens and screens displaying 911-00XX,
or all zeroes.
When the PSAP reports all screens on all calls, ask if there
is any voice contact with callers. If there is no voice
contact the trouble should be referred to the SCC
immediately since 911 calls are not getting through which
may require alternate routing of calls to another PSAP.
When the PSAP reports this condition on all screens but
not all calls and has voice contact with callers, the report
should be referred to SSIM/I&M for dispatch. The
SSC/MAC should verify with the SCC that ANI is pulsing
before dispatching SSIM.
When the PSAP reports this condition on one screen for
all calls (others work fine) the trouble should be referred
to
SSIM/I&M for dispatch, because the trouble is isolated to
one piece of equipment at the customer premise.
An ANI failure (i.e. all zeroes) indicates that the ANI has
not been received by the PSAP from the tandem office or
was lost by the PSAP ANI controller. The PSAP may
receive "02" alarms which can be caused by the ANI
controller logging more than three all zero failures on the
same trunk. The PSAP has been instructed to report this
condition to the SSC/MAC since it could indicate an
equipment trouble at the PSAP which might be affecting
all subscribers calling into the PSAP. When all zeroes are
being received on all calls or "02" alarms continue, a
tester
should analyze the condition to determine the appropriate
action to be taken. The tester must perform cooperative
testing with the SCC when there appears to be a problem
on the Tandem-PSAP trunks before requesting dispatch.
When an occasional all zero condition is reported, the
SSC/MAC should dispatch SSIM/I&M to routine
equipment on a "chronic" troublesweep.
The PSAPs are instructed to report incidental ANI failures
to the BOC on a PSAP inquiry trouble ticket (paper) that is
sent to the Customer Services E911 group and forwarded
to E911 center when required. This usually involves only a
particular telephone number and is not a condition that
would require a report to the SSC/MAC. Multiple ANI
failures which our from the same end office (XX denotes
end office), indicate a hard trouble condition may exist in
the end office or end office tandem trunks. The PSAP will
report this type of condition to the SSC/MAC and the
SSC/MAC should refer the report to the SCC responsible
for the tandem office. NOTE: XX is the ESCO (Emergency
Service Number) associated with the incoming 911 trunks
into the tandem. It is important that the C/MAC tell the
SCC what is displayed at the PSAP (i.e. 911-0011) which
indicates to the SCC which end office is in trouble.
Note: It is essential that the PSAP fill out inquiry form
on
every ANI failure.
The PSAP will report a trouble any time an address is not
received on an address display (screen blank) E911 call.
(If a record is not in the 911 data base or an ANI failure
is
encountered, the screen will provide a display noticing
such condition). The SSC/MAC should verify with the
PSAP whether the NO ALI condition is on one screen or all
screens.
When the condition is on one screen (other screens
receive ALI information) the SSC/MAC will request
SSIM/I&M to dispatch.
If no screens are receiving ALI information, there is
usually a circuit trouble between the PSAP and the Host
computer. The SSC/MAC should test the trouble and
refer for restoral.
Note: If the SSC/MAC receives calls from multiple
PSAP's, all of which are receiving NO ALI, there is a
problem with the Node or Node to Host circuits or the
Host computer itself. Before referring the trouble the
SSC/MAC should call the MMOC to inquire if the Node
or Host is in trouble.
Alarm conditions on the ANI controller digital display at
the PSAP are to be reported by the PSAP's. These alarms
can indicate various trouble conditions so the SSC/MAC
should ask the PSAP if any portion of the E911 system is
not functioning properly.
The SSC/MAC should verify with the PSAP attendant that
the equipment's primary function is answering E911 calls.
If it is, the SSC/MAC should request a dispatch
SSIM/I&M. If the equipment is not primarily used for
E911, then the SSC/MAC should advise PSAP to contact
their CPE vendor.
Note: These troubles can be quite confusing when the
PSAP has vendor equipment mixed in with equipment
that the BOC maintains. The Marketing representative
should provide the SSC/MAC information concerning any
unusual or exception items where the PSAP should
contact their vendor. This information should be included
in the PSAP profile sheets.
ANI or ALI controller down: When the host computer
sees the PSAP equipment down and it does not come back
up, the MMOC will report the trouble to the SSC/MAC;
the equipment is down at the PSAP, a dispatch will be
required.
PSAP link (circuit) down: The MMOC will provide the
SSC/MAC with the circuit ID that the Host computer
indicates in trouble. Although each PSAP has two circuits,
when either circuit is down the condition must be treated
as an emergency since failure of the second circuit will
cause the PSAP to be isolated.
Any problems that the MMOC identifies from the Node
location to the Host computer will be handled directly with
the appropriate MMOC(s)/CCNC.
Note: The customer will call only when a problem is
apparent to the PSAP. When only one circuit is down to
the PSAP, the customer may not be aware there is a
trouble, even though there is one link down, notification
should appear on the PSAP screen. Troubles called into
the SSC/MAC from the MMOC or other company
employee should not be closed out by calling the PSAP
since it may result in the customer responding that they
do not have a trouble. These reports can only be closed
out by receiving information that the trouble was fixed
and by checking with the company employee that
reported the trouble. The MMOC personnel will be able
to verify that the trouble has cleared by reviewing a
printout from the host.
When the CRSAB receives a subscriber complaint (i.e.,
cannot dial 911) the RSA should obtain as much
information as possible while the customer is on the line.
For example, what happened when the subscriber dialed
911? The report is automatically directed to the IMC for
subscriber line testing. When no line trouble is found, the
IMC will refer the trouble condition to the SSC/MAC. The
SSC/MAC will contact Customer Services E911 Group and
verify that the subscriber should be able to call 911 and
obtain the ESN. The SSC/MAC will verify the ESN via
2SCCS. When both verifications match, the SSC/MAC
will refer the report to the SCC responsible for the 911
tandem office for investigation and resolution. The MAC
is responsible for tracking the trouble and informing the
IMC when it is resolved.
For more information, please refer to E911 Glossary of
Terms.
End of Phrack File
_____________________________________
The reader is forgiven if he or she was entirely unable
to read this document. John Perry Barlow had a great
deal of fun at its expense, in "Crime and Puzzlement:"
"Bureaucrat-ese of surpassing opacity.... To read the whole
thing straight through without entering coma requires
either a machine or a human who has too much practice
thinking like one. Anyone who can understand it fully and
fluidly had altered his consciousness beyone the ability to
ever again read Blake, Whitman, or Tolstoy.... the
document contains little of interest to anyone who is not a
student of advanced organizational sclerosis."
With the Document itself to hand, however, exactly
as it was published (in its six-page edited form) in
*Phrack,* the reader may be able to verify a few
statements of fact about its nature. First, there is no
software, no computer code, in the Document. It is not
computer-programming language like FORTRAN or C++,
it is English; all the sentences have nouns and verbs and
punctuation. It does not explain how to break into the
E911 system. It does not suggest ways to destroy or
damage the E911 system.
There are no access codes in the Document. There
are no computer passwords. It does not explain how to
steal long distance service. It does not explain how to
break in to telco switching stations. There is nothing in
it
about using a personal computer or a modem for any
purpose at all, good or bad.
Close study will reveal that this document is not
about machinery. The E911 Document is about
*administration.* It describes how one creates and
administers certain units of telco bureaucracy: Special
Service Centers and Major Account Centers (SSC/MAC).
It describes how these centers should distribute
responsibility for the E911 service, to other units of telco
bureaucracy, in a chain of command, a formal hierarchy.
It describes who answers customer complaints, who
screens calls, who reports equipment failures, who answers
those reports, who handles maintenance, who chairs
subcommittees, who gives orders, who follows orders,
*who* tells *whom* what to do. The Document is not a
"roadmap" to computers. The Document is a roadmap to
*people.*
As an aid to breaking into computer systems, the
Document is *useless.* As an aid to harassing and
deceiving telco people, however, the Document might
prove handy (especially with its Glossary, which I have not
included). An intense and protracted study of this
Document and its Glossary, combined with many other
such documents, might teach one to speak like a telco
employee. And telco people live by *speech* -- they live
by phone communication. If you can mimic their
language over the phone, you can "social-engineer" them.
If you can con telco people, you can wreak havoc among
them. You can force them to no longer trust one another;
you can break the telephonic ties that bind their
community; you can make them paranoid. And people
will fight harder to defend their community than they will
fight to defend their individual selves.
This was the genuine, gut-level threat posed by
*Phrack* magazine. The real struggle was over the control
of telco language, the control of telco knowledge. It was a
struggle to defend the social "membrane of
differentiation" that forms the walls of the telco
community's ivory tower -- the special jargon that allows
telco professionals to recognize one another, and to
exclude charlatans, thieves, and upstarts. And the
prosecution brought out this fact. They repeatedly made
reference to the threat posed to telco professionals by
hackers using "social engineering."
However, Craig Neidorf was not on trial for learning
to speak like a professional telecommunications expert.
Craig Neidorf was on trial for access device fraud and
transportation of stolen property. He was on trial for
stealing a document that was purportedly highly sensitive
and purportedly worth tens of thousands of dollars.
#
John Nagle read the E911 Document. He drew his
own conclusions. And he presented Zenner and his
defense team with an overflowing box of similar material,
drawn mostly from Stanford University's engineering
libraries. During the trial, the defense team -- Zenner,
half-a-dozen other attorneys, Nagle, Neidorf, and
computer-security expert Dorothy Denning, all pored
over the E911 Document line-by-line.
On the afternoon of July 25, 1990, Zenner began to
cross-examine a woman named Billie Williams, a service
manager for Southern Bell in Atlanta. Ms. Williams had
been responsible for the E911 Document. (She was not its
author -- its original "author" was a Southern Bell staff
manager named Richard Helms. However, Mr. Helms
should not bear the entire blame; many telco staff people
and maintenance personnel had amended the
Document. It had not been so much "written" by a single
author, as built by committee out of concrete-blocks of
jargon.)
Ms. Williams had been called as a witness for the
prosecution, and had gamely tried to explain the basic
technical structure of the E911 system, aided by charts.
Now it was Zenner's turn. He first established that
the "proprietary stamp" that BellSouth had used on the
E911 Document was stamped on *every single document*
that BellSouth wrote -- *thousands* of documents. "We
do not publish anything other than for our own company,"
Ms. Williams explained. "Any company document of this
nature is considered proprietary." Nobody was in charge
of singling out special high-security publications for
special high-security protection. They were *all* special,
no matter how trivial, no matter what their subject matter -
- the stamp was put on as soon as any document was
written, and the stamp was never removed.
Zenner now asked whether the charts she had been
using to explain the mechanics of E911 system were
"proprietary," too. Were they *public information,* these
charts, all about PSAPs, ALIs, nodes, local end switches?
Could he take the charts out in the street and show them
to anybody, "without violating some proprietary notion
that BellSouth has?"
Ms Williams showed some confusion, but finally
agreed that the charts were, in fact, public.
"But isn't this what you said was basically what
appeared in *Phrack?*"
Ms. Williams denied this.
Zenner now pointed out that the E911 Document as
published in Phrack was only half the size of the original
E911 Document (as Prophet had purloined it). Half of it
had been deleted -- edited by Neidorf.
Ms. Williams countered that "Most of the
information that is in the text file is redundant."
Zenner continued to probe. Exactly what bits of
knowledge in the Document were, in fact, unknown to the
public? Locations of E911 computers? Phone numbers for
telco personnel? Ongoing maintenance subcommittees?
Hadn't Neidorf removed much of this?
Then he pounced. "Are you familiar with Bellcore
Technical Reference Document TR-TSY-000350?" It was,
Zenner explained, officially titled "E911 Public Safety
Answering Point Interface Between 1-1AESS Switch and
Customer Premises Equipment." It contained highly
detailed and specific technical information about the E911
System. It was published by Bellcore and publicly
available for about $20.
He showed the witness a Bellcore catalog which listed
thousands of documents from Bellcore and from all the
Baby Bells, BellSouth included. The catalog, Zenner
pointed out, was free. Anyone with a credit card could call
the Bellcore toll-free 800 number and simply order any of
these documents, which would be shipped to any
customer without question. Including, for instance,
"BellSouth E911 Service Interfaces to Customer Premises
Equipment at a Public Safety Answering Point."
Zenner gave the witness a copy of "BellSouth E911
Service Interfaces," which cost, as he pointed out, $13,
straight from the catalog. "Look at it carefully," he urged
Ms. Williams, "and tell me if it doesn't contain about twice
as much detailed information about the E911 system of
BellSouth than appeared anywhere in *Phrack.*"
"You want me to...." Ms. Williams trailed off. "I
don't
understand."
"Take a careful look," Zenner persisted. "Take a look
at that document, and tell me when you're done looking at
it if, indeed, it doesn't contain much more detailed
information about the E911 system than appeared in
*Phrack.*"
"*Phrack* wasn't taken from this," Ms. Williams said.
"Excuse me?" said Zenner.
"*Phrack* wasn't taken from this."
"I can't hear you," Zenner said.
"*Phrack* was not taken from this document. I don't
understand your question to me."
"I guess you don't," Zenner said.
At this point, the prosecution's case had been
gutshot. Ms. Williams was distressed. Her confusion was
quite genuine. *Phrack* had not been taken from any
publicly available Bellcore document. *Phrack*'s E911
Document had been stolen from her own company's
computers, from her own company's text files, that her
own colleagues had written, and revised, with much labor.
But the "value" of the Document had been blown to
smithereens. It wasn't worth eighty grand. According to
Bellcore it was worth thirteen bucks. And the looming
menace that it supposedly posed had been reduced in
instants to a scarecrow. Bellcore itself was selling
material
far more detailed and "dangerous," to anybody with a
credit card and a phone.
Actually, Bellcore was not giving this information to
just anybody. They gave it to *anybody who asked,* but
not many did ask. Not many people knew that Bellcore
had a free catalog and an 800 number. John Nagle knew,
but certainly the average teenage phreak didn't know.
"Tuc," a friend of Neidorf's and sometime *Phrack*
contributor, knew, and Tuc had been very helpful to the
defense, behind the scenes. But the Legion of Doom
didn't know -- otherwise, they would never have wasted so
much time raiding dumpsters. Cook didn't know. Foley
didn't know. Kluepfel didn't know. The right hand of
Bellcore knew not what the left hand was doing. The right
hand was battering hackers without mercy, while the left
hand was distributing Bellcore's intellectual property to
anybody who was interested in telephone technical trivia --
apparently, a pathetic few.
The digital underground was so amateurish and
poorly organized that they had never discovered this heap
of unguarded riches. The ivory tower of the telcos was so
wrapped-up in the fog of its own technical obscurity that it
had left all the windows open and flung open the doors.
No one had even noticed.
Zenner sank another nail in the coffin. He produced
a printed issue of *Telephone Engineer & Management,*
a prominent industry journal that comes out twice a
month and costs $27 a year. This particular issue of
*TE&M,* called "Update on 911," featured a galaxy of
technical details on 911 service and a glossary far more
extensive than *Phrack*'s.
The trial rumbled on, somehow, through its own
momentum. Tim Foley testified about his interrogations
of Neidorf. Neidorf's written admission that he had known
the E911 Document was pilfered was officially read into
the court record.
An interesting side issue came up: "Terminus" had
once passed Neidorf a piece of UNIX AT&T software, a
log-in sequence, that had been cunningly altered so that it
could trap passwords. The UNIX software itself was
illegally copied AT&T property, and the alterations
"Terminus" had made to it, had transformed it into a
device for facilitating computer break-ins. Terminus
himself would eventually plead guilty to theft of this piece
of software, and the Chicago group would send Terminus
to prison for it. But it was of dubious relevance in the
Neidorf case. Neidorf hadn't written the program. He
wasn't accused of ever having used it. And Neidorf wasn't
being charged with software theft or owning a password
trapper.
On the next day, Zenner took the offensive. The civil
libertarians now had their own arcane, untried legal
weaponry to launch into action -- the Electronic
Communications Privacy Act of 1986, 18 US Code, Section
2701 et seq. Section 2701 makes it a crime to
intentionally
access without authorization a facility in which an
electronic communication service is provided -- it is, at
heart, an anti-bugging and anti-tapping law, intended to
carry the traditional protections of telephones into other
electronic channels of communication. While providing
penalties for amateur snoops, however, Section 2703 of the
ECPA also lays some formal difficulties on the bugging
and tapping activities of police.
The Secret Service, in the person of Tim Foley, had
served Richard Andrews with a federal grand jury
subpoena, in their pursuit of Prophet, the E911 Document,
and the Terminus software ring. But according to the
Electronic Communications Privacy Act, a "provider of
remote computing service" was legally entitled to "prior
notice" from the government if a subpoena was used.
Richard Andrews and his basement UNIX node, Jolnet,
had not received any "prior notice." Tim Foley had
purportedly violated the ECPA and committed an
electronic crime! Zenner now sought the judge's
permission to cross-examine Foley on the topic of Foley's
own electronic misdeeds.
Cook argued that Richard Andrews' Jolnet was a
privately owned bulletin board, and not within the purview
of ECPA. Judge Bua granted the motion of the
government to prevent cross-examination on that point,
and Zenner's offensive fizzled. This, however, was the
first
direct assault on the legality of the actions of the
Computer Fraud and Abuse Task Force itself -- the first
suggestion that they themselves had broken the law, and
might, perhaps, be called to account.
Zenner, in any case, did not really need the ECPA.
Instead, he grilled Foley on the glaring contradictions in
the supposed value of the E911 Document. He also
brought up the embarrassing fact that the supposedly red-
hot E911 Document had been sitting around for months,
in Jolnet, with Kluepfel's knowledge, while Kluepfel had
done nothing about it.
In the afternoon, the Prophet was brought in to testify
for the prosecution. (The Prophet, it will be recalled, had
also been indicted in the case as partner in a fraud
scheme with Neidorf.) In Atlanta, the Prophet had
already pled guilty to one charge of conspiracy, one
charge of wire fraud and one charge of interstate
transportation of stolen property. The wire fraud charge,
and the stolen property charge, were both directly based
on the E911 Document.
The twenty-year-old Prophet proved a sorry
customer, answering questions politely but in a barely
audible mumble, his voice trailing off at the ends of
sentences. He was constantly urged to speak up.
Cook, examining Prophet, forced him to admit that
he had once had a "drug problem," abusing
amphetamines, marijuana, cocaine, and LSD. This may
have established to the jury that "hackers" are, or can be,
seedy lowlife characters, but it may have damaged
Prophet's credibility somewhat. Zenner later suggested
that drugs might have damaged Prophet's memory. The
interesting fact also surfaced that Prophet had never
physically met Craig Neidorf. He didn't even know
Neidorf's last name -- at least, not until the trial.
Prophet confirmed the basic facts of his hacker
career. He was a member of the Legion of Doom. He had
abused codes, he had broken into switching stations and
re-routed calls, he had hung out on pirate bulletin boards.
He had raided the BellSouth AIMSX computer, copied
the E911 Document, stored it on Jolnet, mailed it to
Neidorf. He and Neidorf had edited it, and Neidorf had
known where it came from.
Zenner, however, had Prophet confirm that Neidorf
was not a member of the Legion of Doom, and had not
urged Prophet to break into BellSouth computers.
Neidorf had never urged Prophet to defraud anyone, or to
steal anything. Prophet also admitted that he had never
known Neidorf to break in to any computer. Prophet said
that no one in the Legion of Doom considered Craig
Neidorf a "hacker" at all. Neidorf was not a UNIX maven,
and simply lacked the necessary skill and ability to break
into computers. Neidorf just published a magazine.
On Friday, July 27, 1990, the case against Neidorf
collapsed. Cook moved to dismiss the indictment, citing
"information currently available to us that was not
available to us at the inception of the trial." Judge Bua
praised the prosecution for this action, which he described
as "very responsible," then dismissed a juror and declared
a mistrial.
Neidorf was a free man. His defense, however, had
cost himself and his family dearly. Months of his life had
been consumed in anguish; he had seen his closest
friends shun him as a federal criminal. He owed his
lawyers over a hundred thousand dollars, despite a
generous payment to the defense by Mitch Kapor.
Neidorf was not found innocent. The trial was simply
dropped. Nevertheless, on September 9, 1991, Judge Bua
granted Neidorf's motion for the "expungement and
sealing" of his indictment record. The United States
Secret Service was ordered to delete and destroy all
fingerprints, photographs, and other records of arrest or
processing relating to Neidorf's indictment, including
their paper documents and their computer records.
Neidorf went back to school, blazingly determined to
become a lawyer. Having seen the justice system at work,
Neidorf lost much of his enthusiasm for merely technical
power. At this writing, Craig Neidorf is working in
Washington as a salaried researcher for the American
Civil Liberties Union.
#
The outcome of the Neidorf trial changed the EFF
from voices-in-the-wilderness to the media darlings of the
new frontier.
Legally speaking, the Neidorf case was not a
sweeping triumph for anyone concerned. No
constitutional principles had been established. The issues
of "freedom of the press" for electronic publishers
remained in legal limbo. There were public
misconceptions about the case. Many people thought
Neidorf had been found innocent and relieved of all his
legal debts by Kapor. The truth was that the government
had simply dropped the case, and Neidorf's family had
gone deeply into hock to support him.
But the Neidorf case did provide a single,
devastating, public sound-bite: *The feds said it was worth
eighty grand, and it was only worth thirteen bucks.*
This is the Neidorf case's single most memorable
element. No serious report of the case missed this
particular element. Even cops could not read this without
a wince and a shake of the head. It left the public
credibility of the crackdown agents in tatters.
The crackdown, in fact, continued, however. Those
two charges against Prophet, which had been based on the
E911 Document, were quietly forgotten at his sentencing --
even though Prophet had already pled guilty to them.
Georgia federal prosecutors strongly argued for jail time
for the Atlanta Three, insisting on "the need to send a
message to the community," "the message that hackers
around the country need to hear."
There was a great deal in their sentencing
memorandum about the awful things that various other
hackers had done (though the Atlanta Three themselves
had not, in fact, actually committed these crimes). There
was also much speculation about the awful things that the
Atlanta Three *might* have done and *were capable* of
doing (even though they had not, in fact, actually done
them). The prosecution's argument carried the day. The
Atlanta Three were sent to prison: Urvile and Leftist both
got 14 months each, while Prophet (a second offender) got
21 months.
The Atlanta Three were also assessed staggering
fines as "restitution": $233,000 each. BellSouth claimed
that the defendants had "stolen" "approximately $233,880
worth" of "proprietary computer access information" --
specifically, $233,880 worth of computer passwords and
connect addresses. BellSouth's astonishing claim of the
extreme value of its own computer passwords and
addresses was accepted at face value by the Georgia
court. Furthermore (as if to emphasize its theoretical
nature) this enormous sum was not divvied up among the
Atlanta Three, but each of them had to pay all of it.
A striking aspect of the sentence was that the Atlanta
Three were specifically forbidden to use computers,
except for work or under supervision. Depriving hackers
of home computers and modems makes some sense if
one considers hackers as "computer addicts," but EFF,
filing an amicus brief in the case, protested that this
punishment was unconstitutional -- it deprived the
Atlanta Three of their rights of free association and free
expression through electronic media.
Terminus, the "ultimate hacker," was finally sent to
prison for a year through the dogged efforts of the Chicago
Task Force. His crime, to which he pled guilty, was the
transfer of the UNIX password trapper, which was
officially valued by AT&T at $77,000, a figure which
aroused intense skepticism among those familiar with
UNIX "login.c" programs.
The jailing of Terminus and the Atlanta Legionnaires
of Doom, however, did not cause the EFF any sense of
embarrassment or defeat. On the contrary, the civil
libertarians were rapidly gathering strength.
An early and potent supporter was Senator Patrick
Leahy, Democrat from Vermont, who had been a Senate
sponsor of the Electronic Communications Privacy Act.
Even before the Neidorf trial, Leahy had spoken out in
defense of hacker-power and freedom of the keyboard:
"We cannot unduly inhibit the inquisitive 13-year-old who,
if left to experiment today, may tomorrow develop the
telecommunications or computer technology to lead the
United States into the 21st century. He represents our
future and our best hope to remain a technologically
competitive nation."
It was a handsome statement, rendered perhaps
rather more effective by the fact that the crackdown
raiders *did not have* any Senators speaking out for
*them.* On the contrary, their highly secretive actions
and tactics, all "sealed search warrants" here and
"confidential ongoing investigations" there, might have
won them a burst of glamorous publicity at first, but were
crippling them in the on-going propaganda war. Gail
Thackeray was reduced to unsupported bluster: "Some of
these people who are loudest on the bandwagon may just
slink into the background," she predicted in *Newsweek* -
- when all the facts came out, and the cops were
vindicated.
But all the facts did not come out. Those facts that
did, were not very flattering. And the cops were not
vindicated. And Gail Thackeray lost her job. By the end of
1991, William Cook had also left public employment.
1990 had belonged to the crackdown, but by '91 its
agents were in severe disarray, and the libertarians were
on a roll. People were flocking to the cause.
A particularly interesting ally had been Mike Godwin
of Austin, Texas. Godwin was an individual almost as
difficult to describe as Barlow; he had been editor of the
student newspaper of the University of Texas, and a
computer salesman, and a programmer, and in 1990 was
back in law school, looking for a law degree.
Godwin was also a bulletin board maven. He was
very well-known in the Austin board community under his
handle "Johnny Mnemonic," which he adopted from a
cyberpunk science fiction story by William Gibson.
Godwin was an ardent cyberpunk science fiction fan. As a
fellow Austinite of similar age and similar interests, I
myself had known Godwin socially for many years. When
William Gibson and myself had been writing our
collaborative SF novel, *The Difference Engine,* Godwin
had been our technical advisor in our effort to link our
Apple word-processors from Austin to Vancouver. Gibson
and I were so pleased by his generous expert help that we
named a character in the novel "Michael Godwin" in his
honor.
The handle "Mnemonic" suited Godwin very well.
His erudition and his mastery of trivia were impressive to
the point of stupor; his ardent curiosity seemed insatiable,
and his desire to debate and argue seemed the central
drive of his life. Godwin had even started his own Austin
debating society, wryly known as the "Dull Men's Club."
In person, Godwin could be overwhelming; a flypaper-
brained polymath who could not seem to let any idea go.
On bulletin boards, however, Godwin's closely reasoned,
highly grammatical, erudite posts suited the medium well,
and he became a local board celebrity.
Mike Godwin was the man most responsible for the
public national exposure of the Steve Jackson case. The
Izenberg seizure in Austin had received no press coverage
at all. The March 1 raids on Mentor, Bloodaxe, and Steve
Jackson Games had received a brief front-page splash in
the front page of the *Austin American-Statesman,* but it
was confused and ill-informed: the warrants were sealed,
and the Secret Service wasn't talking. Steve Jackson
seemed doomed to obscurity. Jackson had not been
arrested; he was not charged with any crime; he was not on
trial. He had lost some computers in an ongoing
investigation -- so what? Jackson tried hard to attract
attention to the true extent of his plight, but he was
drawing a blank; no one in a position to help him seemed
able to get a mental grip on the issues.
Godwin, however, was uniquely, almost magically,
qualified to carry Jackson's case to the outside world.
Godwin was a board enthusiast, a science fiction fan, a
former journalist, a computer salesman, a lawyer-to-be,
and an Austinite. Through a coincidence yet more
Due to the critical nature of E911 service, the control and
timely repair of troubles is demanded. As the primary
E911 customer contact, the SSC/MAC is in the unique
position to monitor the status of the trouble and insure its
resolution.
System Overview
~~~~~~~~~~~~~~~
The number 911 is intended as a nationwide universal
telephone number which provides the public with direct
access to a Public Safety Answering Point (PSAP). A PSAP
is also referred to as an Emergency Service Bureau (ESB).
A PSAP is an agency or facility which is authorized by a
municipality to receive and respond to police, fire and/or
ambulance services. One or more attendants are located
at the PSAP facilities to receive and handle calls of an
emergency nature in accordance with the local municipal
requirements.
An important advantage of E911 emergency service is
improved (reduced) response times for emergency
services. Also close coordination among agencies
providing various emergency services is a valuable
capability provided by E911 service.
1A ESS is used as the tandem office for the E911 network to
route all 911 calls to the correct (primary) PSAP designated
to serve the calling station. The E911 feature was
developed primarily to provide routing to the correct PSAP
for all 911 calls. Selective routing allows a 911 call
originated from a particular station located in a particular
district, zone, or town, to be routed to the primary PSAP
designated to serve that customer station regardless of
wire center boundaries. Thus, selective routing eliminates
the problem of wire center boundaries not coinciding with
district or other political boundaries.
The services available with the E911 feature include:
Forced Disconnect Default Routing
Alternative Routing Night Service
Selective Routing Automatic Number
Identification (ANI)
Selective Transfer Automatic Location
Identification (ALI)
Preservice/Installation Guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a contract for an E911 system has been signed, it is
the responsibility of Network Marketing to establish an
implementation/cutover committee which should include
a representative from the SSC/MAC. Duties of the E911
Implementation Team include coordination of all phases
of the E911 system deployment and the formation of an
on-going E911 maintenance subcommittee.
Marketing is responsible for providing the following
customer specific information to the SSC/MAC prior to
the start of call through testing:
o All PSAP's (name, address, local contact)
o All PSAP circuit ID's
o 1004 911 service request including PSAP details on each
PSAP
(1004 Section K, L, M)
o Network configuration
o Any vendor information (name, telephone number,
equipment)
The SSC/MAC needs to know if the equipment and sets at
the PSAP are maintained by the BOCs, an independent
company, or an outside vendor, or any combination. This
information is then entered on the PSAP profile sheets
and reviewed quarterly for changes, additions and
deletions.
Marketing will secure the Major Account Number (MAN)
and provide this number to Corporate Communications
so that the initial issue of the service orders carry the
MAN and can be tracked by the SSC/MAC via
CORDNET. PSAP circuits are official services by
definition.
All service orders required for the installation of the E911
system should include the MAN assigned to the
city/county which has purchased the system.
In accordance with the basic SSC/MAC strategy for
provisioning, the SSC/MAC will be Overall Control Office
(OCO) for all Node to PSAP circuits (official services) and
any other services for this customer. Training must be
scheduled for all SSC/MAC involved personnel during the
pre-service stage of the project.
The E911 Implementation Team will form the on-going
maintenance subcommittee prior to the initial
implementation of the E911 system. This sub-committee
will establish post implementation quality assurance
procedures to ensure that the E911 system continues to
provide quality service to the customer.
Customer/Company training, trouble reporting interfaces
for the customer, telephone company and any involved
independent telephone companies needs to be addressed
and implemented prior to E911 cutover. These functions
can be best addressed by the formation of a sub-
committee of the E911 Implementation Team to set up
guidelines for and to secure service commitments of
interfacing organizations. A SSC/MAC supervisor should
chair this subcommittee and include the following
organizations:
1) Switching Control Center
- E911 translations
- Trunking
- End office and Tandem office hardware/software
2) Recent Change Memory Administration Center
- Daily RC update activity for TN/ESN translations
- Processes validity errors and rejects
3) Line and Number Administration
- Verification of TN/ESN translations
4) Special Service Center/Major Account Center
- Single point of contact for all PSAP and Node to
host
troubles
- Logs, tracks & statusing of all trouble reports
- Trouble referral, follow up, and escalation
- Customer notification of status and restoration
- Analyzation of "chronic" troubles
- Testing, installation and maintenance of E911
circuits
5) Installation and Maintenance (SSIM/I&M)
- Repair and maintenance of PSAP equipment and
Telco owned sets
6) Minicomputer Maintenance Operations Center
- E911 circuit maintenance (where applicable)
7) Area Maintenance Engineer
- Technical assistance on voice (CO-PSAP) network
related E911 troubles
Maintenance Guidelines
~~~~~~~~~~~~~~~~~~~~~~
The CCNC will test the Node circuit from the 202T at the
Host site to the 202T at the Node site. Since Host to Node
(CCNC to MMOC) circuits are official company services,
the CCNC will refer all Node circuit troubles to the
SSC/MAC. The SSC/MAC is responsible for the testing
and follow up to restoration of these circuit troubles.
Although Node to PSAP circuit are official services, the
MMOC will refer PSAP circuit troubles to the appropriate
SSC/MAC. The SSC/MAC is responsible for testing and
follow up to restoration of PSAP circuit troubles.
The SSC/MAC will also receive reports from
CRSAB/IMC(s) on subscriber 911 troubles when they are
not line troubles. The SSC/MAC is responsible for testing
and restoration of these troubles.
Maintenance responsibilities are as follows:
SCC* Voice Network (ANI to PSAP)
*SCC responsible for tandem switch
SSIM/I&M PSAP Equipment (Modems, CIU's, sets)
Vendor PSAP Equipment (when CPE)
SSC/MAC PSAP to Node circuits, and tandem to
PSAP voice circuits (EMNT)
MMOC Node site (Modems, cables, etc)
Note: All above work groups are required to resolve
troubles by interfacing with appropriate work groups for
resolution.
The Switching Control Center (SCC) is responsible for
E911/1AESS translations in tandem central offices. These
translations route E911 calls, selective transfer, default
routing, speed calling, etc., for each PSAP. The SCC is
also
responsible for troubleshooting on the voice network (call
originating to end office tandem equipment).
For example, ANI failures in the originating offices would
be a responsibility of the SCC.
Recent Change Memory Administration Center
(RCMAC) performs the daily tandem translation updates
(recent change) for routing of individual telephone
numbers.
Recent changes are generated from service order activity
(new service, address changes, etc.) and compiled into a
daily file by the E911 Center (ALI/DMS E911 Computer).
SSIM/I&M is responsible for the installation and repair of
PSAP equipment. PSAP equipment includes ANI
Controller, ALI Controller, data sets, cables, sets, and
other peripheral equipment that is not vendor owned.
SSIM/I&M is responsible for establishing maintenance
test kits, complete with spare parts for PSAP maintenance.
This includes test gear, data sets, and ANI/ALI Controller
parts.
Special Services Center (SSC) or Major Account Center
(MAC) serves as the trouble reporting contact for all
(PSAP) troubles reported by customer. The SSC/MAC
refers troubles to proper organizations for handling and
tracks status of troubles, escalating when necessary. The
SSC/MAC will close out troubles with customer. The
SSC/MAC will analyze all troubles and tracks "chronic"
PSAP troubles.
Corporate Communications Network Center (CCNC) will
test and refer troubles on all node to host circuits. All
E911
circuits are classified as official company property.
The Minicomputer Maintenance Operations Center
(MMOC) maintains the E911 (ALI/DMS) computer
hardware at the Host site. This MMOC is also responsible
for monitoring the system and reporting certain PSAP and
system problems to the local MMOC's, SCC's or
SSC/MAC's. The MMOC personnel also operate software
programs that maintain the TN data base under the
direction of the E911 Center. The maintenance of the
NODE computer (the interface between the PSAP and the
ALI/DMS computer) is a function of the MMOC at the
NODE site. The MMOC's at the NODE sites may also be
involved in the testing of NODE to Host circuits. The
MMOC will also assist on Host to PSAP and data network
related troubles not resolved through standard trouble
clearing procedures.
Installation And Maintenance Center (IMC) is
responsible for referral of E911 subscriber troubles that
are not subscriber line problems.
E911 Center - Performs the role of System Administration
and is responsible for overall operation of the E911
computer software. The E911 Center does A-Z trouble
analysis and provides statistical information on the
performance of the system.
This analysis includes processing PSAP inquiries (trouble
reports) and referral of network troubles. The E911 Center
also performs daily processing of tandem recent change
and provides information to the RCMAC for tandem
input. The E911 Center is responsible for daily processing
of the ALI/DMS computer data base and provides error
files, etc. to the Customer Services department for
investigation and correction. The E911 Center participates
in all system implementations and on-going maintenance
effort and assists in the development of procedures,
training and education of information to all groups.
Any group receiving a 911 trouble from the SSC/MAC
should close out the trouble with the SSC/MAC or provide
a status if the trouble has been referred to another group.
This will allow the SSC/MAC to provide a status back to
the customer or escalate as appropriate.
Any group receiving a trouble from the Host site (MMOC
or CCNC) should close the trouble back to that group.
The MMOC should notify the appropriate SSC/MAC
when the Host, Node, or all Node circuits are down so that
the SSC/MAC can reply to customer reports that may be
called in by the PSAPs. This will eliminate duplicate
reporting of troubles. On complete outages the MMOC
will follow escalation procedures for a Node after two (2)
hours and for a PSAP after four (4) hours. Additionally the
MMOC will notify the appropriate SSC/MAC when the
Host, Node, or all Node circuits are down.
The PSAP will call the SSC/MAC to report E911 troubles.
The person reporting the E911 trouble may not have a
circuit I.D. and will therefore report the PSAP name and
address. Many PSAP troubles are not circuit specific. In
those instances where the caller cannot provide a circuit
I.D., the SSC/MAC will be required to determine the
circuit I.D. using the PSAP profile. Under no
circumstances will the SSC/MAC Center refuse to take
the trouble. The E911 trouble should be handled as
quickly as possible, with the SSC/MAC providing as much
assistance as possible while taking the trouble report from
the caller.
The SSC/MAC will screen/test the trouble to determine
the appropriate handoff organization based on the
following criteria:
PSAP equipment problem: SSIM/I&M
Circuit problem: SSC/MAC
Voice network problem: SCC (report trunk group
number)
Problem affecting multiple PSAPs (No ALI report from
all PSAPs): Contact the MMOC to check for NODE or
Host computer problems before further testing.
The SSC/MAC will track the status of reported troubles
and escalate as appropriate. The SSC/MAC will close out
customer/company reports with the initiating contact.
Groups with specific maintenance responsibilities,
defined above, will investigate "chronic" troubles upon
request from the SSC/MAC and the ongoing maintenance
subcommittee.
All "out of service" E911 troubles are priority one type
reports. One link down to a PSAP is considered a priority
one trouble and should be handled as if the PSAP was
isolated.
The PSAP will report troubles with the ANI controller, ALI
controller or set equipment to the SSC/MAC.
NO ANI: Where the PSAP reports NO ANI (digital
display screen is blank) ask if this condition exists on all
screens and on all calls. It is important to differentiate
between blank screens and screens displaying 911-00XX,
or all zeroes.
When the PSAP reports all screens on all calls, ask if there
is any voice contact with callers. If there is no voice
contact the trouble should be referred to the SCC
immediately since 911 calls are not getting through which
may require alternate routing of calls to another PSAP.
When the PSAP reports this condition on all screens but
not all calls and has voice contact with callers, the report
should be referred to SSIM/I&M for dispatch. The
SSC/MAC should verify with the SCC that ANI is pulsing
before dispatching SSIM.
When the PSAP reports this condition on one screen for
all calls (others work fine) the trouble should be referred
to
SSIM/I&M for dispatch, because the trouble is isolated to
one piece of equipment at the customer premise.
An ANI failure (i.e. all zeroes) indicates that the ANI has
not been received by the PSAP from the tandem office or
was lost by the PSAP ANI controller. The PSAP may
receive "02" alarms which can be caused by the ANI
controller logging more than three all zero failures on the
same trunk. The PSAP has been instructed to report this
condition to the SSC/MAC since it could indicate an
equipment trouble at the PSAP which might be affecting
all subscribers calling into the PSAP. When all zeroes are
being received on all calls or "02" alarms continue, a
tester
should analyze the condition to determine the appropriate
action to be taken. The tester must perform cooperative
testing with the SCC when there appears to be a problem
on the Tandem-PSAP trunks before requesting dispatch.
When an occasional all zero condition is reported, the
SSC/MAC should dispatch SSIM/I&M to routine
equipment on a "chronic" troublesweep.
The PSAPs are instructed to report incidental ANI failures
to the BOC on a PSAP inquiry trouble ticket (paper) that is
sent to the Customer Services E911 group and forwarded
to E911 center when required. This usually involves only a
particular telephone number and is not a condition that
would require a report to the SSC/MAC. Multiple ANI
failures which our from the same end office (XX denotes
end office), indicate a hard trouble condition may exist in
the end office or end office tandem trunks. The PSAP will
report this type of condition to the SSC/MAC and the
SSC/MAC should refer the report to the SCC responsible
for the tandem office. NOTE: XX is the ESCO (Emergency
Service Number) associated with the incoming 911 trunks
into the tandem. It is important that the C/MAC tell the
SCC what is displayed at the PSAP (i.e. 911-0011) which
indicates to the SCC which end office is in trouble.
Note: It is essential that the PSAP fill out inquiry form
on
every ANI failure.
The PSAP will report a trouble any time an address is not
received on an address display (screen blank) E911 call.
(If a record is not in the 911 data base or an ANI failure
is
encountered, the screen will provide a display noticing
such condition). The SSC/MAC should verify with the
PSAP whether the NO ALI condition is on one screen or all
screens.
When the condition is on one screen (other screens
receive ALI information) the SSC/MAC will request
SSIM/I&M to dispatch.
If no screens are receiving ALI information, there is
usually a circuit trouble between the PSAP and the Host
computer. The SSC/MAC should test the trouble and
refer for restoral.
Note: If the SSC/MAC receives calls from multiple
PSAP's, all of which are receiving NO ALI, there is a
problem with the Node or Node to Host circuits or the
Host computer itself. Before referring the trouble the
SSC/MAC should call the MMOC to inquire if the Node
or Host is in trouble.
Alarm conditions on the ANI controller digital display at
the PSAP are to be reported by the PSAP's. These alarms
can indicate various trouble conditions so the SSC/MAC
should ask the PSAP if any portion of the E911 system is
not functioning properly.
The SSC/MAC should verify with the PSAP attendant that
the equipment's primary function is answering E911 calls.
If it is, the SSC/MAC should request a dispatch
SSIM/I&M. If the equipment is not primarily used for
E911, then the SSC/MAC should advise PSAP to contact
their CPE vendor.
Note: These troubles can be quite confusing when the
PSAP has vendor equipment mixed in with equipment
that the BOC maintains. The Marketing representative
should provide the SSC/MAC information concerning any
unusual or exception items where the PSAP should
contact their vendor. This information should be included
in the PSAP profile sheets.
ANI or ALI controller down: When the host computer
sees the PSAP equipment down and it does not come back
up, the MMOC will report the trouble to the SSC/MAC;
the equipment is down at the PSAP, a dispatch will be
required.
PSAP link (circuit) down: The MMOC will provide the
SSC/MAC with the circuit ID that the Host computer
indicates in trouble. Although each PSAP has two circuits,
when either circuit is down the condition must be treated
as an emergency since failure of the second circuit will
cause the PSAP to be isolated.
Any problems that the MMOC identifies from the Node
location to the Host computer will be handled directly with
the appropriate MMOC(s)/CCNC.
Note: The customer will call only when a problem is
apparent to the PSAP. When only one circuit is down to
the PSAP, the customer may not be aware there is a
trouble, even though there is one link down, notification
should appear on the PSAP screen. Troubles called into
the SSC/MAC from the MMOC or other company
employee should not be closed out by calling the PSAP
since it may result in the customer responding that they
do not have a trouble. These reports can only be closed
out by receiving information that the trouble was fixed
and by checking with the company employee that
reported the trouble. The MMOC personnel will be able
to verify that the trouble has cleared by reviewing a
printout from the host.
When the CRSAB receives a subscriber complaint (i.e.,
cannot dial 911) the RSA should obtain as much
information as possible while the customer is on the line.
For example, what happened when the subscriber dialed
911? The report is automatically directed to the IMC for
subscriber line testing. When no line trouble is found, the
IMC will refer the trouble condition to the SSC/MAC. The
SSC/MAC will contact Customer Services E911 Group and
verify that the subscriber should be able to call 911 and
obtain the ESN. The SSC/MAC will verify the ESN via
2SCCS. When both verifications match, the SSC/MAC
will refer the report to the SCC responsible for the 911
tandem office for investigation and resolution. The MAC
is responsible for tracking the trouble and informing the
IMC when it is resolved.
For more information, please refer to E911 Glossary of
Terms.
End of Phrack File
_____________________________________
The reader is forgiven if he or she was entirely unable
to read this document. John Perry Barlow had a great
deal of fun at its expense, in "Crime and Puzzlement:"
"Bureaucrat-ese of surpassing opacity.... To read the whole
thing straight through without entering coma requires
either a machine or a human who has too much practice
thinking like one. Anyone who can understand it fully and
fluidly had altered his consciousness beyone the ability to
ever again read Blake, Whitman, or Tolstoy.... the
document contains little of interest to anyone who is not a
student of advanced organizational sclerosis."
With the Document itself to hand, however, exactly
as it was published (in its six-page edited form) in
*Phrack,* the reader may be able to verify a few
statements of fact about its nature. First, there is no
software, no computer code, in the Document. It is not
computer-programming language like FORTRAN or C++,
it is English; all the sentences have nouns and verbs and
punctuation. It does not explain how to break into the
E911 system. It does not suggest ways to destroy or
damage the E911 system.
There are no access codes in the Document. There
are no computer passwords. It does not explain how to
steal long distance service. It does not explain how to
break in to telco switching stations. There is nothing in
it
about using a personal computer or a modem for any
purpose at all, good or bad.
Close study will reveal that this document is not
about machinery. The E911 Document is about
*administration.* It describes how one creates and
administers certain units of telco bureaucracy: Special
Service Centers and Major Account Centers (SSC/MAC).
It describes how these centers should distribute
responsibility for the E911 service, to other units of telco
bureaucracy, in a chain of command, a formal hierarchy.
It describes who answers customer complaints, who
screens calls, who reports equipment failures, who answers
those reports, who handles maintenance, who chairs
subcommittees, who gives orders, who follows orders,
*who* tells *whom* what to do. The Document is not a
"roadmap" to computers. The Document is a roadmap to
*people.*
As an aid to breaking into computer systems, the
Document is *useless.* As an aid to harassing and
deceiving telco people, however, the Document might
prove handy (especially with its Glossary, which I have not
included). An intense and protracted study of this
Document and its Glossary, combined with many other
such documents, might teach one to speak like a telco
employee. And telco people live by *speech* -- they live
by phone communication. If you can mimic their
language over the phone, you can "social-engineer" them.
If you can con telco people, you can wreak havoc among
them. You can force them to no longer trust one another;
you can break the telephonic ties that bind their
community; you can make them paranoid. And people
will fight harder to defend their community than they will
fight to defend their individual selves.
This was the genuine, gut-level threat posed by
*Phrack* magazine. The real struggle was over the control
of telco language, the control of telco knowledge. It was a
struggle to defend the social "membrane of
differentiation" that forms the walls of the telco
community's ivory tower -- the special jargon that allows
telco professionals to recognize one another, and to
exclude charlatans, thieves, and upstarts. And the
prosecution brought out this fact. They repeatedly made
reference to the threat posed to telco professionals by
hackers using "social engineering."
However, Craig Neidorf was not on trial for learning
to speak like a professional telecommunications expert.
Craig Neidorf was on trial for access device fraud and
transportation of stolen property. He was on trial for
stealing a document that was purportedly highly sensitive
and purportedly worth tens of thousands of dollars.
#
John Nagle read the E911 Document. He drew his
own conclusions. And he presented Zenner and his
defense team with an overflowing box of similar material,
drawn mostly from Stanford University's engineering
libraries. During the trial, the defense team -- Zenner,
half-a-dozen other attorneys, Nagle, Neidorf, and
computer-security expert Dorothy Denning, all pored
over the E911 Document line-by-line.
On the afternoon of July 25, 1990, Zenner began to
cross-examine a woman named Billie Williams, a service
manager for Southern Bell in Atlanta. Ms. Williams had
been responsible for the E911 Document. (She was not its
author -- its original "author" was a Southern Bell staff
manager named Richard Helms. However, Mr. Helms
should not bear the entire blame; many telco staff people
and maintenance personnel had amended the
Document. It had not been so much "written" by a single
author, as built by committee out of concrete-blocks of
jargon.)
Ms. Williams had been called as a witness for the
prosecution, and had gamely tried to explain the basic
technical structure of the E911 system, aided by charts.
Now it was Zenner's turn. He first established that
the "proprietary stamp" that BellSouth had used on the
E911 Document was stamped on *every single document*
that BellSouth wrote -- *thousands* of documents. "We
do not publish anything other than for our own company,"
Ms. Williams explained. "Any company document of this
nature is considered proprietary." Nobody was in charge
of singling out special high-security publications for
special high-security protection. They were *all* special,
no matter how trivial, no matter what their subject matter -
- the stamp was put on as soon as any document was
written, and the stamp was never removed.
Zenner now asked whether the charts she had been
using to explain the mechanics of E911 system were
"proprietary," too. Were they *public information,* these
charts, all about PSAPs, ALIs, nodes, local end switches?
Could he take the charts out in the street and show them
to anybody, "without violating some proprietary notion
that BellSouth has?"
Ms Williams showed some confusion, but finally
agreed that the charts were, in fact, public.
"But isn't this what you said was basically what
appeared in *Phrack?*"
Ms. Williams denied this.
Zenner now pointed out that the E911 Document as
published in Phrack was only half the size of the original
E911 Document (as Prophet had purloined it). Half of it
had been deleted -- edited by Neidorf.
Ms. Williams countered that "Most of the
information that is in the text file is redundant."
Zenner continued to probe. Exactly what bits of
knowledge in the Document were, in fact, unknown to the
public? Locations of E911 computers? Phone numbers for
telco personnel? Ongoing maintenance subcommittees?
Hadn't Neidorf removed much of this?
Then he pounced. "Are you familiar with Bellcore
Technical Reference Document TR-TSY-000350?" It was,
Zenner explained, officially titled "E911 Public Safety
Answering Point Interface Between 1-1AESS Switch and
Customer Premises Equipment." It contained highly
detailed and specific technical information about the E911
System. It was published by Bellcore and publicly
available for about $20.
He showed the witness a Bellcore catalog which listed
thousands of documents from Bellcore and from all the
Baby Bells, BellSouth included. The catalog, Zenner
pointed out, was free. Anyone with a credit card could call
the Bellcore toll-free 800 number and simply order any of
these documents, which would be shipped to any
customer without question. Including, for instance,
"BellSouth E911 Service Interfaces to Customer Premises
Equipment at a Public Safety Answering Point."
Zenner gave the witness a copy of "BellSouth E911
Service Interfaces," which cost, as he pointed out, $13,
straight from the catalog. "Look at it carefully," he urged
Ms. Williams, "and tell me if it doesn't contain about twice
as much detailed information about the E911 system of
BellSouth than appeared anywhere in *Phrack.*"
"You want me to...." Ms. Williams trailed off. "I
don't
understand."
"Take a careful look," Zenner persisted. "Take a look
at that document, and tell me when you're done looking at
it if, indeed, it doesn't contain much more detailed
information about the E911 system than appeared in
*Phrack.*"
"*Phrack* wasn't taken from this," Ms. Williams said.
"Excuse me?" said Zenner.
"*Phrack* wasn't taken from this."
"I can't hear you," Zenner said.
"*Phrack* was not taken from this document. I don't
understand your question to me."
"I guess you don't," Zenner said.
At this point, the prosecution's case had been
gutshot. Ms. Williams was distressed. Her confusion was
quite genuine. *Phrack* had not been taken from any
publicly available Bellcore document. *Phrack*'s E911
Document had been stolen from her own company's
computers, from her own company's text files, that her
own colleagues had written, and revised, with much labor.
But the "value" of the Document had been blown to
smithereens. It wasn't worth eighty grand. According to
Bellcore it was worth thirteen bucks. And the looming
menace that it supposedly posed had been reduced in
instants to a scarecrow. Bellcore itself was selling
material
far more detailed and "dangerous," to anybody with a
credit card and a phone.
Actually, Bellcore was not giving this information to
just anybody. They gave it to *anybody who asked,* but
not many did ask. Not many people knew that Bellcore
had a free catalog and an 800 number. John Nagle knew,
but certainly the average teenage phreak didn't know.
"Tuc," a friend of Neidorf's and sometime *Phrack*
contributor, knew, and Tuc had been very helpful to the
defense, behind the scenes. But the Legion of Doom
didn't know -- otherwise, they would never have wasted so
much time raiding dumpsters. Cook didn't know. Foley
didn't know. Kluepfel didn't know. The right hand of
Bellcore knew not what the left hand was doing. The right
hand was battering hackers without mercy, while the left
hand was distributing Bellcore's intellectual property to
anybody who was interested in telephone technical trivia --
apparently, a pathetic few.
The digital underground was so amateurish and
poorly organized that they had never discovered this heap
of unguarded riches. The ivory tower of the telcos was so
wrapped-up in the fog of its own technical obscurity that it
had left all the windows open and flung open the doors.
No one had even noticed.
Zenner sank another nail in the coffin. He produced
a printed issue of *Telephone Engineer & Management,*
a prominent industry journal that comes out twice a
month and costs $27 a year. This particular issue of
*TE&M,* called "Update on 911," featured a galaxy of
technical details on 911 service and a glossary far more
extensive than *Phrack*'s.
The trial rumbled on, somehow, through its own
momentum. Tim Foley testified about his interrogations
of Neidorf. Neidorf's written admission that he had known
the E911 Document was pilfered was officially read into
the court record.
An interesting side issue came up: "Terminus" had
once passed Neidorf a piece of UNIX AT&T software, a
log-in sequence, that had been cunningly altered so that it
could trap passwords. The UNIX software itself was
illegally copied AT&T property, and the alterations
"Terminus" had made to it, had transformed it into a
device for facilitating computer break-ins. Terminus
himself would eventually plead guilty to theft of this piece
of software, and the Chicago group would send Terminus
to prison for it. But it was of dubious relevance in the
Neidorf case. Neidorf hadn't written the program. He
wasn't accused of ever having used it. And Neidorf wasn't
being charged with software theft or owning a password
trapper.
On the next day, Zenner took the offensive. The civil
libertarians now had their own arcane, untried legal
weaponry to launch into action -- the Electronic
Communications Privacy Act of 1986, 18 US Code, Section
2701 et seq. Section 2701 makes it a crime to
intentionally
access without authorization a facility in which an
electronic communication service is provided -- it is, at
heart, an anti-bugging and anti-tapping law, intended to
carry the traditional protections of telephones into other
electronic channels of communication. While providing
penalties for amateur snoops, however, Section 2703 of the
ECPA also lays some formal difficulties on the bugging
and tapping activities of police.
The Secret Service, in the person of Tim Foley, had
served Richard Andrews with a federal grand jury
subpoena, in their pursuit of Prophet, the E911 Document,
and the Terminus software ring. But according to the
Electronic Communications Privacy Act, a "provider of
remote computing service" was legally entitled to "prior
notice" from the government if a subpoena was used.
Richard Andrews and his basement UNIX node, Jolnet,
had not received any "prior notice." Tim Foley had
purportedly violated the ECPA and committed an
electronic crime! Zenner now sought the judge's
permission to cross-examine Foley on the topic of Foley's
own electronic misdeeds.
Cook argued that Richard Andrews' Jolnet was a
privately owned bulletin board, and not within the purview
of ECPA. Judge Bua granted the motion of the
government to prevent cross-examination on that point,
and Zenner's offensive fizzled. This, however, was the
first
direct assault on the legality of the actions of the
Computer Fraud and Abuse Task Force itself -- the first
suggestion that they themselves had broken the law, and
might, perhaps, be called to account.
Zenner, in any case, did not really need the ECPA.
Instead, he grilled Foley on the glaring contradictions in
the supposed value of the E911 Document. He also
brought up the embarrassing fact that the supposedly red-
hot E911 Document had been sitting around for months,
in Jolnet, with Kluepfel's knowledge, while Kluepfel had
done nothing about it.
In the afternoon, the Prophet was brought in to testify
for the prosecution. (The Prophet, it will be recalled, had
also been indicted in the case as partner in a fraud
scheme with Neidorf.) In Atlanta, the Prophet had
already pled guilty to one charge of conspiracy, one
charge of wire fraud and one charge of interstate
transportation of stolen property. The wire fraud charge,
and the stolen property charge, were both directly based
on the E911 Document.
The twenty-year-old Prophet proved a sorry
customer, answering questions politely but in a barely
audible mumble, his voice trailing off at the ends of
sentences. He was constantly urged to speak up.
Cook, examining Prophet, forced him to admit that
he had once had a "drug problem," abusing
amphetamines, marijuana, cocaine, and LSD. This may
have established to the jury that "hackers" are, or can be,
seedy lowlife characters, but it may have damaged
Prophet's credibility somewhat. Zenner later suggested
that drugs might have damaged Prophet's memory. The
interesting fact also surfaced that Prophet had never
physically met Craig Neidorf. He didn't even know
Neidorf's last name -- at least, not until the trial.
Prophet confirmed the basic facts of his hacker
career. He was a member of the Legion of Doom. He had
abused codes, he had broken into switching stations and
re-routed calls, he had hung out on pirate bulletin boards.
He had raided the BellSouth AIMSX computer, copied
the E911 Document, stored it on Jolnet, mailed it to
Neidorf. He and Neidorf had edited it, and Neidorf had
known where it came from.
Zenner, however, had Prophet confirm that Neidorf
was not a member of the Legion of Doom, and had not
urged Prophet to break into BellSouth computers.
Neidorf had never urged Prophet to defraud anyone, or to
steal anything. Prophet also admitted that he had never
known Neidorf to break in to any computer. Prophet said
that no one in the Legion of Doom considered Craig
Neidorf a "hacker" at all. Neidorf was not a UNIX maven,
and simply lacked the necessary skill and ability to break
into computers. Neidorf just published a magazine.
On Friday, July 27, 1990, the case against Neidorf
collapsed. Cook moved to dismiss the indictment, citing
"information currently available to us that was not
available to us at the inception of the trial." Judge Bua
praised the prosecution for this action, which he described
as "very responsible," then dismissed a juror and declared
a mistrial.
Neidorf was a free man. His defense, however, had
cost himself and his family dearly. Months of his life had
been consumed in anguish; he had seen his closest
friends shun him as a federal criminal. He owed his
lawyers over a hundred thousand dollars, despite a
generous payment to the defense by Mitch Kapor.
Neidorf was not found innocent. The trial was simply
dropped. Nevertheless, on September 9, 1991, Judge Bua
granted Neidorf's motion for the "expungement and
sealing" of his indictment record. The United States
Secret Service was ordered to delete and destroy all
fingerprints, photographs, and other records of arrest or
processing relating to Neidorf's indictment, including
their paper documents and their computer records.
Neidorf went back to school, blazingly determined to
become a lawyer. Having seen the justice system at work,
Neidorf lost much of his enthusiasm for merely technical
power. At this writing, Craig Neidorf is working in
Washington as a salaried researcher for the American
Civil Liberties Union.
#
The outcome of the Neidorf trial changed the EFF
from voices-in-the-wilderness to the media darlings of the
new frontier.
Legally speaking, the Neidorf case was not a
sweeping triumph for anyone concerned. No
constitutional principles had been established. The issues
of "freedom of the press" for electronic publishers
remained in legal limbo. There were public
misconceptions about the case. Many people thought
Neidorf had been found innocent and relieved of all his
legal debts by Kapor. The truth was that the government
had simply dropped the case, and Neidorf's family had
gone deeply into hock to support him.
But the Neidorf case did provide a single,
devastating, public sound-bite: *The feds said it was worth
eighty grand, and it was only worth thirteen bucks.*
This is the Neidorf case's single most memorable
element. No serious report of the case missed this
particular element. Even cops could not read this without
a wince and a shake of the head. It left the public
credibility of the crackdown agents in tatters.
The crackdown, in fact, continued, however. Those
two charges against Prophet, which had been based on the
E911 Document, were quietly forgotten at his sentencing --
even though Prophet had already pled guilty to them.
Georgia federal prosecutors strongly argued for jail time
for the Atlanta Three, insisting on "the need to send a
message to the community," "the message that hackers
around the country need to hear."
There was a great deal in their sentencing
memorandum about the awful things that various other
hackers had done (though the Atlanta Three themselves
had not, in fact, actually committed these crimes). There
was also much speculation about the awful things that the
Atlanta Three *might* have done and *were capable* of
doing (even though they had not, in fact, actually done
them). The prosecution's argument carried the day. The
Atlanta Three were sent to prison: Urvile and Leftist both
got 14 months each, while Prophet (a second offender) got
21 months.
The Atlanta Three were also assessed staggering
fines as "restitution": $233,000 each. BellSouth claimed
that the defendants had "stolen" "approximately $233,880
worth" of "proprietary computer access information" --
specifically, $233,880 worth of computer passwords and
connect addresses. BellSouth's astonishing claim of the
extreme value of its own computer passwords and
addresses was accepted at face value by the Georgia
court. Furthermore (as if to emphasize its theoretical
nature) this enormous sum was not divvied up among the
Atlanta Three, but each of them had to pay all of it.
A striking aspect of the sentence was that the Atlanta
Three were specifically forbidden to use computers,
except for work or under supervision. Depriving hackers
of home computers and modems makes some sense if
one considers hackers as "computer addicts," but EFF,
filing an amicus brief in the case, protested that this
punishment was unconstitutional -- it deprived the
Atlanta Three of their rights of free association and free
expression through electronic media.
Terminus, the "ultimate hacker," was finally sent to
prison for a year through the dogged efforts of the Chicago
Task Force. His crime, to which he pled guilty, was the
transfer of the UNIX password trapper, which was
officially valued by AT&T at $77,000, a figure which
aroused intense skepticism among those familiar with
UNIX "login.c" programs.
The jailing of Terminus and the Atlanta Legionnaires
of Doom, however, did not cause the EFF any sense of
embarrassment or defeat. On the contrary, the civil
libertarians were rapidly gathering strength.
An early and potent supporter was Senator Patrick
Leahy, Democrat from Vermont, who had been a Senate
sponsor of the Electronic Communications Privacy Act.
Even before the Neidorf trial, Leahy had spoken out in
defense of hacker-power and freedom of the keyboard:
"We cannot unduly inhibit the inquisitive 13-year-old who,
if left to experiment today, may tomorrow develop the
telecommunications or computer technology to lead the
United States into the 21st century. He represents our
future and our best hope to remain a technologically
competitive nation."
It was a handsome statement, rendered perhaps
rather more effective by the fact that the crackdown
raiders *did not have* any Senators speaking out for
*them.* On the contrary, their highly secretive actions
and tactics, all "sealed search warrants" here and
"confidential ongoing investigations" there, might have
won them a burst of glamorous publicity at first, but were
crippling them in the on-going propaganda war. Gail
Thackeray was reduced to unsupported bluster: "Some of
these people who are loudest on the bandwagon may just
slink into the background," she predicted in *Newsweek* -
- when all the facts came out, and the cops were
vindicated.
But all the facts did not come out. Those facts that
did, were not very flattering. And the cops were not
vindicated. And Gail Thackeray lost her job. By the end of
1991, William Cook had also left public employment.
1990 had belonged to the crackdown, but by '91 its
agents were in severe disarray, and the libertarians were
on a roll. People were flocking to the cause.
A particularly interesting ally had been Mike Godwin
of Austin, Texas. Godwin was an individual almost as
difficult to describe as Barlow; he had been editor of the
student newspaper of the University of Texas, and a
computer salesman, and a programmer, and in 1990 was
back in law school, looking for a law degree.
Godwin was also a bulletin board maven. He was
very well-known in the Austin board community under his
handle "Johnny Mnemonic," which he adopted from a
cyberpunk science fiction story by William Gibson.
Godwin was an ardent cyberpunk science fiction fan. As a
fellow Austinite of similar age and similar interests, I
myself had known Godwin socially for many years. When
William Gibson and myself had been writing our
collaborative SF novel, *The Difference Engine,* Godwin
had been our technical advisor in our effort to link our
Apple word-processors from Austin to Vancouver. Gibson
and I were so pleased by his generous expert help that we
named a character in the novel "Michael Godwin" in his
honor.
The handle "Mnemonic" suited Godwin very well.
His erudition and his mastery of trivia were impressive to
the point of stupor; his ardent curiosity seemed insatiable,
and his desire to debate and argue seemed the central
drive of his life. Godwin had even started his own Austin
debating society, wryly known as the "Dull Men's Club."
In person, Godwin could be overwhelming; a flypaper-
brained polymath who could not seem to let any idea go.
On bulletin boards, however, Godwin's closely reasoned,
highly grammatical, erudite posts suited the medium well,
and he became a local board celebrity.
Mike Godwin was the man most responsible for the
public national exposure of the Steve Jackson case. The
Izenberg seizure in Austin had received no press coverage
at all. The March 1 raids on Mentor, Bloodaxe, and Steve
Jackson Games had received a brief front-page splash in
the front page of the *Austin American-Statesman,* but it
was confused and ill-informed: the warrants were sealed,
and the Secret Service wasn't talking. Steve Jackson
seemed doomed to obscurity. Jackson had not been
arrested; he was not charged with any crime; he was not on
trial. He had lost some computers in an ongoing
investigation -- so what? Jackson tried hard to attract
attention to the true extent of his plight, but he was
drawing a blank; no one in a position to help him seemed
able to get a mental grip on the issues.
Godwin, however, was uniquely, almost magically,
qualified to carry Jackson's case to the outside world.
Godwin was a board enthusiast, a science fiction fan, a
former journalist, a computer salesman, a lawyer-to-be,
and an Austinite. Through a coincidence yet more