RISKS-LIST: Risks-Forum Digest Friday 28 March 2003 Volume 22 : Issue 65
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at
http://catless.ncl.ac.uk/Risks/22.65.html
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Autotote betting scam sentencing (PGN)
Patriot software again a concern? (James Paul)
Surveillance Nation (Monty Solomon)
U.S. lifts FBI criminal database checks (Peets)
Text message disables Siemens mobile phones (Derek K. Miller)
Wireless mushrooms (Brian H. Seborg)
Failure of aircraft electronic displays at a critical moment (Peter B. Ladkin)
A320 incident partly due to computer failure (Peter B. Ladkin)
Paper is good (David Magda)
FTC's National Telemarketing "Do Not Call" Web Site to Launch 1 Jul (CDT Info)
Transient Microsoft Passport security vulnerability (James Van Bokkelen)
Re: Traffic lights don't work in the snow (Ryan O'Connell)
Re: Beware the spelling checker (Crispin Cowan)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 21 Mar 2003 11:08:57 PST
From: "Peter G. Neumann" <neumannat_private>
Subject: Autotote betting scam sentencing
Auto-tote that charge,
and lift that trail,
Get a little bunk-o,
and you land in jail.
[Apologies to "Old Man <up the> River"]
In RISKS-22.33 and 22.38 through 22.40, we discussed the case of the former
Autotote programmer who hacked the Catskill NY off-track horse-race betting
system (which had a very weak audit trail), resulting in a rigged $3 million
winning Breeders' Cup Pick Six bet, plus other previous scams, on which his
two Drexel frat buddies collected the winnings. The sentences have now been
handed down. Programmer Chris Harn was given the minimum possible jail time
-- only a year and a day instead of "up to seven years" -- because he
"helped" the authorities; his frat buddies were given two- and three-year
terms. [Source: *San Francisco Chronicle* item, 21 March 2003]
I suppose one of the tabloids might find a cute headline such as
Fat-cat frat rat begat rat-a-tat automat reformat, sat pat. Splat!
------------------------------
Date: Wed, 26 Mar 2003 01:58:13 -0500 (EST)
From: james.paulat_private
Subject: Patriot software again a concern?
"For the second time in as many days, a U.S. Patriot missile defense battery
has apparently locked its sights on an allied fighter plane, raising concern
about a potentially serious glitch in the system's targeting software." A
Patriot system about 30 miles south of Najaf in Iraq apparently locked on to
an Air Force F-16 fighter on 24 Mar, and prepared to fire. The F-16
responded by firing a high-speed anti-radiation HARM missile at the battery,
destroying its radar dish. This came a day after a Patriot missile shot
down a British Royal Air Force Tornado GR4 fighter near the Kuwaiti border,
killing both crew members. The British fliers were the first known friendly
fire casualties of the war in Iraq. [There was discussion about whether to
blame the Patriot software or the system operators, although evidence seems
to favor the former.] [Source: Jonathan Weisman, *The Washington Post*, 25
Mar 2003; PGN-ed]
http://www.washingtonpost.com/wp-dyn/articles/A29390-2003Mar25.html
[The Patriot of course had a checkered role in the 1991 Persian Gulf War,
with initial reports of great success, followed by official reports that
it was only about 10% successful. But after three major upgrades, it is
now thought to be much better, having knocked out 6 of 14 Iraqi missiles.
PGN]
[Incidentally, NBC on 24 Mar 2003 had an item on self-inflicted damage,
noting that in the Vietnam War, 24% of U.S. fatalities were due to
friendly fire. I have heard reports that it was even higher in the
first Gulf War. That is truly astounding! PGN]
------------------------------
Date: Wed, 19 Mar 2003 17:30:58 -0500
From: "monty solomon" <montyat_private>
Subject: Surveillance Nation
Surveillance Nation [excerpt for RISKS]
Dan Farmer & Charles C. Mann, MIT *Technology Review*, cover story, Apr 2003
Webcams, tracking devices, and interlinked databases are leading to the
elimination of unmonitored public space. Are we prepared for the
consequences of the intelligence-gathering network we're unintentionally
building?
Route 9 is an old two-lane highway that cuts across Massachusetts from
Boston in the east to Pittsfield in the west. Near the small city of
Northampton, the highway crosses the wide Connecticut River. The Calvin
Coolidge Memorial Bridge, named after the president who once served as
Northampton's mayor, is a major regional traffic link. When the state began
a long-delayed and still-ongoing reconstruction of the bridge in the summer
of 2001, traffic jams stretched for kilometers into the bucolic New England
countryside.
In a project aimed at alleviating drivers' frustration, the University of
Massachusetts Transportation Center, located in nearby Amherst, installed
eight shoe-size digital surveillance cameras along the roads leading to the
bridge. Six are mounted on utility poles and the roofs of local businesses.
Made by Axis Communications in Sweden, they are connected to dial-up modems
and transmit images of the roadway before them to a Web page, which
commuters can check for congestion before tackling the road. According to
Dan Dulaski, the system's technical manager, running the entire webcam
system-power, phone, and Internet fees-costs just $600 a month.
The other two cameras in the Coolidge Bridge project are a little less
routine. Built by Computer Recognition Systems in Wokingham, England, with
high-quality lenses and fast shutter speeds (1/10,000 second), they are
designed to photograph every car and truck that passes by. Located eight
kilometers apart, at the ends of the zone of maximum traffic congestion, the
two cameras send vehicle images to attached computers, which use special
character-recognition software to decipher vehicle license plates. The
license data go to a server at the company's U.S. office in Cambridge, MA,
about 130 kilometers away. As each license plate passes the second camera,
the server ascertains the time difference between the two readings. The
average of the travel durations of all successfully matched vehicles defines
the likely travel time for crossing the bridge at any given moment, and that
information is posted on the traffic watch Web page.
To local residents, the traffic data are helpful, even vital: police use the
information to plan emergency routes. But as the computers calculate
traffic flow, they are also making a record of all cars that cross the
bridge-when they do so, their average speed, and (depending on lighting and
weather conditions) how many people are in each car.
http://www.technologyreview.com/articles/farmer0403.asp
------------------------------
Date: Wed, 26 Mar 2003 18:15:30 +1100 (EST)
From: Peets <phobosat_private>
Subject: U.S. lifts FBI criminal database checks
The Justice Department has lifted a requirement that is supposed to ensure
the accuracy and timeliness of information about criminals and crime victims
before it is added to the National Crime Information Center database, which
includes data about terrorists, fugitives, warrants, people missing, gang
members, and stolen vehicles, guns, and boats.
Records are queried increasingly by the nation's law enforcement agencies to
help decide whether to monitor, detain or arrest someone. The records are
[supposedly] inaccessible to the public, and police have been prosecuted in
U.S. courts for misusing the system to find, for example, personal
information about girlfriends or former spouses. [RISKS has noted at least
two such cases resulting in deaths of the identified persons.]
Officials said the change, which immediately drew criticism from
civil-liberties advocates, is necessary to ensure investigators have access
to information that can't be confirmed but could take on new significance
later, FBI spokesman Paul Bresson said. [...]
Critics have noted complaints for years about wrong information in the
computer files that disrupted the lives of innocent citizens, and the FBI
has acknowledged problems. In one case, a Phoenix resident was arrested for
minor traffic violations that had been quashed weeks earlier; in another, a
civilian was misidentified as a Navy deserter.
[Source: Ted Bridis, AP, 25 Mar 2003; PGN-ed]
http://news.yahoo.com/news
?tmpl=story2&cid=542&u=/ap/20030325/ap_on_go_ca_st_pe/fbi_database_4&printer=1
------------------------------
Date: Wed, 19 Mar 2003 10:15:19 -0800
From: "Derek K. Miller" <dkmillerat_private>
Subject: Text message disables Siemens mobile phones
MacInTouch.com relays a CNET News.com report by Ben Charny that a particular
text message can disable cell phones manufactured by Siemens.
The e-mails contain a single word, taken from the phone's language menu,
surrounded by quote marks and preceded by an asterisk, such as "*English" or
"*Deutsch", Siemens said. Opening the short-text message on a Siemens
35-series cell completely disables it [according to Siemens spokesman Jacob
Rice]. Siemens 45-series phones are less affected and can be resuscitated
after about two minutes of work. Both phones are sold only in Europe. The
phones are not the victim of a denial of service attack, as suggested by
some participating in an e-mail string on Bugtraq, a popular security e-mail
list. "It's just not possible," Rice said. [Source: news.com, 18 Mar 2003]
http://news.com.com/2100-1039-993197.html?tag=macintouch
Derek K. Miller dkmillerat_private http://www.penmachine.com
Penmachine Media Company, Vancouver, Canada
------------------------------
Date: Thu, 20 Mar 2003 14:52:47 -0500
From: "brian-h seborg" <brian.seborgat_private>
Subject: Wireless mushrooms
Many articles have covered wireless security issues from a technical
perspective including the weaknesses in WEP, the fixes to WEP (fast-packet
keying), and recommendations for securing a wireless network (802.1x,
suppress SSID broadcast, etc.), and I suspect that we in the technical
community have a pretty clear understanding that tried and true network
security solutions like SSL, SSH, firewalls, IPSec, two-factor
authentication, etc. can be brought to bear to secure wireless networks in
the same way we have used them to secure Internet and dial-up connections
for years. The question is, do non-technical users have any knowledge of
these things? My own experience is that the answer is "no."
ISPs, especially those offering DSL and high-speed cable modems aren't doing
much if anything to make up for this deficit even though they are now
delivering wireless routers to customer's homes. I have noticed that in the
last month three more access points have popped up in my neighborhood. Of
the five I can see, only one has WEP turned on and all are broadcasting
their SSIDs (making them visible to even a novice). As I drive around in my
car, I can easily connect to four of these access points. Further, when I
checked to see if I can connect to the default administrative port, I can do
so on all but the WEP protected one, and on three, I see they have not reset
the default admin password, meaning I could, if I were a bad guy,
reconfigure their router either rendering it useless (until they
re-initialize it), or opening it to the Internet.
The fact that insecure access points are springing up like mushrooms makes
it likely that we will begin to see a rash of hacked home users unless the
high-speed Internet providers wake up and begin providing guidance to their
customers about how to properly secure their wireless routers. In the case
where Internet providers are supplying the wireless gear, it would seem
prudent that they would supply each device with a default safe configuration
(random SSID, SSID broadcast suppressed, random admin username, random admin
password, etc.). Unfortunately, like usual, appropriate measures are
unlikely to be taken until security breaches begin to get noticed and
customers begin to complain. In the meantime, as good neighbors, we might
consider performing a high-tech neighborhood watch informing neighbors that
their home networks are insecure. :-)
------------------------------
Date: Thu, 20 Mar 2003 08:52:17 +0100
From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
Subject: Failure of aircraft electronic displays at a critical moment
David Learmount reports in Flight International, 11-17 Mar 2003, p12, on the
loss of attitude information on the electronic attitude direction indicators
(EADI) in a temporary loss-of-control incident due to icing with an Embraer
Brasilia commuter turboprop operated by Comair.
The incident happened on 19 Mar 2001, and was investigated by the US
National Transportation Safety Board. I have been unable to reach the FAA
Incident Database to obtain the original documents (it refuses my
connection).
The aircraft was cruising at 17,000 ft when it encountered icing conditions.
It oscillated violently in roll (110 degrees left, 130 degrees right, then a
360 degree roll to the right -yes, that's a full rotation) and pitched 60
degrees nose down. During this manoeuvre, the EADIs, which present crucial
information to the pilots, "blacked out". The attitude indicator gives
perhaps the most crucial control information available to pilots in
instrument flight conditions. They recovered at 10,000 ft altitude when the
aircraft emerged into visual flight conditions below the cloud. They pulled
3.6g to recover from the descent, itself a hairy manoeuvre.
"In subsequent test of the EADIs according to the production test
requirements (PTR), the first officer's display was found to have an
intermittent rate failure. However, the PTR does not test the equipment
against its specified maximum performance in roll and pitch rate, not
reaching in the icing incident until almost all the violent roll
oscillations had occurred."
"The NTSB reports that the EADIs blacked out well before the specified
performance limits had been reached,and benchtests in the performance area
between the standard PTR criteria and specified performance limits caused
both instruments to malfunction."
The NTSB apparently suggests that all Rockwell-Collins AHC-85 EADIs have
been inadequately tested following manufacture and after maintenance.
Rockwell-Collins apparently says that it did not carry out tests beyond PTR,
and that the unit's performance at limits could be inferred from the results
of the tests to PTR.
One cannot, and should not, conclude, however, that use of these electronic
devices has led to new types of failures. Traditional mechanical gyroscopes
would likely have tumbled in these manoeuvres, and the pilots would have
thus been no better off. The issue that this incident highlights concerns
the discrepancy between expected performance (represented by the PTRs and
the "limits") and actual performance. This is a specification and testing
issue.
Peter Ladkin, University of Bielefeld, Germany, http://www.rvs.uni-bielefeld.de
------------------------------
Date: Thu, 20 Mar 2003 18:03:17 +0100
From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
Subject: A320 incident partly due to computer failure
John Sampson pointed out to me a computer-related incident to an A320.
On 21 May 1998, a Leisure International Airways A320 overran the runway at
Ibiza Airport in the Balearic Islands. The damage was minor (broken
nosewheel and consequent underbelly damage, dirt and stones ingestion in the
engines, etc), and there were no serious injuries, so the incident probably
does not rate as an accident.
The accident report is not long and a PDF version may be found at
http://www.mfom.es/ciaiac/publicaciones/informes/1998/1998_019_A.pdf
Braking on landing is normally automatic, controlled by the Brake and
Steering Control Unit (BCSU) computer. The BCSU is selected "on" during
approach, by pressing the "A/SKID & N/W STRG" (Antiskid and nosewheel
steering) button on the front panel in the cockpit. The BCSU has two
identical channels, active ("hot") and standby, and there is a command (COM)
and monitor (MON) function of the BCSU. MON checks COM for agreement before
output is sent. Upon detection of a disagreement, a "disagree" condition is
logged in the BCSU as well as sent to the Centralised Fault Data Interface
Unit (CFDIU).
Suppose a fault develops and is detected in the hot channel. If hot and
standby channels are both functioning, the system then transfers control
to standby, which becomes hot and operates non-redundantly (that is, the
faulty channel remains permanently cold). If standby is cold, hot remains
active, control is not transferred, and one lives with whatever functions
are still provided by the faulty hot channel.
The BCSU performs a functional test on selection of Landing Gear Down,
opening the Normal Selector Valve, which allows pressure from the Green
hydraulic system to reach the four servo valves of the Normal system (Normal
Servo Valves, NSVs). The BCSU then sends current momentarily to the NSVs and
monitors the pressure rise. It then closes the NSVs, closes Normal Selector
Valve, and then opens the NSVs again to release the pressure. This will
have happened on the incident flight, says the report.
If the Normal braking system is inoperative, Alternate braking is made
available by a spring-biased changeover valve (Automatic Selector Valve)
which allows pressure from the Yellow hydraulic system to the Alternate
braking system. Alternate braking is achieved through foot pedal pressure,
transmitted hydraulically along a low-pressure line and ported through a
Brake Dual Distribution Valve (BDDV) and a Dual Shuttle Valve to the
Alternate servos on the brakes (these are separate devices from the
NSVs). Antiskid is controlled by the BCSU, if still operative.
There is also a Parking Brake, operating off the Yellow system, backed up by
a Brake Accumulator. Operating the Parking Brake handle applies unmodulated
Yellow system hydraulic pressure (but reduced) to the brakes via the Parking
Brake Valve.
Or so it all says here.
One problem is as follows. The status of the BCSU switch is sampled every 20
msec asynchronously by the COM and MON functions. It is possible that a
short switch operation, from 20 ms to 50 ms, could be detected by one
function and not by the other, causing a "disagree" fault in one, or indeed
in both, channels of the BCSU. The analysis concludes that this indeed
happened. The crew saw the "BRAKES BSCU Ch 2 FAULT" message on the
Electronic Centralised Aircraft Monitoring (ECAM) display on selection of
the BCSU. The message is listed in the Operating Manual as for "Crew
Awareness" and there is no corresponding procedure. It turns out that the
crew could have reset the BCSU but this info is not in the Abnormal and
Emergency Procedures section of the Ops Manual, but in the Supplementary
Techniques section, where it commences with the conditional "In case of
braking /steering difficulty..." which they did not have because they were
still in the air.
What will have then happened is that the hot channel, Channel 2, will have
relinquished control to the standby, Channel 1, which will have logged the
same fault, but cannot relinquish control since it is operating without a
standby. On sensing touchdown ("Weight on Wheels"), four seconds after the
spoiler deployment signal, the Autobrake function of the BCSU calls the
command function to apply current to open the Normal Selector Valve. The
COM/MON disagreement fault becomes a failure; the Normal Selector Valve is
not opened, the Autobrake function is lost and the Normal braking system is
left inoperative. This is recorded in the CFDIU as a failure in the NSVs
(although the actual failure was upstream), which is sent to the ECAM as a
"BRAKES AUTO BRK FAULT" message, which is inhibited from display during
landing until engine shut down, but is recorded for post-flight replay. So
the crew never saw it.
The Alternate system was inhibited due to moisture contamination of the
BDDV, which it was presumed had turned to ice during flight and inhibited
operation of the BDDV. This course of events was confirmed by subsequent
testing.
In principle, the crew could have used the parking brake, but they had not
been so trained. It says in the operating manual that operating the parking
brake deactivates the other braking systems.
At the end of the overrun area, there is a sea wall and the Mediterranean
Ocean. Rather than risk taking a swim, the captain swerved the aircraft from
side to side to lose momentum through scrubbing the tires, and then turned
it finally 90 degrees away and bumped over the grass and into a low bank "to
remain within the aerodrome boundary". The report describes the ride thereto
as "quite rough".
BCSU software Release 7 was on board; Release 8 provides a fix for the
sensing discrepancy condition involved in this incident; Release 9 was
released after in-service experience with Release 8. I don't know what
release is current.
Peter Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de
------------------------------
Date: Sun, 23 Mar 2003 12:55:28 -0500
From: David Magda <dmagda+risksat_private>
Subject: Paper is good
As we all (should) know, paper is still a useful thing to have around.
A weblog entry from [1]:
--- entry ---
Sat, 22 Mar 2003
Books in Print Wouldn't Fit
An odd thing happened on my way to buy a book at my local Barnes and Noble.
[Yes, yes, before you go and point it out, any story that starts out this
way is almost certainly my fault.]
Me: Can you tell me who the author of ______ is?
Retailer: I can't.
Me: Well, can you look it up?
Retailer: I can't. Our computers are down.
Me: Ah. Well, can I take a gander at your Books in Print.
Retailer: [Smirks] We don't have a list of all the books in print.
We wouldn't be able to fit it in the store.
Me: In fact you would. We had these great big volumes and then later
microfiche when I worked in a bookstore a number of years back.
Retailer: Do you know how many books that would be?
Me: Lots, I do believe you. But the fact remains that Books in Print
is indeed a real thing.
Retailer: Well, we don't have it. We have computers instead.
Me: Apparently not.
[Only ever so slightly paraphrased.]
--- entry ---
Book in Print(tm) can be found online at [2]: assuming that your
computer is up, the 'Net is working, and their computer is up. :> You
need an account to search their online catalogue. A paper version is
described at [3].
[1] http://www.raelity.org/archives/society/literature/books_in_print_wouldnt_fit.html
[2] http://www.booksinprint.com/bip/
[3] http://www.bowker.com/bowkerweb/catalog2001/bibtoc.htm
David Magda <dmagda at ee.ryerson.ca>
... Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
------------------------------
Date: Wed, 26 Mar 2003 15:06:50 -0500
From: CDT Info <infoat_private>
Subject: FTC's National Telemarketing "Do Not Call" Web Site to Launch 1 Jul
[via Monty Solomon]
The Federal Trade Commission has announced that the Web site allowing
consumers to put their telephone numbers on the national registry to stop
telemarketing calls will launch in July. The FTC will also have a toll free
number to call. The FTC expects overwhelming demand for the project and is
therefore rolling out the toll free number beginning on the west coast and
heading east throughout the summer. March 26, 2003
The FTC The National "Do Not Call" Registry Page
http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html
Comments of CDT and others to FTC supporting "Do Not Call" list [pdf] March 28, 2002
http://www.cdt.org/privacy/020328cpg-dnc-comments.pdf
CDT comments to FCC on "Do Not Call" December 9, 2002
http://www.cdt.org/privacy/021209cdt.shtml
http://www.cdt.org/mailman/listinfo/cdt-announcements
------------------------------
Date: Wed, 19 Mar 2003 16:05:18 -0500
From: "James Van Bokkelen" <jbvbat_private>
Subject: Transient Microsoft Passport security vulnerability
When a laptop arrived last week with a sacrificial Windows XP Home Edition
installed on it, we combined curiosity with a testing opportunity, and
analyzed its network traffic with our NetIntercept tool. After using
UDP-based protocols to locate resources, and HTTP and HTTP over SSL to
register itself, the WinXP installer asked if we wanted to create a .NET
Passport account. We agreed. After an initial exchange with host
nexus.passport.com using HTTP over SSL, subsequent HTTP connections used
normal HTTP on port 80.
We were quite surprised by several POST commands to
register.msnia.passport.net. Each contained plaintext answers to the
previous screen's questions. All the critical data necessary to hijack the
.NET passport was exposed: name, birthday, ZIP, gender, occupation, password
and secret question/answer. A more detailed analysis can be found at
http://www.sandstorm.net/passport
This took place on the morning of 14 Mar 2003. Microsoft was informed as
soon as we made our way through the obfuscation protecting the proper
channels, and they assured us the problem was being worked on. Testing on
17 Mar led us to believe it was fixed, and Microsoft confirmed this later in
the day. They told us the problem had been introduced as part of routine
web site maintenance earlier in the week. Because it didn't involve
customer software, they didn't plan to issue a security bulletin.
The risks associated with maintaining systems are well known; I expect an
enormous number of people have studied that particular set of transactions
since the Passport roll-out. However, any others who looked during the
period of vulnerability apparently didn't inform Microsoft. Presumably we
won't hear more unless a rash of identity theft generates publicity.
Although I've been involved with the Internet for years, I had avoided using
my credit card over the net until this month. Given current tools, I'll
feel compelled to read the page source before I do so again.
------------------------------
Date: Tue, 11 Mar 2003 10:02:46 +0000 (GMT Standard Time)
From: "Ryan O'Connell" <ryan-risksat_private>
Subject: Re: Traffic lights don't work in the snow (RISKS-22.62)
This is not a new problem for anyone used to riding a small (125cc - 7.6
cubic inches I believe is the US measurement) motorbike. Many small sports
motorbikes are made almost entirely of alloy to reduce their weight. (The
Aprillia RS125 is an example) Sometimes, there's not enough metal in the
bike to trigger these sensors - leaving you sitting at the lights wondering
what to do next. On many roads you can't turn round so you just have to risk
running the red light.
Fortunately, when this happens it's usually late at night so there's no
other traffic about to trigger the lights and therefor no other traffic that
can hit you.
On a busy road, the risks are obvious. You have no choice but to attempt to
join a potentially busy road by going through a red light or ride on the
pavement to a safe spot to rejoin traffic. (I usually chose the latter
option.)
------------------------------
Date: Tue, 18 Mar 2003 17:05:51 -0800
From: Crispin Cowan <crispinat_private>
Subject: Re: Beware the spelling checker (NewsScan, RISKS-22.64)
> ... However, using the software, the two groups made about the same number
> of errors -- 16 vs 17.
What this experiment does not account for is to compare the 16 or 17 errors
in a document assisted by the spelling checker vs. the error rate in
documents that are never proof read at all because the author could not be
bothered.
Crispin Cowan, Chief Scientist, WireX http://wirex.com/~crispin/
HP/Trend Immunix http://h18000.www1.hp.com/products/servers/solutions/iis/
------------------------------
Date: 29 Mar 2002 (LAST-MODIFIED)
From: RISKS-requestat_private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
send e-mail requests to <risks-requestat_private> with one-line body
subscribe [OR unsubscribe]
which requires your ANSWERing confirmation to majordomoat_private .
If Majordomo balks when you send your accept, please forward to risks.
[If E-mail address differs from FROM: subscribe "other-address <x@y>" ;
this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
Lower-case only in address may get around a confirmation match glitch.
INFO [for unabridged version of RISKS information]
There seems to be an occasional glitch in the confirmation process, in which
case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
.UK users should contact <Lindsay.Marshallat_private>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 21" for volume 21]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Lindsay Marshall has also added to the Newcastle catless site a
palmtop version of the most recent RISKS issue and a WAP version that
works for many but not all telephones: http://catless.ncl.ac.uk/w/r
http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
http://www.csl.sri.com/illustrative.html for browsing,
http://www.csl.sri.com/illustrative.pdf or .ps for printing
------------------------------
End of RISKS-FORUM Digest 22.65
************************
This archive was generated by hypermail 2b30 : Fri Mar 28 2003 - 10:08:13 PST