Risks Digest 21.19
From
risks@csl.sri.com
Date
Tue, 9 Jan 2001 13:11:36 -0800
[: hacktivism :]
RISKS-LIST: Risks-Forum Digest Tuesday 9 January 2001 Volume 21 : Issue 19
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 <URL:http://catless.ncl.ac.uk/Risks/21.19.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Security at UK nuclear power stations (Brian Randell)
Re: Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (Bob Dubery)
Motorola flex non-non-non-leap year (Dan Jacobson)
Millennium error in Postscript calendar (Eric Lindsay)
Two satellite failures (Peter B. Ladkin)
Teen intercepts MD's pages, makes medical orders (Terry Carroll)
Dutch Railways to introduce electronic access/ID card (Marcus de Geus)
Risks of "upgrades" and network-centric applications (Jay R. Ashworth)
Re: Chinook (Phil Payne, Ryan O'Connell)
Re: CIOs: "What, Me Worry?" (Mark Hull-Richter)
Re: Egghead.com (Jonathan Kamens, Mark Hull-Richter)
Re: Y2K+1 bug in Sharp Organizer (Philip Berman, Jonathan Kamens)
Re: IBM and Intel push copy protection (David Collier-Brown)
Security white paper (Gene Spafford)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 9 Jan 2001 10:16:27 +0000
From: Brian Randell <Brian.Randell@newcastle.ac.uk>
Subject: Security at UK nuclear power stations
There is an article in today's Guardian starting:
"Tough new security checks are to be imposed at nuclear power stations
after a guard employed to protect the station attempted to sabotage the
site's computers . . ."
Apparently he was caught hacking the power station's system in June
1999 "to alter sensitive information".
The full text is at
http://www.guardianunlimited.co.uk/nuclear
Brian Randell
Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne,
NE1 7RU, UK Brian.Randell@newcastle.ac.uk +44 191 222 7923
[Seen by Dave Stringer-Calvert at
http://news.bbc.co.uk/hi/english/uk/newsid_1107000/1107353.stm
-- which notes that the guard had never been vetted and had two
undisclosed criminal convictions. The Bradwell magnox reactor in Essex
is the nearest nuclear power generator to London. PGN]
------------------------------
Date: Fri, 5 Jan 2001 09:13:12 +0200
From: "Bob Dubery" <bdubery@netcare.co.za>
Subject: Re: Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (RISKS-21.18)
One possible cause of the inability to handle 31 Dec 2000 is a potential bug
that year2000.com warned about some time ago:
http://www.year2000.com/y2kcurrent1.html
Usually a year spans 53 calendar weeks or part weeks. But 2000 spanned 54
weeks or part weeks. This occurs every 28 years. In 1972, computer systems
and embedded code were not as pervasive as they are now.
If a system has software that uses the number of the calendar week, then it
may have problems on 31 Dec 2000 which is the start day (and only day) of
week 54.
[The year 2000 began on a Saturday and ended on a Sunday; ergo, 54
calendar weeks. PGN]
------------------------------
Date: 07 Jan 2001 06:26:43 +0800
From: Dan Jacobson <jidanni@kimo.FiXcomTHiS.tw>
Subject: Motorola flex non-non-non-leap year
My Motorola flex page knows about leap years, and that every 100 years
is a non leap year, and every 400 years is a non-non-leap year, but it
didn't know every 1000 years is a non-non-non-leap year, well, something like
that, anyways, had to set it to 1996 at the millennium.
http://www.geocities.com/jidanni Tel886-4-25854780 e-mail:restore .com. ¿n¤¦¥§
------------------------------
Date: Sat, 06 Jan 2001 20:26:22 GMT
From: eric@wrevenge.com.au (Eric Lindsay)
Subject: Millennium error in Postscript calendar
For the decade and more I have been printing myself a monthly
calendar using a free Postscript program.
%!
% PostScript program to draw calendar
% Copyright (C) 1987 by Pipeline Associates, Inc.
% Permission is granted to modify and distribute this free of charge.
I checked for Y2K errors, and had no problem with the
output. However it turned out the first calendar for 2001
was in error by several days.
/startday { % starting day-of-week for this month
/off year 3000 sub def % offset from start of "epoch"
off
off 4 idiv add % number of leap years
off 100 idiv sub % number of centuries
off 1000 idiv add % number of millennia
1 add 7 mod 7 add % offset from Jan 1 3000
/off exch def
1 1 month 1 sub {
1 copy
days_month exch 1 sub get
exch 2 eq
isleap and
{
1 add
} if
/off exch off add def
} for
off 7 mod % 0--Sunday, 1--monday, etc.
} def
The code was originally starting from 2000. As you can see, you can
be pretty arbitrary about starting dates.
However, I wonder how many other calendar programs out there are
also working their way backwards from some fairly arbitrary date,
rather than forwards from some date in the past?
Eric Lindsay http://psiphi.server101.com/airlie
Airlie Beach Qld Australia - Great Barrier Reef entry
------------------------------
Date: Sun, 07 Jan 2001 18:37:55 +0100
From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Subject: Two satellite failures
"The Boeing Satellite Systems (formerly Hughes Space and Communications)-
built Galaxy VII communications satellite operated by PanAmSat has stopped
functioning in geostationary orbit following a spacecraft control processor
(SCP) fault that has hit several sister satellites." (Flight International,
5-11 December 2000, p34, article "Control fault knocks out Galaxy" by Tim
Furniss. The capitalised "G" is important.)
This wasn't the first. The craft lost its first SCP in June 1998. The second
SCP stopped functioning on 25 November 2000; the craft lost attitude control
and its solar panels lost track of the sun.
Apparently, tiny crystalline structures can grow and bridge the terminals of
tin-plated relay latching switches to their case, causing a short
circuit. People have known about it since a Hughes analysis in 1995 from
telemetry data, but there isn't much one can do about it on satellites
launched years before. "It is believed" that the builder switched to nickel
plating from tin in 1997.
The EarthWatch Quick Bird 1 satellite may have suffered from a computer
error, causing its solar arrays to deploy while still attached to the
ascending Cosmos 3M booster rocket, launched from Plesetsk on 21 November
2000, according to a report in Flight International (12-18 December 2000,
p36) citing "Russian officials". The satellite was lost, which resulted in
"48 employees or 24% of the work force of EarthWatch being laid off".
Peter Ladkin
------------------------------
Date: Mon, 8 Jan 2001 16:13:13 -0800 (PST)
From: Terry Carroll <carroll@tjc.com>
Subject: Teen intercepts MD's pages, makes medical orders
AP reports that a Virginia teenager obtained a pager used by the Inova
Fairfax Hospital, in Fairfax Virginia. According to the article, he then
"gained access to the hospital's paging system" (the article is not clear
on whether this was a hack, or what) and forwarded a physician's number to
his pager.
When the physician was paged, the allegedly boy returned the calls and
gave the nurses medical orders, including authorizing prescriptions and
minor medical procedures (such as blood tests and oxygen administration).
According to the Washington Post, he is believed to have issued "about a
dozen orders."
Yikes.
<http://news.findlaw.com/ap/o/1110/1-4-2001/20010104042024690.html>; also,
<http://www.washingtonpost.com/wp-dyn/articles/A14467-2001Jan3.html>.
An earlier report by the Post notes that:
The court papers and hospital say that on the overnight shift of Dec.
7-8, the youth ordered 12 treatments for six patients. His orders
allegedly included prescribing the blood thinner heparin and asking for
blood tests and oxygen for patients.
In each case, the orders were medically "appropriate under the
circumstances," said Russell Seneca, chief of surgery at the hospital.
<http://www.washingtonpost.com/wp-dyn/articles/A13455-2000Dec15.html>
Terry Carroll, Santa Clara, CA carroll@tjc.com
------------------------------
Date: Sun, 31 Dec 2000 13:31:14 GMT
From: Marcus de Geus <marcus@degeus.com>
Subject: Dutch Railways to introduce electronic access/ID card
On 28 Dec 2000, *De Volkskrant*, one of the leading Dutch morning papers,
reported on its front page that NS, the Dutch Railways, are set to invest
3,000 million guilders (approx. 1,400 million euro) over the next decade "to
improve the quality of service". The article reads like a "for your
convenience" notice.
One of the main items (at 1,100 million guilders) scheduled for improvement
is public safety on platforms. Improved safety is to be achieved through the
introduction of CCTV cameras and electronic access barriers. In time (the
year 2002 is mentioned), the latter are to restrict platform access to
persons carrying (and presumably, swiping) a Public Transport Chipcard,
which will also act as a means of identification. The chipcard scheme alone
is budgeted at 500 million guilders.
One obvious risk to the public is of course the connection the scheme will
provide between two hitherto distinct sets of demographics. The real-time
linking of personal data to transport information will no doubt prove to be
irresistible to marketeers should the scheme ever come to fruition.
Another, perhaps less obvious, risk concerns the loss of quality of service
resulting from such a scheme. Will incidental travelers be forced into
separate queues to have their photographs taken and their personal details
checked? How will incoming cross-border rail passengers be expected to cope?
What happens to flight passengers arriving at Schiphol airport, one of the
main transit points in the Dutch railway system? The mind boggles.
Marcus de Geus <marcus@degeus.com> http://www.degeus.com
------------------------------
Date: Tue, 9 Jan 2001 15:21:59 -0500
From: "Jay R. Ashworth" <jra@baylink.com>
Subject: Risks of "upgrades" and network-centric applications
Regular readers of RISKS will of course be familiar with the syndrome
described here, but the lesson bears repeating because, apparently, some
people still haven't gotten with the program.
The State of Florida, in the last 3 years or so, has a) turned over all it's
tele- and data-communications business to a single vendor (that this vendor
is Intermedia Communications, for whom I have a personal and professional
distaste isn't especially germane to this discussion) and b) replaced their
vehicle registration management computer software system.
(What they replaced it with was one of those horribly inefficient "make a
3270 look like Windows" things that are all the vogue these days -- with
everyone except the poor front-end operators, but *that's* not directly
germane, either. :-{ )
What *is* on point here is that new system (b) doesn't allow off-line
transactions to be made in any fashion except by hand, on legal pads, and,
of course, the network (a) failed yesterday for between 4 hours and all day,
depending on which office you were in, because of "an incomplete overnight
attempt to upgrade the fiber-optic communications network", according to a
story in today's St Petersburg Times, at
http://www.sptimes.com/News/010901/TampaBay/Technical_glitch_stal.shtml
No matter *who* the carrier is, if you've only got one, you'd better have
your backup plans in order. If you've only got one carrier, and you *don't*
have a manual fallback option, you'd better have the number for Office
Depot's delivery desk.
Have *you* looked at your "emergency preparedness" binder lately?
Jay R. Ashworth <jra@baylink.com> Baylink The Suncoast Freenet
Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
------------------------------
Date: Sat, 06 Jan 2001 12:04:39+0000
From: phil@isham-research.freeserve.co.uk
Subject: Re: Chinook (RISKS-21.18)
The debate about the Chinook accident continues and progress is slow. I
suggest using http://www.computerweekly.co.uk and entering 'CHINOOK' as a
search argument.
There are many aspects of RISK. One is undoubtedly that of putting all your
eggs in one basket - flying such a concentration of critical expertise in a
single aircraft was reckless; the more so because they were engaged in
activities so vital to anti-terrorist efforts.
Another is flying a significant number of passengers in an aircraft equipped
with neither a flight data recorder nor a cockpit voice recorder. This is
the computing-related risk - we simply do not know what actually happened on
the flight, except that 29 people died.
The third was previously unknown - that serving officers of the British
armed forces could be posthumously condemned for gross negligence, even
though the Queen's Regulations under which they operate specifically forbid
this in the absence of conclusive proof.
Yes - the apparent actions of the pilots appear to contravene their training
and orders. But we don't know for certain what happened on the flight, and
that's the key risk the Royal Air Force ran. Many people (including a
substantial number of Members of Parliament) agree that the dead officers'
families should not be used as scapegoats for the authorities' use of a
single aircraft and their failure to provide data and voice recording on a
passenger flight, especially where specific safety concerns existed about
both the particular aircraft and the type in general.
Phil Payne http://www.isham-research.freeserve.co.uk
------------------------------
Date: Fri, 5 Jan 2001 08:30:25 +0000
From: "Ryan O'Connell" <ryan@complicity.co.uk>
Subject: Re: Chinook (RISKS-21.18)
The distinction between VFR and IFR is purely a civil aviation one. Military
pilots are not constrained in such a way, and have a number of systems at
their disposal that civil pilots do not have.
> ... the crew were required to make a 180 degree turn and fly out of the
> cloud. That is what they were trained to do. That is what the law required
> them to do and that is what the RAF rules required them to do.
This is what civil flight rules required them to do, not what RAF rules
required them to do.
The RAF pilots broke civil flight rules, which they are quite entitled to
do. Military pilots are required to follow civil flight rules only when it
does not interfere with operations. Given that the aircraft was carrying a
number of prominent anti-terrorist figures and that Northern Ireland is
generally regarded as a war zone as far as the military is concerned, the
pilots would have been following war-time military rules and not civil
flight rules.
RAF jet and helicopter pilots are highly trained in "Nap of Earth" flying,
which involves flying as close to the ground as possible even in adverse
weather conditions and was used to great effect in the Gulf War. The
Chinook would have been fitted with a terrain-following radar for exactly
this purpose, which the pilots would have been using. (This is not the same
system as Civil radar altimeters, military systems show the pilot the
"shape" of the terrain in front of the aircraft)
Flying at 1,500m (about 4000ft) above the high point would expose the
aircraft to anti-aircraft fire, and is probably not within the capability of
the aircraft in any event. (Chinook aircraft have a service ceiling of about
2500m, and Scotland has quite a number of large hills) It seems in this case
that the RISK of flying under civil rules and being shot down was deemed
greater than the RISK of flying under military rules - the military are
trained to take risks, and if that judgment was incorrect it should be the
officers in charge that are responsible, not the pilots.
Ryan O'Connell - <ryan@complicity.co.uk> - http://www.complicity.co.uk
------------------------------
Date: Fri, 5 Jan 2001 17:19:19 -0800
From: Mark Hull-Richter <Mark.Hull-Richter@quest.com>
Subject: Re: CIOs: "What, Me Worry?" (RISKS-21.18)
> ... Meanwhile, a 1999 survey found that Fortune 1000 companies lost
> more than $45 billion in thefts of proprietary information that
> year. [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001]
I am HIGHLY skeptical of all claims of losses by large corporations. The
Virus Myths web page (http:www.vmyths.com) is replete with examples of
hyperbole and exaggerated claims of losses due to viruses and virus hoaxes
without one shred of substantive evidence to back up those numbers. How
does this $45 billion number come about? How does a company arrive at the
amount of money they actually lost due to theft of proprietary information?
(How does one quantify such a loss anyway? Was the theft before or after
the information gained value by market success of the product? Either way,
these numbers are all estimates since they can't be physically quantified
unless a lawsuit is involved, in which case the "loss" is recoverable.)
Notice at least that they didn't have the audacity to blame the losses on
hacking incidents, just "theft of proprietary information."
------------------------------
Date: Mon, 8 Jan 2001 22:52:03 -0500
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
Subject: Re: Egghead.com (Murphy, RISKS-21.18)
Such a scheme would almost certainly be detected quite easily. If only 1%
of the 500,000 credit card users check their statements every month and
report charges they didn't make (and I imagine that in fact the percentage
is higher than that; you do, don't you? I certainly do), the various credit
card companies will be hit with 5,000 complaints in short order. Each
credit-card company has legions of people and computers looking for patterns
to detect cases of extensive fraud. Furthermore, I imagine that the various
credit-card companies work together in some way to combat fraud, so their
information would be pooled.
Even if the number of customers reporting the bogus charges is low, surely
the credit-card companies' fraud prevention algorithms will be suspicious of
a new merchant suddenly ringing up tens of thousands of dollars in purchases,
at least suspicious enough to flag the merchant's account for a human being
to examine more closely? Merchants do *not* get their money from the
credit-card companies immediately, you know.
Once the fraud is detected, its pattern is usually easy to determine (the
credit-card companies do, after all, have auditable trails of all charges
going back for quite a long time; if the trail isn't auditable, then how
does the "organized crime boss" get his money?) and the credit-card
companies can recover the money from the company which placed the illegal
charges on the cards.
The usual strategy for preventing the bilked customers from complaining is
to give the front company a name that makes it look like a pornographic Web
site or telephone hotline. This is supposed to make most people too
embarrassed to complain about the errant charge. I find it hard to believe
that this is particularly effective, considering that we read about these
failed schemes over and over in the newspapers.
To pull off this kind of fraud successfully, you need to have control over a
large number of mostly legitimate merchants who are willing to launder the
bogus charges for you, you need to make the amounts of the bogus charges
small, and you need to spread them out over time rather than charging them
all at once. All of these restrictions obviously limit the amount of profit
you can successfully reap from such a scheme. And even if you are
successful for a time, there's always a chance that one of the credit-card
companies will catch up with one of the merchants, and there's always a
chance that the merchant will sing like a canary when he's supposed to be
clamming up about where he got those credit-card numbers from.
>[Simson Garfinkel commented:
> I simply do not understand why companies insist on keeping the old
> VISA/MC numbers in their computers.]
Because what the focus groups tell them, over and over again, is that
shopping on-line has to be fast and painless, and the faster and more
painless it is, the more likely it is that customers will keep using your
site. If two sites are equal in all ways except that one of them stores
your credit-card number so you don't have to reenter it and the other one
doesn't, the one with the stored numbers has a competitive advantage.
People care more about saving thirty seconds every once in a while than they
do about the remote chance that their credit-card numbers might be stolen by
a hacker.
I can't say that I particularly blame them. How many people, really, are
damaged by fraudulent charges on their credit cards which can be traced to
numbers stolen from Web sites? How often do such fraudulent charges go
uncaught by the credit-card companies?
I confirm every item on every credit-card statement I receive. Anyone who
does so has nothing to fear from hackers breaking into Web sites and
stealing lists of credit-card numbers. In my opinion, anyone who does *not*
do so is being foolish, regardless of whether they allow their credit-card
numbers to be stored on Web sites.
Jonathan Kamens
------------------------------
Date: Fri, 5 Jan 2001 17:19:19 -0800
From: Mark Hull-Richter <Mark.Hull-Richter@quest.com>
Subject: Re: Egghead.com (Murphy, RISKS-21.18)
> Suppose you have 500,000 VISA/MC numbers in your computer, [...]
> and have the means and desire to rack up just $20 worth [...] for a
> cool fast million dollar profit [...] what is to stop me from offering
> your system administrator some tidy sum (even 10%!) to just slip in
> a floppy disk and grab me a copy of the data?
Last I checked, $20 x 500,000 is $10,000,000 - that 10% just got a LOT
bigger...
------------------------------
Date: Mon, 8 Jan 2001 07:39:51 -0500
From: "Berman, Philip" <Philip.Berman@itt.com>
Subject: Re: Y2K+1 bug in Sharp Organizer (RISKS-21.18)
This is an update of my previous posting. I was able to reach Sharp
Customer Service and the problem has been verified by them. It seems to be
isolated to only the model YO-550. In addition my report that it seemed to
be a 2001 problem is not entirely accurate. The condition (loss of all
memory) occurs when the two least significant digits of the date fall
between 01 and 49. Thus setting the calculator to 1901 will cause the
problem. If I just wait for 2050 the problem will go away.
Not only has Sharp confirmed the problem, but they have indicated that they
will exchange my organizer for a new model.
Philip Berman <philip.berman@itt.com>
------------------------------
Date: Mon, 8 Jan 2001 22:28:56 -0500
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
Subject: Re: Y2K+1 bug in Sharp Organizer? (Berman, RISKS 21.18)
>About 4 years of notes and phone numbers lost (yes you can back it up
>to a computer - The backup kit cost about the same as the organizer).
And what is the "cost" of reconstructing the four years of notes and phone
numbers? I can't imagine that it's less than it would have cost to buy and
use the backup kit.
In my opinion, this point is as important as Mr. Berman's main point about
the failure of his Sharp organizer (and presumably many others) when
confronted with dates in 2001: If your data is worth keeping, it's probably
worth backing up.
According to the Sharp Web site, the cable for connecting Mr. Berman's
organizer to a PC costs $49.99 and the software to use with it costs $99.99.
Admittedly, that's a bit pricey, but is $150, amortized over four years,
really more expensive than the aggravation caused by the loss of the data?
When my brother gave me an organizer as a gift years ago, the first
thing I did was figure out how I could transfer its data to/from my
computer. I refused to store *any* data on it until I was confident
that I would not lose anything when it died. And indeed, when I
finally dropped it one too many times and it gave up the ghost, all of
its data was backed up intact on my PC and I didn't lose anything.
Incidentally, the Sharp Electronics Web site
(<URL:http://www.sharpelectronics.com/about/AboutY2k/0,1334,,00.html#YO550>)
says that Sharp is aware of this problem and will replace any affected
YO-550, free of charge. It also confirms that, "UNFORTUNATELY, ANY CUSTOMER
ENTERED DATA FROM THE DEVICE NOT BACKED UP TO A PERSONAL COMPUTER WILL NOT
BE RECOVERABLE."
Jonathan Kamens
------------------------------
Date: Fri, 05 Jan 2001 09:40:09 -0500
From: David Collier-Brown <David.Collier-Brown@canada.sun.com>
Subject: Re: IBM and Intel push copy protection (Gelsinger, RISKS-21.18)
This explanation may be erroneous: a member of the ATA committee is cited at
http://www.ihateapple.com/ "Hard Drive Copy Protection Update" as saying
that IBM has in fact proposed a set of ATA commands to do so.
The Register has followed up by posting a set of frequently asked questions,
including a counter-argument to the claim that the extension is only for
removable media.
Read the article at http://www.theregister.co.uk/content/2/15718.html
and make up your own mind.
dave David Collier-Brown, Performance & Engineering Team, Americas Customer
Engineering (905) 415-2849 davecb@canada.sun.com
------------------------------
Date: Fri, 29 Dec 2000 20:50:19 -0500
From: Gene Spafford <spaf@cerias.purdue.edu>
Subject: Security white paper
Risks readers may be interested in the report at this link:
<http://www.cerias.purdue.edu/events/summit_4q2000.php>
>From that page:
Extraordinary changes in the way we do business and lead our lives in the
ever-connected world of the future will create tremendous security
challenges. These challenges will be shaped by many of today's emerging
trends: the rapid acceleration of network speed, connectivity and the
overall number of devices; the removal of the human element from many
everyday transactions; and easier and cheaper collection of public and
private information. More than ever before, we will demand security
solutions that enable businesses to thrive and private information to be
protected.
Accenture has just released the Security Call to Action and executive
summary, from the 15 security experts who participated in the CERIAS
Security Vision Roundtable. This two-day event, jointly sponsored by
Accenture and the Purdue University CERIAS (Center for Education and
Research in Information Assurance and Security), brought together both
industry pioneers as well as information security leaders experts at some of
the largest and most influential companies in the world. The report includes
a Call to Action and a list of the key trends affecting security over the
next decade. The bottom-line is that doing security right requires the
greater community of business leaders, technologists, educators and
political leaders to look seriously at this Call to Action and to commit
resources and energy to help lead us all to a more secure world.
Accenture is the new name for Andersen Consulting as of January 1, 2001.
------------------------------
Date: 26 Dec 2000 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
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 DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <risks-request@pica.army.mil> (Dennis Rears).
.UK users should contact <Lindsay.Marshall@newcastle.ac.uk>.
=> 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 risks@CSL.sri.com 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 20" for volume 20]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
==> 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 21.19
************************
[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]