Risks Digest 23.13

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Friday 16 January 2004  Volume 23 : Issue 13

   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://www.risks.org as
  http://catless.ncl.ac.uk/Risks/23.13.html
The current issue can be found at
  http://www.csl.sri.com/users/risko/risks.txt

  Contents:
Is the F-35 fighter jet is too reliant on foreign software (Lillie Coney)
Some rental cars keep tabs on drivers (Dewayne Hendricks via IP)
Israeli Post Office break-in (Gadi Evron)
Online poll rigging (Keith C. Ivey)
Students' data on Web, and NYU. on defensive (Monty Solomon)
Bruce Schneier on Orange Alert in Salon (Cory Doctorow via IP)
Some .mil and .gov subscribers of Risks Spammed (Dennis G Rears)
Errant weather alert (David Kennedy)
Moscow ML fails because of time overflow bug (Paul E. Black)
Re: Happy 2**30'th birthday, time_t! (Alistair McDonald, Ed Ravin,
  Massimo Dal Zotto)
Re: The dangers of PGN-ing (Peter Riocreux, Huge)
E-mail scam attacks AT*T Worldnet (John Reinke)
PayPal spoofing (Jacob Palme)
Announcement: Third Bieleschweig Workshop (Peter B. Ladkin)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 09 Jan 2004 16:27:49 -0500
From: Lillie Coney <lillie.coney () acm org>
Subject: Is the F-35 fighter jet is too reliant on foreign software

Defense: The House Government Reform Committee expects to hold hearings this
year to determine whether the Lockheed Martin-made F-35 fighter jet is too
reliant on foreign software, Defense Daily reported Thursday. The concern,
according to a congressional source, is that the fighter, which has been
hailed as a model for international cooperation, could require foreign
software for integral parts of the aircraft's computer system. The
<http://www.gao.gov/>General Accounting Office (GAO) is preparing a report
on the issue and expects to brief committee members in about three to four
weeks, the source added. The National Security, Emerging Threats and
International Relations Subcommittee, chaired by Christopher Shays, R-Conn.,
frequently holds hearings on the status of such weapons-acquisition
programs. The subcommittee's decision to look at the software issue is part
of a broader concern about foreign software development and what effect that
could have on the availability or security of the software.

------------------------------

