RISKS-LIST: Risks-Forum Digest Sunday 20 February 2005 Volume 23 : Issue 73
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/23.73.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
"High-tech passports are not working" (Yves Bellefeuille)
Federal agencies get failing grades on cybersecurity (NewsScan)
Break-In At SAIC Risks ID Theft (Griff Witte via Monty Solomon)
ChoicePoint warns of ID theft concerns (NewsScan)
In the Matter of Component Architecture (Paul Robinson)
RSS reader redirect risks (Monty Solomon)
eBay redirects to phishers from their own site (Pete Krawczyk)
Risks of battery-operated wireless input devices (Peter Pankonin)
You There, at the Computer: Pay Attention (Katie Hafner via Monty Solomon)
Assuming customers can't spell (Andrew Malakoff)
Unintended consequences of automatic abbreviation (John Pettitt)
REVIEW: "Modern Cryptography: Theory and Practice", Wenbo Mao (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 17 Feb 2005 21:15:41 -0500
From: Yves Bellefeuille <yan@private>
Subject: "High-tech passports are not working"
The British weekly magazine _The Economist_ has an article entitled
"High-tech passports are not working":
http://www.economist.com/science/displayStory.cfm?story_id=3666171
The usual arguments are made -- the technology isn't reliable, there will be
too many false positives, and so on -- but there's also a new argument I
hadn't seem before:
"The data on these chips will be readable remotely, without the bearer
knowing. And -- gain at America's insistence -- those data will not be
encrypted, so anybody with a suitable reader, be they official, commercial,
criminal or terrorist, will be able to check a passport holder's details...
"Passport chips are deliberately designed for clandestine remote reading.
The ICAO [International Civil Aviation Organisation, a UN agency]
specification refers quite openly to the idea of a "walk-through" inspection
with the person concerned "possibly being unaware of the operation"."
Apparently, the only country that's ready for the US requirements is
Belgium. It's really the *only* country: the US itself won't be able to
deal with the passport requirements it's imposing on others by the November
2005 deadline!
------------------------------
Date: Thu, 17 Feb 2005 15:21:43 -0700
From: "NewsScan" <newsscan@private>
Subject: Federal agencies get failing grades on cybersecurity
At least half of all federal agencies received a grade of "D" or worse
on the House Government Reform Committee's annual cyber-security report
card. Agencies that received failing marks include the departments of
Agriculture, Commerce, Energy, Health and Human Services, Housing and Urban
Development, and Veterans Affairs. A grade of "D" was awarded to the
departments of Defense and Treasury, as well as the National Aeronautics and
Space Administration and the Small Business Administration. Committee
Chairman Tom Davis (R-VA) was encouraged by the fact that the scores of the
10 agencies, as poor as they were, have actually improved since last year,
but he warned they must still do better: "I hope it won't take some kind of
major cyber-attack to wake everybody up." [*The Washington Post*, 16 Feb
2005; NewsScan Daily, 17 Feb 2005]
http://www.washingtonpost.com/wp-dyn/articles/A30342-2005Feb16.html
------------------------------
Date: Sun, 13 Feb 2005 23:48:14 -0500
From: Monty Solomon <monty@private>
Subject: Break-In At SAIC Risks ID Theft
Computers Held Personal Data on Employee-Owners
Griff Witte, *The Washington Post*, 12 Feb 2005, E01
Some of the nation's most influential former military and intelligence
officials have been informed in recent days that they are at risk of
identity theft after a break-in at a major government contractor netted
computers containing the Social Security numbers and other personal
information about tens of thousands of past and present company employees.
The contractor, employee-owned Science Applications International Corp. of
San Diego, handles sensitive government contracts, including many in
information security. It has a reputation for hiring Washington's most
powerful figures when they leave the government, and its payroll has been
studded with former secretaries of defense, CIA directors and White House
counterterrorism advisers.
Those former officials -- along with the rest of a 45,000-person workforce
in which a significant percentage of employees hold government security
clearances -- were informed last week that their private information may
have been breached and they need to take steps to protect themselves from
fraud.
David Kay, who was chief weapons inspector in Iraq after nearly a decade as
an executive at SAIC, said he has devoted more than a dozen hours to
shutting down accounts and safeguarding his finances. He said the successful
theft of personal data, by thieves who smashed windows to gain access, does
not speak well of a company that is devoted to keeping the government's
secrets secure. ...
http://www.washingtonpost.com/ac2/wp-dyn/A17506-2005Feb11
------------------------------
Date: Thu, 17 Feb 2005 15:21:43 -0700
From: "NewsScan" <newsscan@private>
Subject: ChoicePoint warns of ID theft concerns
ChoicePoint, a Georgia company in the business of selling personal data on
consumers, is alerting 145,000 people throughout the nation that a crime
ring paid for their credit reports, Social Security numbers and other
information. Con artists had posed as owners of debt-collection agencies,
insurance agencies and other firms that told ChoicePoint they needed to run
background checks on consumers. [*San Jose Mercury News*, 17 Feb 2005;
NewsScan Daily, 17 Feb 2005]
http://www.siliconvalley.com/mld/siliconvalley/10921081.htm
------------------------------
Date: Sun, 20 Feb 2005 05:27:37 GMT
From: Paul Robinson <paul@paul-robinson.us>
Subject: In the Matter of Component Architecture
I had sort of a revelation this afternoon when I think I finally figured
what it was that I knew was a missing piece and the explanation.
And it also came to me as to why we have such a horrible problem with
software reliability. Let me ask you to take a moment and consider how you
started this morning.
Most likely, you crawled out of your cave, went down to the stream to bathe
in the ice-cold water, came back and pulled the wheat out of the ground,
stripped the chaff, then used either a mortar and pestle or a grindstone to
make flour, then pulled some yeast from the pot to mix with it to make
bread, then chopped wood, then used the wood to build a fire and baked the
bread, then ground peanuts in the same mortar to make peanut butter, then
spread it across the bread and ate it, because by now it was lunch, no?
No, most likely you got out of a bed, got up and took a hot shower in your
indoor bathroom, poured boxed cereal into a bowl or made breakfast from
materials you bought in a store, then cooked it on a range, or went to a
restaurant and bought something to eat, then went on to work, and probably
in this entire time you did nothing more strenuous than pick up the morning
paper.
Also, you did not mine the ore for your utensils or forge the steel for
them, nor did you build the automobile you drove to work. Or a thousand
other things you used today if you don't drive. You used items someone else
made. And they used things other people made for them to make those things.
So what and how does what I just said have anything to do with the idea of a
means to reduce or eliminate software failure? Because we do not do the same
thing in the virtual space of software that we do in the real world.
Every time you use something manufactured, you use a component. A system as
it were, an object. That component or object is itself built out of other
components, or subsystems, which are operated upon by various other objects
through various events. Let me give a simple example.
Using our hypothetical peanut butter sandwich from earlier in this article,
no, on second thought we'll make it a peanut butter and jelly sandwich, we
have an object which has three components or subsystems, the bread object,
the peanut butter object, and the jelly object, which are manipulated by the
hand and knife objects via the spread event.
Now you may start to see what I'm talking about here. All of the things we
do or work with are generally made by combining other components either to
produce an object or are used standalone (as when someone eats a sandwich
which is finished or was made by someone else). We generally do not build
everything from scratch.
But when was the last time you saw this sort of obvious acceptance of
previously built components in the software development field? Okay, we will
use an operating system and a compiler. That's about it; people will look at
you askance if you talk about code reuse and designing applications to be
built out of modular pieces and possibly completely built out of components
designed by someone else.
For some reason it's perfectly acceptable for a trucking company to build an
accounts receivable application from scratch but nobody in their right mind
would expect them to build their own trucks.
If you're remodeling a kitchen the nearest Home Depot, Lowes, or a thousand
places on the Internet will sell you any of several thousand designs to
match your taste, decor and budget. That even though you are constructing a
space you can buy all the components pre-built and while some people might
be willing to pay extra for custom-built kitchens (and most people won't
because the pre-built stuff is absolutely fine for all but the most unusual
cases), but even at that nobody makes their own stove, refrigerator or sink.
Go out to a typical shop in a data processing organization and they'll look
at you funny as they peer out over the landscape of trees they plan to mill
for the cabinets, and the stocks of steel and copper tubing they have to
build the gas powered refrigerators, and the enamel painting shop they plan
to use to bake the finish onto the custom-built coal-fired stove they'll
provide you with, to give a mismatched comparison.
They also can't estimate how long it will take to build the equipment, they
don't know what it will cost, and as for warranty protection that the stove
won't explode when it's used, a promise that the cabinets will support the
weight of the dishes and groceries you want to put in them, and guarantees
that the refrigerator will start when you plug it in and won't catch fire,
or will even keep food cold, they'll think you're crazy if you want it
anything but "as is."
Does this make any sense?
And we as software practitioners have been getting away with this sort of
racket for decades.
The Sears Department stores of K-Mart Corporation will sell you an
adjustable wrench that not only has a guarantee that it will do what it is
intended for, and is guaranteed against defects in materials and
workmanship, they will even replace it if you broke it because you damaged
it on purpose. Forever. And their Craftsman brand is competitively priced
against tools from competitors. I do note that their more complicated
appliances don't have this strong a warranty, but in any case they do have
one on everything they sell.
If you order even the simplest piece of software from anyone they can't even
give you the minimum under the Moss-Magnuson Warranty Act: that the product
is fit for use for the purpose it is intended to be used. The reasons for
this are many, but come down to two things.
Software has neither architectural integrity nor engineering discipline.
You buy a house and have knowledge that it was built according to detailed
blueprints which an architect knows if it is built according to the
specification that it has the characteristics to support the structure. You
remodel a kitchen and have knowledge that the cabinets were built according
to good engineering practices to support the usual and customary weights and
stresses dealing with household goods used in kitchens.
Software developers will promise neither of these in even the simplest
pieces of software. Neither will there be a promise of architectural
correctness nor even engineering integrity. They can't because they don't
have a way to determine what the load factors or stresses on the software
are. It's all built by hand, on an ad-hoc basis, usually without any formal
disciplines being used, with all new materials milled from scratch. Very
little if any predeveloped components are used.
One of the greatest improvements in programmer productivity was the move
from using wire boards and toggle switches to being able to write programs
in source code, typically assembler. The next boost was the development of
third-generation programming languages such as Fortran, C, Cobol, Basic,
Pascal and six thousand others. And I think the next boost was the
implementation of object orientation. Of the use of components to build
software out of previously constructed pieces. Despite the capacity being
there, it's rarely used.
If you have small components that you know are right, and you then combine
those components to manipulate each other according to their published
interface specifications, the results should be consistently correct. The
results will be predictable, the usage will be consistent every time. But in
general, this is not how we are designing software.
The question that should be asked is, "why this is allowed to continue?"
Software as it is currently being developed provides so much value relative
to its costs that we as practitioners of this medieval-class craft (in terms
of our level of automation and sophistication of production methods) can get
away with practices that would not be tolerated by a Taiwanese manufacturer
of toasters.
And this is the reason we are seeing programming jobs being outsourced to
low wage countries. If you're going to get crappy software there's no reason
to pay premium prices for it. It is exactly the sort of situation that
befell the American automobile manufacturers back in the 1970s and
1980s. And unless we start to make changes we will see exactly the same
thing happening.
Actually some of the software development places that are used for
outshoring have formal practices in place for reducing defects. So it is
entirely possible what we are getting is the exact equivalent of what I
stated above. The overseas "manufacturers" produce better quality at a lower
cost than we do.
I think that a basis of component architecture is the direction that we need
to go in the development of software. That we need to make more software to
be designed as a series of reusable components that can be used in other
contexts. It also means we need to develop at least an engineering
discipline in a way of making software of higher quality and eventually to
reduce the risks of development.
And this is why I now understand more clearly why I knew that there was
something right about this concept even though I didn't know exactly why at
the time. In a book I once wrote, the main character explains about
realizing the validity of a concept even if you're not sure why:
I know how that is; more than once I've had gut feelings about things
where I couldn't put my finger on it, but I knew something wasn't right.
Later I would discover why I had that feeling, and, more importantly, why
I was right, but at the time I did not have the evidence or knowledge to
know why I felt that way.
- George Green, "In the Matter of: The Gatekeeper: The Gate Contracts"
We can continue on the same path of disaster-ridden bugware or we can choose
to change. We can change because the current methods do not work very well,
they spell disaster in terms of cost, reliability, future employment
potential, and the possibility of seeing our craft ruined by heavy-handed
government mandates for licensing. We can choose to change because if we do
not, the choice on how to make the changes may be made for us, and in a
manner we will not appreciate.
The process will not be easy, but the benefits to us will more than outweigh
the short-term losses by having to re-learn a new way of working, and
thinking. If we want to continue to have fun in this craft without being
placed into a bad position because of our own arrogance in failing to
acknowledge the incompetence, sloth and waste our current practices contain,
we need to change. And we need to do it before we are forced to do so
because the customers decide they can't stand it any more, before we do.
------------------------------
Date: Fri, 18 Feb 2005 02:02:45 -0500
From: Monty Solomon <monty@private>
Subject: RSS reader redirect risks
I hooked up my laptop to the network in a hotel room and fired up my browser
to connect. The hotel network is set up so that any HTTP requests redirect
to their registration page before you are registered.
After successfully connecting I noticed that many of my RSS feeds no longer
worked in the RSS reader. It turns out that the RSS reader automatically
replaces feed addresses with any redirects and it tried to refresh the feeds
between the time I connected the laptop and registered to use the
network. The URI addresses for may of the RSS feeds were automatically
changed to "http://soln-sr335.solutionip.com/register/" (the RSS reader was
'active' on the sleeping laptop before it was connected to the network).
This behavior would be repeated when the RSS reader was running when the
network performed its automatic daily shutdown. There wasn't any mechanism
on the registration page to register for the whole hotel stay instead of on
a per diem basis.
At a minimum, the RSS reader should validate the feed at the redirected URI
before blindly switching to it.
------------------------------
Date: Tue, 15 Feb 2005 09:08:18 -0600 (CST)
From: Pete Krawczyk <risks@private>
Subject: eBay redirects to phishers from their own site
eBay fraudsters have a new trick up their sleeve: using eBay's servers to
link to a fraudulent web site.
In the past, it was easy to pass a URL through a decoder and find that the
actual server hosted behind a URL was not owned by eBay, since phishers
would use @, %40, or other domain misdirection tactics. However, I recently
received an eBay fraud mail that contained the following URL, which has been
edited to point to Google:
http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&DomainUrl=http://www.google.com/
As you can see, that URL will access cgi4.ebay.com, and eBay will gladly
hand the browser over to Google for further action. That URL can be
trivially changed to any web site.
The RISK is obvious: allowing untrusted URL redirects in this case will fool
many more people who may now believe that eBay is truly asking for account
details, and may lead to further identity theft.
I contacted eBay, and got nothing but canned responses. I did try the live
chat, and after the rep confirmed that I had not given out my account
information, he said they would investigate. That was on Saturday.
------------------------------
Date: Thu, 17 Feb 2005 16:44:01 +0000
From: Peter Pankonin <webtmc@private>
Subject: Risks of battery-operated wireless input devices
This week a user complained that his computer system had locked up. He had
typed away on a document for an hour (without saving of course) and couldn't
move the mouse. Rebooting didn't fix the problem.
I was summoned to investigate, whereupon I noticed that the mouse pointer
was indeed frozen at the center of the screen. Interestingly enough the
keyboard still worked. Then I noticed that there was no red light emanating
from his wireless optical mouse. After a quick installation of fresh
batteries, the system magically recovered. Unfortunately, I was unable to
recover the data lost after he rebooted.
Peter Pankonin, digitalcrucible
------------------------------
Date: Wed, 16 Feb 2005 22:51:24 -0500
From: Monty Solomon <monty@private>
Subject: You There, at the Computer: Pay Attention (Katie Hafner)
Katie Hafner, *The New York Times*, 10 Feb 2005
FIRST, a confession. Since starting to write this article two hours ago, I
have left my chair only once. But I have not been entirely present, either.
Each time I have encountered a thorny sentence construction or a tough
transition, I have heard the siren call of distraction. Shouldn't I fiddle
with my Netflix queue, perhaps, or click on the weekend weather forecast?
And there must be a friend having a birthday who would love to receive an
e-card right now.
I have checked two e-mail accounts at least a dozen times each, and read
eight messages. Only two were relevant to my task, but I responded right
away to all of them. My sole act of self-discipline: both instant messaging
accounts are turned off. For now.
This sorry litany is made only slightly less depressing when I remind myself
that I have plenty of company. Humans specialize in distraction, especially
when the task at hand requires intellectual heavy lifting. All the usual "Is
it lunchtime yet?" inner voices, and external interruptions like incoming
phone calls, are alive and well.
But in the era of e-mail, instant messaging, Googling, e-commerce and
iTunes, potential distractions while seated at a computer are not only
ever-present but very enticing. Distracting oneself used to consist of
sharpening a half-dozen pencils or lighting a cigarette. Today, there is a
universe of diversions to buy, hear, watch and forward, which makes focusing
on a task all the more challenging.
http://www.nytimes.com/2005/02/10/technology/circuits/10info.html
------------------------------
Date: Thu, 17 Feb 2005 12:38:10 -0800
From: "Andrew Malakoff" <ambler@private>
Subject: Assuming customers can't spell
I'm sure this has come up before, but here it is again. I just tried to use
the web site of my Very Large mutual fund group to change my address. My
new address contains "Greenlake". The c.o.a. form's hidden, unoverridable,
spelling checker insists on, mais naturellement, "Green Lake". The risk of
assuming your customers can't spell their address properly: misdirected mail
and unhappy customers.
A Malakoff, Seattle WA USA http://www.eskimo.com/~ambler
------------------------------
Date: Thu, 17 Feb 2005 19:01:02 -0800
From: John Pettitt <jpp@private>
Subject: Unintended consequences of automatic abbreviation.
I use Thunderbird to read Usenet news - one of the features of this client
is that it abbreviates group names automatically when it displays them. It
does this using the first letter of each part of the group name but retains
the last word- for example comp.protocols.time.ntp becomes c.p.t.ntp. This
works fine until you subscribe to ba.jobs.offered which takes on a whole new
meaning when abbreviated :)
------------------------------
Date: Mon, 31 Jan 2005 07:46:52 -0800
From: Rob Slade <rslade@private>
Subject: REVIEW: "Modern Cryptography: Theory and Practice", Wenbo Mao
BKMDNCRP.RVW 20041207
"Modern Cryptography: Theory and Practice", Wenbo Mao, 2004,
0-13-066943-1, U$54.99/C$82.99
%A Wenbo Mao
%C One Lake St., Upper Saddle River, NJ 07458
%D 2004
%G 0-13-066943-1
%I Prentice Hall
%O U$54.99/C$82.99 +1-201-236-7139 fax: +1-201-236-7131
%O http://www.amazon.com/exec/obidos/ASIN/0130669431/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0130669431/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0130669431/robsladesin03-20
%O tl s rl 1 tc 3 ta 3 tv 0 wq 1
%P 707 p.
%T "Modern Cryptography: Theory and Practice"
A "Short Description of the Book" states that it is intended to address the
issue of whether various crypto algorithms are "practical," as opposed to
just theoretically strong. This seems odd, since no algorithm is ready for
implementation as such: it must be made part of a full system, and most
problems with cryptography come in the implementation. The preface doesn't
make things much clearer: it reiterates a "fit-for-application" mantra, but
doesn't say clearly, at any point, why existing algorithms are not
appropriate for use. The preface also suggests that this book is for
advanced study in cryptography, although it states that security engineers
and administrators, with special responsibility for developing or
implementing cryptography, are also in the target audience.
Part one is an introduction, consisting of two chapters. Chapter one
outlines the idea of the first "protocol" of the book: a "fair coin toss"
over the telephone, grounding the book firmly in the camp of cryptography
for the purpose of secure communications. The remainder of the chapter
points out all the requirements to make such an unbiased selector work,
acting as a kind of sales pitch or "come on" to make you want to read the
rest of the book. The promotion is slightly flawed by the fact that there
is very little practical detail in the material (it takes a lot of work on
the part of the reader to figure out that, yes, this system might work),
excessive verbiage, and poor explanations. The stated "objectives" of the
chapter, given at the end, say that you should have a "fundamental
understanding of cryptography": this is true only in the most limited sense.
Chapter two slowly builds a kind of pseudo-Kerberos system.
Part two covers mathematical foundations. Chapter three deals with
probability and information theory, four with Turing Machines and the notion
of computational complexity, five with the algebraic foundations behind the
use of prime numbers and elliptic curves for cryptography, and various
number theory topics are touched on in chapter six.
Part three addresses basic cryptographic techniques. Chapter seven deals
with basic symmetric encryption techniques, touching on substitution and
transposition, as well as reviewing the operations of DES (Data Encryption
Standard) and AES (Advanced Encryption Standard). The insistence on
converting all operations, and giving all explanations, in symbolic logic
does not seem to have any utility, does not provide any clarity, and makes
the material much more difficult than it could be. Asymmetric techniques,
and attacks against them, are outlined in chapter eight. Finding individual
bits of the message, a process examined in chapter nine, can, over time,
result in an attack on the message or key as a whole. Chapter ten looks at
data integrity, hashes, and digital signatures.
Part four deals with authentication. Chapter eleven reviews various
conceptual protocols, pointing out (for example) that there is a serious
problem of key storage for challenge/response systems. A variety of real
applications are considered in chapter twelve, and warnings issued about
each. Issues of authentication specific to asymmetric systems are covered
in chapter thirteen.
Part five looks at formal approaches to the establishment of security.
There is more asymmetric cryptographic theory in chapter fourteen. Chapter
fifteen examines a number of provably secure asymmetric cryptosystems, while
sixteen does the same for digital signatures. Formal methods of
authentication protocol analysis are given in chapter seventeen.
Part six discusses abstract cryptographic protocols. Chapter eighteen
reviews a number of zero knowledge protocols, which provide the basis for
authentication where the principals are not previously known to each other.
The coin flipping protocol, initiated in chapter one, is revisited in
chapter nineteen. Chapter twenty wraps up with a summary of the author's
intentions for the book.
The book is certainly for advanced study, but it is hardly suitable for
security administrators, professionals, or even engineers. The mathematical
material is quite demanding, and is seldom explained (as opposed to the
clear explanations of the implications of the math that is given in, for
example, "Applied Cryptography" [cf. BKAPCRYP.RVW], or even the equally
advanced but much more comprehensible "Algebraic Aspects of Cryptography"
[cf. BKALASCR.RVW]). However, there are points in the material that could
be useful for practical cryptographic systems, provided one is dealing
primarily with authentication of communications, and the possibility of
physical access is ignored. The text would have been much more useful if
the author could have been induced to provide some of the basic explanations
in English, rather than leaving the reader to work out the math.
copyright Robert M. Slade, 2004 BKMDNCRP.RVW 20041207
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@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. Mailman can let you subscribe directly:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay 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/> .
==> 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 23.73
************************
This archive was generated by hypermail 2.1.3 : Sun Feb 20 2005 - 12:22:06 PST