Date: Wed, 14 Jan 2004 00:33:21 -0800
From: Dewayne Hendricks <dewayne () warpspeed com>
Subject: Some rental cars keep tabs on drivers (via Dave Farber's IP)

Byungsoo Son (from Georgetown, Ontario) rented a car at a Payless Car Rental
outlet in California for 12 days, with a contract rate of $259.51.  When he
returned the car, he was charged $3,405.05 and given a map showing his
actual itinerary, tracked by GPS (including Las Vegas Nevada and the Grand
Canyon in Arizona).  He was charged $1 for each mile driven outside of
California -- in violation of his contract, whose stipulated the car must
remain in California.  [Source: Christopher Elliott, *The New York Times*,
13 Jan 2004; PGN-ed] http://www.nytimes.com/2004/01/13/business/13gps.html

  [This is a classical cautionary RISKS case: READ THE FINE PRINT!  PGN]

Archives at: <http://Wireless.Com/Dewayne-Net>
IP Archives at: http://www.interesting-people.org/archives/interesting-people/

------------------------------

Date: Sun, 11 Jan 2004 11:16:56 -0600 (CST)
From: Gadi Evron <ge () linuxbox org>
Subject: Israeli Post Office break-in

My summary/article on what happened is at
  www.math.org.il/post-office.rtf

  [Thanks to Tom Van Vleck for alerting me to Gadi's article.  A wireless
  gateway was surreptitiously installed in a computer rack in a Haifa branch
  of the Israeli Post Office (which also serves as a bank), perhaps allowing
  sniffing of passwords and other access.  The perpetrators then remotely
  accessed the system to transfer money to newly opened accounts.  The
  computer heist reportedly netted 56,000 shekels (USD$13,000) in the few
  days it was in operation.  Although withdrawals from the new accounts
  reportedly caused the perpetrators to be apprehended, Gadi speculates that
  with a little more care, the fraud could have gone undetected for much
  longer.  PGN-ed]

------------------------------

Date: Thu, 15 Jan 2004 07:58:42 -0500
From: "Keith C. Ivey" <kcivey () cpcug org>
Subject: Online poll rigging

The Senate Republican Conference has a Web poll on its front page about the
capture of Saddam Hussein.  Apparently the results weren't turning out the
way they like (what a surprise for a Web poll!), so they changed the form to
switch the way two answers are recorded.  Now if you choose the 1st choice,
it's recorded as the 2nd, and vice versa.  But there's no feedback to let you
know it's happening.  The change has been confirmed by checking Google's
cache of the page.  Here's the story:
  http://atrios.blogspot.com/2004_01_11_atrios_archive.html#107414565730750569

If politicians are willing to tamper with something as insignificant as a
Web poll, how much more tempting is it to tamper with the results of a real
election?

Keith C. Ivey, Washington, DC <kcivey () cpcug org> 

  [Added note: There was something very similar in November 2003 
  on Bill Frist's Senate site, too:
    http://reason.com/hitandrun/003421.shtml
  KCI]

------------------------------

Date: Mon, 12 Jan 2004 00:41:53 -0500
From: Monty Solomon <monty () roscom com>
Subject: Students' data on Web, and NYU. on defensive

Three years ago, when Brian Frank entered New York University, he signed up
for intramural basketball, providing his name and his university
identification number, which was also his Social Security number.

Yesterday morning, Mr. Frank, who is now a senior, learned from N.Y.U. that
these details had been posted on the Internet. He was among about 1,800
N.Y.U. students who received the same e-mail notification from the
university. In some cases, students' phone numbers were posted, too.  ...
[Source: Karen W. Arenson, *The New York Times*, 10 Jan 2004]
  http://www.nytimes.com/2004/01/10/nyregion/10identity.html

  [An unidentified poster of the entire item in Dave Farber's IP list 
  added this pithy comment:
    >Dave:  Not mentioned in this article is that at the start of 2003,
    >NYU laid off its senior system and network security manager, who
    >had been with the university for nearly 18 years, in a budget-cutting
    >round.  At the time of the layoff, the manager was working on privacy
    >issues, including HIPAA compliance.
  PGN]

------------------------------

Date: Fri, 09 Jan 2004 15:55:59 -0800
From: Cory Doctorow <cory () eff org>
Subject: Bruce Schneier on Orange Alert in Salon (from Dave Farber's IP)

> Homeland insecurity
> The fact that U.S. intelligence agencies can't tell terrorists from children
> on passenger jets does little to inspire confidence.
>
> By Bruce Schneier
>
> 9 Jan 2004  |  Security can fail in two different ways. It can fail to
> work in the presence of an attack: a burglar alarm that a burglar
> successfully defeats. But security can also fail to work correctly when
> there's no attack: a burglar alarm that goes off even if no one is there.
>
> Citing "very credible" intelligence regarding terrorism threats, U.S.
> intelligence canceled 15 international flights in the last couple of weeks,
> diverted at least one more flight to Canada, and had F-16s shadow others as
> they approached their final destinations.
>
> These seem to have been a bunch of false alarms. Sometimes it was a case of
> mistaken identity. For example, one of the "terrorists" on an Air France
> flight was a child whose name matched that of a terrorist leader; another
> was a Welsh insurance agent. Sometimes it was a case of assuming too much;
> British Airways Flight 223 was detained once and canceled twice, on three
> consecutive days, presumably because that flight number turned up on some
> communications intercept somewhere. In response to the public embarrassment
> from these false alarms, the government is slowly leaking information about
> a particular person who didn't show up for his flight, and two
> non-Arab-looking men who may or may not have had bombs. But these seem more
> like efforts to save face than the very credible evidence that the
> government promised.
>
> Security involves a tradeoff: a balance of the costs and benefits. It's
> clear that canceling all flights, now and forever, would eliminate the
> threat from air travel. But no one would ever suggest that, because the
> tradeoff is just too onerous. Canceling a few flights here and there seems
> like a good tradeoff because the results of missing a real threat are so
> severe. But repeatedly sounding false alarms entails security problems, too.
> False alarms are expensive -- in money, time, and the privacy of the
> passengers affected -- and they demonstrate that the "credible threats"
> aren't credible at all. Like the boy who cried wolf, everyone from airport
> security officials to foreign governments will stop taking these warnings
> seriously. We're relying on our allies to secure international flights;
> demonstrating that we can't tell terrorists from children isn't the way to
> inspire confidence.
>
> Intelligence is a difficult problem. You start with a mass of raw data:
> people in flight schools, secret meetings in foreign countries, tips from
> foreign governments, immigration records, apartment rental agreements, phone
> logs and credit card statements. Understanding these data, drawing the right
> conclusions -- that's intelligence. It's easy in hindsight but very
> difficult before the fact, since most data is irrelevant and most leads are
> false. The crucial bits of data are just random clues among thousands of
> other random clues, almost all of which turn out to be false or misleading
> or irrelevant.
>
> In the months and years after 9/11, the U.S. government has tried to address
> the problem by demanding (and largely receiving) more data. Over the New
> Year's weekend, for example, federal agents collected the names of 260,000
> people staying in Las Vegas hotels. This broad vacuuming of data is
> expensive, and completely misses the point. The problem isn't obtaining
> data, it's deciding which data is worth analyzing and then interpreting it.
> So much data is collected that intelligence organizations can't possibly
> analyze it all. Deciding what to look at can be an impossible task, so
> substantial amounts of good intelligence go unread and unanalyzed. Data
> collection is easy; analysis is difficult.
>
> Many think the analysis problem can be solved by throwing more computers at
> it, but that's not the case. Computers are dumb. They can find obvious
> patterns, but they won't be able to find the next terrorist attack. Al-Qaida
> is smart, and excels in doing the unexpected. Osama bin Laden and his troops
> are going to make mistakes, but to a computer, their "suspicious" behavior
> isn't going to be any different than the suspicious behavior of millions of
> honest people. Finding the real plot among all the false leads requires
> human intelligence.
>
> More raw data can even be counterproductive. With more data, you have the
> same number of "needles" and a much larger "haystack" to find them in. In
> the 1980s and before, East German police collected an enormous amount of
> data on 4 million East Germans, roughly a quarter of their population. Yet
> even they did not foresee the peaceful overthrow of the Communist
> government; they invested too heavily in data collection while neglecting
> data interpretation.
>
> In early December, the European Union agreed to turn over detailed passenger
> data to the U.S. In the few weeks that the U.S. has had this data, we've
> seen 15 flight cancellations. We've seen investigative resources chasing
> false alarms generated by computer, instead of looking for real connections
> that may uncover the next terrorist plot. We may have more data, but we
> arguably have a worse security system.
>
> This isn't to say that intelligence is useless. It's probably the best
> weapon we have in our attempts to thwart global terrorism, but it's a weapon
> we need to learn to wield properly. The 9/11 terrorists left a huge trail of
> clues as they planned their attack, and so, presumably, are the terrorist
> plotters of today. Our failure to prevent 9/11 was a failure of analysis, a
> human failure. And if we fail to prevent the next terrorist attack, it will
> also be a human failure.
>
> Relying on computers to sift through enormous amounts of data, and
> investigators to act on every alarm the computers sound, is a bad security
> tradeoff. It's going to cause an endless stream of false alarms, cost
> millions of dollars, unduly scare people, trample on individual rights and
> inure people to the real threats. Good intelligence involves finding meaning
> among enormous reams of irrelevant data, then organizing all those disparate
> pieces of information into coherent predictions about what will happen next.
> It requires smart people who can see connections, and access to information
> from many different branches of government. It can't be seen by the various
> individual pieces of bureaucracy; the whole picture is larger than any of
> them.
>
> These airline disruptions highlight a serious problem with U.S.
> intelligence. There's too much bureaucracy and not enough coordination.
> There's too much reliance on computers and automation. There's plenty of raw
> material, but not enough thoughtfulness. These problems are not new; they're
> historically what's been wrong with U.S. intelligence. These airline
> disruptions make us look like a bunch of incompetents who cry wolf at the
> slightest provocation.   [...]

IP Archives at: http://www.interesting-people.org/archives/interesting-people/
  [Also, See Bruce's Crypto-gram: http://www.schneier.com/crypto-gram.html
  PGN]

------------------------------

Date: Wed, 14 Jan 2004 18:11:39 -0500
From: "Rears, Dennis G [AMSTA-AR-FSP-S]" <d.rears () us army mil>
Subject: Some .mil and .gov subscribers of Risks Spammed

It was just recently brought to my attention that over the last week readers
of RISKS with e-mail addresses in the .mil and .gov domains have been
getting spam that was sent to risks-mil () pica army mil.  That address was set
up years ago to help Peter manage the huge RISKS e-mail list.  As a favour
to Peter, I managed all .mil and .gov e-mail addresses for most of the
1990s.  As part of the Risks Distribution he would send mail to
risks-mil () pica army mil, which then resent the mail to over 500 .mil/.gov
subscribers.  The risks-mil address was hidden so that people would not send
to it.  Last year I stopped the exploder list and all e-mail addresses from
that list were forwarded to Peter to be included in his master list (with
risks-mil () pica army mil being deleted from the master list).  However I
never got around to disabling the risks-mil () pica army mil address.  Thus
spammers were able to exploit this oversight via risks-mil () pica army mil.  I
have now taken steps to solve that problem by disabling the address.  Yet
another risk of not cleaning up things.

------------------------------

Date: Tue, 13 Jan 2004 00:13:10 -0500
From: David Kennedy CISSP <david.kennedy () acm org>
Subject: Errant weather alert

http://www.washingtonpost.com/wp-dyn/articles/A63858-2004Jan7.html  

01/07/04: The National Weather Service's Office of Science and Technology in
Silver Spring sent a test weather-alarm message on Wednesday afternoon.
Intended for internal use only, it was instead sent via the Internet around
the world.  The alarm forecast a blizzard in the Washington DC area.

  "We thought all of the systems that were capable of going live out of this
  other facility where they do development had been disconnected, so that
  this could not happen again," Travers said. "Well, I guess they found out
  that something had not been disconnected."

[It gets better.]

Other weather-related services using the NWS feed contributed to the false
alarm by re-sending it to their customers, some of whom use proprietary
desktop weather clients like Weatherbug and Accuweather.

  Jack Hayes, director of the Office of Science and Technology, said bogus
  messages have snuck out before. His office wrestles with the challenge of
  getting weather hazard information out as quickly as possible.  Any human
  who had looked out the window would have known this warning was a
  mistake. But humans can gum up the works when trying to issue lifesaving
  alerts.  "Any time you have a human [in the process], you introduce a
  delay in getting an important warning out to the public," Hayes said.
  
    [NOTE a similar previous case: NOAA training session test message warns
    of hotter weather as Earth nears the Sun (RISKS-23.07).  PGN]

------------------------------

Date: Fri, 16 Jan 2004 10:50:12 -0500
From: "Paul E. Black" <paul.black () nist gov>
Subject: Moscow ML fails because of time overflow bug

HOL, a system for proving theorems in Higher Order Logic,
  http://sourceforge.net/projects/hol/
is implemented in Moscow ML, an implementation of Standard ML.
  http://www.dina.dk/~sestoft/mosml.html
For soundness, HOL records the time along with new types or theories
(collections of theorems, types, values, etc.)  which are created.  When
time values overflowed on Saturday 10 January in a few libraries of the
underlying Moscow ML 2.00, HOL was rendered unusable.

Moscow ML represents time as seconds since midnight 1 January 1970.  After
10 January the number of seconds exceeded 2^30.  Although this was
anticipated and most code for time handled this, a few libraries did not.
  http://www.dina.kvl.dk/~sestoft/mosml/y2004bug.html

Maintainers issued a patch for HOL and fixes for Moscow ML within days.

Paul E. Black, NIST, 100 Bureau Drive, Stop 8970, Gaithersburg, MD 20899-8970
+1 301 975-4794  http://hissa.nist.gov/~black/ paul.black () nist gov

------------------------------

Date: Tue, 13 Jan 2004 00:00:59 -0000 (GMT)
From: "Alistair McDonald" <alistair () inrevo com>
Subject: Re: Happy 2**30'th birthday, time_t! (RISKS-23.12)

Paul Eggert ends his piece with a thought that a lot of applications will
break in 2038. I think that the problem will appear much sooner than that,
as some software (reservation systems, timetabling, and so on) looks into
the future.

I hope that the time_t wraparound will be a thing of the past by 2010, but
I also hope that some legacy systems from "way back" will still be
running. These systems, maybe embedded, might just fail once and carry on,
or they might be useless as they interface with the real world and their
dates will be 2^32 seconds out.

Alistair McDonald    InRevo Ltd.  http://www.inrevo.com  (+44)(0)7017-467386

------------------------------

Date: Tue, 13 Jan 2004 01:27:14 -0500
From: Ed Ravin <eravin () panix com>
Subject: Re: Happy 2**31 birthday, time_t! (RISKS-23.12)

> About 13 hours ago, the POSIX time_t counter exceeded 2**30, thus reaching
> half its useful positive range (which counts seconds since 1970) on
> traditional hosts with 32-bit signed integer time_t.

My shop uses an old version of the Heimdal implementation of the Kerberos
authentication system (supplied with NetBSD 1.5), and we found
that after the Unix time_t "birthday", our Kerberos clients were issuing
erroneous requests.  The result was that many of our staffers coming in to
work on Monday morning couldn't log in to their workstations.

It's moments like this that make me appreciate the necessity of diverse
software implementations - since we had other versions of Kerberos available
(i.e. MIT Kerberos and a newer version of Heimdal with the bug fixed), all
of which worked, we were able to quickly identify the buggy client program.

------------------------------

Date: Tue, 13 Jan 2004 21:59:19 +0100 (CET)
From: Massimo Dal Zotto <dz () cs unitn it>
Subject: Re: Happy 2**30'th birthday, time_t! (RISKS-23.12)

We have another interesting precedent:

   http://catless.ncl.ac.uk/Risks/21.69.html#subj7

Massimo Dal Zotto <dz () debian org>

------------------------------

Date: 12 Jan 2004 23:30:33 +0000
From: Peter Riocreux <peter.riocreux () cakes org uk>
Subject: Re: The dangers of PGN-ing (Hogg, RISKS-23.12)

> As I'm sure many of the RISKs readers are aware, the Bank of England is a
> Central Bank and hence does not issue its own Visa (or any other credit
> cards) at least for consumers.  

Except that it *does* have consumer accounts, it is just that eligibility is
severely limited.  Current (and possibly past) employees are certainly able
to hold an account, but I know not what other persons may hold one.  As
such, it is perfectly possible that they could have been the target of a
phishing expedition.

The RISK is assuming that the system is the same as in the US, something
which, despite the UK government's best efforts, is still commonly not the
case.

------------------------------

Date: Fri, 16 Jan 2004 17:04:55 +0000 (GMT)
From: huge () huge org uk (Huge)
Subject: The dangers of PGN-ing (Hogg, RISKS-23.12)

  [PGN: Peter Riocreux's point above was also noted by Huge, who added this:]

> How many programmers does it need to be able to analyse a piece of code to
> be able to work out what it does?

In this case, none!  The attachment was conveniently [and correctly] named
as a keystroke logger.

------------------------------

Date: Sat, 10 Jan 2004 10:44:00 -0500
From: "John Reinke" <reinke () att net>
Subject: E-mail scam attacks AT*T Worldnet

-----Original Message-----
From: attwns-announcement-system
[mailto:CustomerNotifications () worldnet att net] 
Sent: Saturday, January 10, 2004 1:04 AM
To: AT&T Worldnet Customers
Subject: ALERT: E-mail scam - [Billing Update Requested (URGENT)]

Dear AT&T Worldnet Service Member,

You may have received a fraudulent e-mail with the Subject line of "Billing
Update Requested (URGENT) " from a sender's address that is either
att.billing () worldnet att net or billing () worldnet att net. This counterfeit
e-mail requests that you resubmit your credit card information for billing
purposes.

[That] e-mail is not from AT&T Worldnet Service.  Please do not respond to
it -- instead disregard and delete it. 

If you have already provided your credit card information in response to the
fraudulent e-mail, we recommend you notify your credit card issuer
immediately.

If at any time you receive an e-mail requesting billing information, please
be aware that it is likely to be a scam. Authentic billing notifications
sent by AT&T Worldnet Service will always direct you to visit the AT&T
Worldnet Member Services secure site, where you will login with your userid
and password to update your billing information.)  Please forward any
suspicious e-mail to AT&T Special Investigations at scam () abuse-att net."

For more information on how to protect yourself against identity theft,
please visit the US Federal Trade Commission's Identity Theft web site, at
http://www.consumer.gov/idtheft

AT&T Worldnet Service

  [But they overlook the fact that the message did direct the reader to a
  site that APPEARED to be an AT&T site. Sheesh, doesn't anyone read over
  there?  John]

------------------------------

Date: Sat, 10 Jan 2004 13:58:53 +0100
From: Jacob Palme <jpalme () dsv su se>
Subject: PayPal spoofing

I received a message which is abbreviated below [and even more by PGN]:

> Received: from unknown (HELO reva) (81.196.161.141)
>    by 0 with SMTP; 6 Jan 2004 01:55:14 -0000
> Reply-To: "service () paypal com" <spooff () paypal com> 
> From: "service () paypal com" <service () paypal com> 
> To: <jpalme () dsv su se> 
> Subject: Account issue
> Date: Tue, 6 Jan 2004 03:51:33 +0200
>
> Due to concerns, for the safety and integrity of the PayPal
> community we have issued this warning message.
>
> It has come to our attention that your account information needs
> to be renew due to inactive members and non-functioning mailboxes.
> If you could please take 5-10 minutes out of your online 
> experience and renew your records you will not run into 
> any future problems with the online service.
>
> However, failure to update your records will result in account 
> deletation [sic].  This notification expires on January 10, 2004.
>
> Once you have updated your account records your PayPal will not be
> interrupted and will continue as normal.
>
> Please follow the link below and renew your account information.
>   http://https-ebay.com   PayPal Service Department

When I clicked on the link, I got to a form which requested a number of
personal data, including my credit card number, its security code and its
PIN code! I have put up a copy of the form they asked me to fill in at
  http://dsv.su.se/jpalme/temp/domain-name-spam-2c.pdf

I got suspicious for several reasons:

(a) No company has ever before asked me for my credit card PIN code.

(b) This information was requested by http, not https. But with a domain
name, http://https-ebay.com which might make some people believe it was
actually using https.

(c) Looking up in whois indicates that the owner of the domain name
https-ebay.com is a private person, not a company.

To be on the safe side, I immediately blocked my credit card, since I had
entered some information before I understood this was a spoof. I also wrote
to PayPal, who confirmed that the mail was not from them!

I have learnt to be more careful and suspicious in the future!

Jacob Palme <jpalme () dsv su se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

  [This is increasingly becoming a problem!  We desperately need 
  some greater authentication and accountability.  PGN]

------------------------------

Date: Fri, 09 Jan 2004 08:45:13 +0100
From: "Peter B. Ladkin" <ladkin () rvs uni-bielefeld de>
Subject: Announcement: Third Bieleschweig Workshop (abridged for RISKS)

The Third Bieleschweig Workshop on System Engineering.
Main themes: Risk Analysis and Root-Causal Analysis
An event of the German Chapter of the System Safety Society
12-13 February, 2004
Center for Interdisciplinary Research (ZiF), Bielefeld

Convened by
University of Bielefeld, Faculty of Technology, RVS Group
Siemens Transportation Systems, Rail Automation
Technical University of Braunschweig, Institute for Railway
        Systems Engineering and Transport Safety

In the Third Bieleschweig Workshop, we shall have causal-analysis
presentations on the 1994 "Friendly Fire" shootdown of two helicopters (WBA,
comparison with existing sociological and STAMP analyses), the Herald of
Free Enterprise capsize (SOL, MES, ECF, comparison), the Brühl derailment
(SOL) and the Royal Majesty grounding (SOL), and the development of
CausalML, all of which work had been planned during the First and Second
Workshops. On the new theme of risk analysis, we shall have presentations on
the PROFUND method, and on the Improved Risk Priority Number concept
recently developed at Siemens. We shall hold moderated discussions on the
causal analysis comparison criteria, as well as on one of the themes:
visualisation, system safety tasks, investigative processes, and
countermeasures.

We invite additional papers on themes in system engineering, especially
concerned with risk analysis, from all applications areas. Please send
proposals for talks (max. 2 pages) to

     Peter Ladkin ( ladkin () rvs uni-bielefeld de )
     by Friday, January 23, 2004.

Further details, including travel information, may be found in the Third
Bieleschweig Workshop announcement in the Bieleschweig pages available
through www.rvs.uni-bielefeld.de .

Peter B. Ladkin, University of Bielefeld, www.rvs.uni-bielefeld.de

------------------------------

Date: 7 Oct 2003 (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 e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 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.Marshall () newcastle ac uk>.
=> 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  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.
 *** NEW: 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: http://www.sri.com/risks
 http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., 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/ .
 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 23.13
************************