precedence: bulk
Subject: RISKS DIGEST 19.58

RISKS-LIST: Risks-Forum Digest  Friday 30 January 1998  Volume 19 : Issue 58

  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. *****

 Contents:
Man jailed because of computer glitch (Bear Giles)
False identification of child support deadbeats (Epstein Family)
Y2K bug at major bank? (Andrew Walduck)
Dangerous handling of null variables in programs (Mike Jeays)
Internet Explorer flaw (Joseph Bergin)
Location tracing service of handy phones starts in Tokyo (Kenji Rikitake)
EuroParl Rpt on NSA, Trade, & Crypto Controls (Vin McLellan)
Crash of A-320, Strasbourg (Alexandre Siniakov)
Re: TCAS near-miss (Nancy Leveson)
Re: robots.txt (Bertrand Meyer)
4-Letter words, Re: CyberSitter (Devon McCormick)
Re: Possible Netscape source code risks (Dale Martin)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 28 Jan 98 16:45:42 MST
From: Bear Giles <[email protected]>
Subject: Man jailed because of computer glitch

>From "Glitches of the Week",
http://www.currents.net/newstoday/98/01/27/news1.html

>Man Jailed Because of Computer Glitch
> Tony Ninness of Agnes Waters, Australia, was jailed for six hours for
> failing to pay a traffic fine, even though it turned out he had paid the
> fine five years ago.  Last month, police came to Ninness' residence with
> outstanding warrants for his arrest.  He was held in custody at the Agnes
> Waters police station until the friend paid the police $1350.  The next
> day, courthouse staff confirmed that Ninness had indeed paid off the fine
> long ago, and issued him a refund check.  But then the police contacted
> him and said they had issued too large a refund, and said he would be
> jailed again unless he returned $114.60.  "It sounds like a load of
> rubbish to me," Ninness told the Sunday Mail newspaper.  "Why should I pay
> it?  It's not my fault."  Police officials blamed computer glitches for
> the problems.

Unfortunately, the article doesn't make it clear if the "excess amount" was
on top of what the friend paid in "outstanding" fines, or if the check was
for $1350 and the police demanded incarceration charges similar to those
becoming common in the United States.

Bear Giles  [email protected]

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

Date: Thu, 29 Jan 1998 21:12:12 -0500
From: Epstein Family <[email protected]>
Subject: False identification of child support deadbeats

*The Washington Post* (29 Jan 1998) reports that the state of Virginia has
been cracking down on noncustodial parents who have fallen behind on child
support payments.  About 15,000 people have paid $15 million.  But 2300
other people were incorrectly identified as delinquent and were sent notices
revoking any hunting and fishing licenses they have.  The incorrect notices
were caused by "a computer programming error".  The state official
responsible for child support apologized and said that safeguards have been
put in place to avoid it happening again.

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

Date: 27 Jan 1998 17:48 EST
From: "Andrew Walduck" <[email protected]>
Subject: Y2K bug at major bank?

I'm having an interesting encounter with one of the major Canadian banks
right now over RRSP (registered retirement savings plan) receipts.  It
smells vaguely Y2K-ish.  Here's the scenario.

In August of 1997, I purchased 11 $1000 GICs (guaranteed investment
certificates) laddered at 4 months increments with the farthest out one
coming due in 5 years (or 2002-09), the earliest would come due in 1 year, 8
months (1999-05) (the actual maturities are 1999 5, 1999 9, 2000 1, 2000 5,
2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9).

In December, I received a receipt for $2000. The bank usually accumulates up
all of your contributions for the year and then sends one receipt. In my
case, I should have received a receipt for $11,000. I thought this strange,
so I phoned their call center and was told that a receipt for the rest of
the amount would be coming. So I made a note in my daytimer, and let it
sleep.  So today (end of January, 1998) I phoned my branch and talked to a
rep I know there about my account. She checks the records and they show that
I was to receive only a $2000 receipt (not $11,000), although, there are 11
different GICs in my account all purchased in August! Fortunately, I still
have the temporary, no good for taxes, receipt. So now she's investigating
and I did some thinking.  Of the 11 GICs I purchased, 2 came due before
2000, (in 1999 5 and 1999 9), the rest came due in (2000 1, 2000 5, 2000 9,
2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). Hmm... $2000 receipt... for
the ones maturing before 2000?  Where did the receipt for the rest go?? ;-)

The hypothesis: If you buy a GIC that matures after 2000-1-1, the receipt
program breaks, and ignores the amount. You don't get a receipt mailed to
you.

Has anyone else had this experience with a Canadian bank?

Andrew Walduck

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

Date: Wed, 28 Jan 1998 09:26:00 -0500
From: "Jeays, Mike" <[email protected]>
Subject: Dangerous handling of null variables in programs

The treatment of null values is arguably reasonable once it is understood -
null values simply fail all comparisons with non-null variables. This means
that if you ask if x(null) < y(non-null), you will be told "no". The same
thing will happen if you change the operator to ">".  Not too bad so far.

However - I found the result of "<>" deceptive. It fooled me into writing a
statement that did the exact opposite of what I expected.  Behaviour like
this in a language is dangerous, because many people will fall into the
trap, and some of them will bring down national telephone systems.

The following code snippets are NOT equivalent:

if x=b then
 print "Equal"
else
 print "Not equal"
endif

and

if x<>b then
 print "Not equal"
else
 print "Equal"
endif

The latter is perverse and non-intuitive. It says the two variables
are equal when one of them is null and the other isn't. Think very
carefully when you use the "<>" operator!

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

Date: Wed, 28 Jan 1998 07:32:02 -0800 (PST)
From: "Joseph Bergin"  <[email protected]>
Subject: Internet Explorer flaw

It seems MS/IE makes it easy to steal private keys:

 Microsoft Product Flaws Make Net Dangerous, Experts Say
 By Douglas Hayward, TechWeb (23 Jan 1998)
 <http://www.techweb.com/wire/story/TWB19980123S0007>

Joseph Bergin, Professor, Pace University, Computer Science, One Pace Plaza,
NY NY 10038  [email protected]  http://csis.pace.edu/~bergin/

 [The beginning of the text is excerpted below by PGN Stark Abstracting:]

Flaws in the security of Microsoft's Internet products allow malicious
hackers to steal users' private encryption keys and impersonate their
victims, security experts said.  [...]  A security advisory note circulated
this week by Peter Gutmann, a security expert in New Zealand, said that
private encryption keys can easily be stolen from the hard disks of machines
whose users are surfing the Web, thanks to flaws in several Microsoft
products, including the Internet Explorer browser and the Internet
Information Server package.  "I would say it was a fairly important security
flaw," Gutmann told TechWeb. "At the moment there is no defense against the
problem."

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

Date: Thu, 29 Jan 1998 20:38:20 +0900 (JST)
From: Kenji Rikitake <[email protected]>
Subject: Location tracing service of handy phones starts in Tokyo

On 20 Jan 1998, NTT Central Personal Communication Network Inc. announced an
experimental service of providing the estimated location of a PHS (Personal
Handy-phone System) terminal through a FAX machine.  The service will be
provided in Tokyo from February to April.  The location information is
accessible by any FAX machine with the phone number and the access PIN of
the PHS terminal.  The information is given by a circle on a map, with the
radius of 100 to 500 meters (or 328 to 1640 feet) range.

The company has been field-testing the service since July 1997, and will
provide the same kind of experimental service for The coming Nagano Olympic
Games too.

The risk is quite obvious; anyone who has a PHS terminal is technically
traceable, without the consent or knowledge of the owner.  I found a similar
service was being developed by British Telecom too[1].

PHS is quite popular in Japan. The number of PHS service subscriber in Japan
was 6,992,000 as of December 31, 1997, according to the report of
Telecommunications Carriers Association[2].

References:
[1] "Spy phones trace cheating husbands -- and employees", RISKS Forum 19:35.
[2] http://www.teleserve.co.jp/tca/whatn/whatn_e.html

Kenji Rikitake <[email protected]> <URL:http://www.k2r.org/kenji/>

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

Date: Wed, 28 Jan 1998 03:30:35 -0500
From: Vin McLellan <<[email protected]>
Subject: EuroParl Rpt on NSA, Trade, & Crypto Controls

A draft ("consultation version") of a report by the European Parliament's
Office for Scientific and Technological Option Assessment (STOA) entitled
"AN APPRAISAL OF TECHNOLOGIES OF POLITICAL CONTROL" has been submitted to
the EuroParl's Civil Liberties and Interior Committee. Several IT-relevant
excerpts are now available at John Young's widely respected crypto-politics
website: <<http://www.jya.com/atpc.htm>

(STOA regs apparently require a document to be distributed only on paper
while it is a "working document."  Quaint, huh? A hardcopy can be ordered by
e-mail from the office of British MEP Glyn Ford <<[email protected]> or
with a fax to STOA in Luxembourg.)

  According to Mr. Young's correspondents, the report covers:

  - The Role & Function of Political Control Technologies
  - Recent Trends and Innovations
  - Developments in Surveillance Technologies
  - Innovations in Crowd Control Weapons
  - New Prison Control Systems
  - Interrogation, Torture Techniques and Technologies
  - Regulation of Horizontal Proliferation
  - Further Research

As expected, a portion of the report highlights the NSA's Echelon
surveillance system, developed and managed in conjunction with its sister
SigIntel agencies from the UK, Australia, New Zealand, and Canada. Snippets
quoted give the flavor, capturing the tenor of fear common in European media
references to the NSA:

"[...] unlike many of the electronic spy systems developed during the cold
war, ECHELON is designed for primarily non- military targets: governments,
organizations and businesses in virtually every country. The ECHELON system
works by indiscriminately intercepting very large quantities of
communications and then siphoning out what is valuable using artificial
intelligence aids like Memex to find key words."

"[...] Within Europe, all e-mail, telephone and fax communications are
routinely intercepted by the United States National Security Agency,
transferring all target information from the European mainland via the
strategic hub of London then by satellite to Fort Meade in Maryland via the
crucial hub at Menwith Hill in the North York Moors of the UK."

The priority targets of this surveillance system are selected by the
participating intelligence agencies -- only one of which is European -- on
the basis of their individual military and political interests, notes
STOA. "Whilst there is much information gathered about potential terrorists,
there is a lot of economic intelligence, notably intensive monitoring of all
the countries participating in the GATT negotiations...."

The report seems to briefly summarize a wealth of earlier reports on the
Echelon network, notably from Bamford and Hager, but offers no apparent
evidence of an independent inquiry.

The report nevertheless suggests that these intelligence agencies have
become a law unto themselves, and operate in a context where most
presumably-private communications are effectively transparent and accessible
to them. "With no system of accountability, it is difficult to discover what
criteria determine who is not a target," the STOA adds in a dry summary.

STOA recommends a new European Parliament study of the "constitutional
issues" raised by the American eavesdropping practices, and of the impact of
Echelon upon (a) the "constitutional safeguards" of the individual European
states, and (b) "the political, cultural and economic autonomy" of EU's
nation states.

The report also recommends that the European Parliament should address and
explicitly reject "proposals from the United States for making private
messages via the global communications network (Internet) accessible to US
Intelligence Agencies.

  "Nor," warns STOA, "should the Parliament agree to new expensive
encryption controls without a wide ranging debate within the EU on the
implications of such measures."

The "implications" of these proposed controls over free access to strong
cryptography, declares STOA, "encompass the civil and human rights of
European citizens and the commercial rights of companies to operate within
the law, without unwarranted surveillance by intelligence agencies operating
in conjunction with multinational competitors..."

That last phrase -- with its explicit reference to the commercial
intelligence which can be gleaned from electronic surveillance (and the
value of such data to "multinational" corporations aligned with each of the
intelligence agencies cooperating in Echelon) -- lies in the dense gray text
of the report like an unlit fuse.

One of the inevitable problems for a nation which fosters both intelligence
prowess and commercial prowess is that success in the former can undermine
the legitimacy of whatever success it achieves in commerce and industry.
International finance and trade rely, in some measure, upon a general
acceptance that the terms of such trade are overt, if not necessarily
"fair."  Without that minimal trust, the successful competitor is viewed not
with respect, or even jealousy; but with scorn and bitterness.  Commercial
failures will inevitably attribute their losses not to the skill or
ingenuity of their international competitors, but rather to the competence
and bias of the mysterious cyberspooks who, all acknowledge, probably
watched the deal unfold.

The MEPs wouldn't be European if they didn't consider the possibility of
that sort of frustration fueling a backlash against the European Union and
EU governments which appear either unable or unwilling to protect the
integrity of their economic infrastructure.

Americans worry about future InfoWar: the corruption of the American
economic infrastructure by tech-savvy foreigners.  A Presidential Commission
studies the threat today, and generates headlines by the ream.

Europeans might fairly ask if they are not already the victims of such
malevolent prowess.  And what guarantees could they be offered that this is
not the case?

"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which
by its nature will resist efforts to restrict it to bureaucrats and
others who deem only themselves worthy of such Privilege."
_ A thinking man's Creed for Crypto/ vbm.

Vin McLellan + The Privacy Guild + <<[email protected]>
53 Nichols St., Chelsea, MA 02150 USA <<617> 884-5548

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

Date: Fri, 23 Jan 1998 20:38:24 +0300
From: "SINIAKOV ALEXANDRE" <[email protected]>
Subject: Crash of A-320, Strasbourg

About the cause of air accidents and crashes of

* Boeing-747, Flight 826, 28 Dec 1997 (Tokyo-Honolulu)
* A-320, 20 Jan 1992 (Mont Saint-Odile, France)
* A-310, 22 Mar 1994 (Novokuznetsk, Russia)
* Tu-154, 6 Dec 1995 (Habarovsk, Russia)

Computer researches show,that Local Geophysical Resonance was primary cause
of these air accidents (B-747) and crashes (A-320, A-310, Tu-154).  This is
a previously unrecognized natural phenomenon, connected with the resonance
characteristics of both the solar system and outer space.  LGR arises from
the interaction of the planets of the solar system and is a cause of an
excitement of space-local sones.  In such cases natural and technical
catastrophes take place.

Specifically, under certain conditions at a moment of LGR, aircraft
flight-safety-critical whirlwinds (tornados) arise.  The whirlwinds are the
common cause of these incidents.

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

Date: Wed, 28 Jan 1998 06:11:30 -0800
From: Nancy Leveson <[email protected]>
Subject: Re: TCAS near-miss (Bellovin, RISKS-19.55)

> ... Someone on the ground switched on a transponder; the TCAS system on
> the plane overhead decided that an aircraft had suddenly appeared 3000
> below it, and suggested that the pilot climb.

This didn't make any sense to me.  TCAS recognizes transponders on the
ground and ignores them.  It also only issues alerts near the ground when an
aircraft is within 750 feet (not 3000) and even at high altitudes the max is
950.

As usual, what you see on the net has been garbled.  The FAA is still
investigating, but apparently the radar data shows that the actual
separation between the two aircraft was much greater than reported by the
media (in fact, the media has exaggerated the whole event).

What seems to have happened is that a maintenance shop on the ground was
testing the altitude reporting capability of the transponder and the
transponder was reporting an altitude above ground level.  The FAA has
guidance to perform such tests with the transponder antenna shielded so that
these events will not occur.  They are still investigating why the shielding
did not occur.

Where the media got the number "3000 feet below it" is unknown but was
probably a garbling of the Southwest Airlines plane's climb rate of 3000
feet per minute.

 [It would indeed be helpful if would-be RISKS contributions gave
 specific sources of information.  To satisfy that desideratum in
 this case, I note that Nancy's information comes from the head of the TCAS
 program at the FAA and the AIRINC investigation report of the incident.
 PGN]

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

Date: Fri, 30 Jan 98 00:23:26 PST
From: [email protected] (Bertrand Meyer)
Subject: Re: robots.txt (Meyer, RISKS-19.57)

I have received a flurry of responses to my article describing the risks
associated with the `robots.txt' convention for excluding search engines
from indexing parts of a Web site.

I apologize for not responding individually to all the people who wrote to
me.  I have put, however, all the answers in a Web page, for the benefit of
anyone who cares to consult them:

       http://www.eiffel.com/private/meyer/robots.html

(available Saturday, Jan 31st, 18:00 California time).

The common theme of the answers can be summarized as follows: I was wrong to
criticize the robots.txt design because it is not meant to protect pages,
simply to keep search engines away from pages that are not *worth* indexing,
e.g. because they are of temporary values. To quote one correspondent, Osma
Ahvenlampi <[email protected]>:

> Robots.txt is a way to protect your web server from being overloaded by a
> dumb robot in a cgi loop, not a security tool. This much should be obvious
> to anyone capable to be in charge of web site administration.

or, according to Chris Cheyney <[email protected]>:

> Anyone stupid enough to leave a network open and count on the optional
> robots.txt robot exclusion de-facto standard for security gets (and should
> get) what he deserves.

Among the people making similar points: Thomas Andrews
<[email protected]>, Nelson Minar <[email protected]>, John
R. Levine <[email protected]>, Jeremy Nelson <[email protected]>, Barry
Margolin <[email protected]>, Laurentiu Badea <[email protected]>, Klaus
Johannes Rusch <[email protected]>. Again, see the Web page for the
details of their comments.

I stand by my original assessment:

1. If every facility was always used as its designers intended, the RISKS
archives would be noticeably slimmer. Here the possibility of misuse seems
rather considerable. If you are just a bit absent-minded, isn't it natural
to use this mechanism to exclude stuff from being indexed and hence believe
no one will find it? "Stupid", maybe -- but not unlikely.  After all, the
designers of the Mercedes A-Class car could also say "anyone stupid enough
to swerve violently when an elk crosses the road gets (and should get) what
he deserves". Unfortunately for them, and probably fortunately for most of
us, that doesn't pass muster.

2. For anyone who thinks this is just a hypothetical possibility, here is
the robots.txt file of the site of a major communications company:

robots.txt

       User-agent: *
       Disallow: /bug-navigator # Bug Data
       Disallow: /warp/customer # Registered Users
       Disallow: /kobayashi # Navigation for registered
       Disallow: /cgi-bin # no programs
       Disallow: /pcgi-bin # no programs
       Disallow: /univ-src/ccden # will get content through /univercd
       Disallow: /cpropub/univercd # obsolete

The first two lines at least suggest to me that this is stuff that the
company doesn't want publicized -- for security reasons, not because it is
of temporary value.  Were I a "hacker" in the bad sense of the term, I would
revel in such information, as it would direct my efforts to the really juicy
bits.

Here is an extract from another page -- I'll let you guess the URL:

       # o Created this file to prevent indexing of one
       #   SME directory.

       User-agent: *

       Disallow: /sparc/SPARCengineUltraAX/oem/
       Disallow: /microelectronics/SPARCengineUltraAX/oem/
       Disallow: /javachip/SPARCengineUltraAX/oem/
       Disallow: /javachips/SPARCengineUltraAX/oem/

       Disallow: /sparc/SPARCengineUltraAX/download/
       Disallow: /microelectronics/SPARCengineUltraAX/download/
       Disallow: /javachip/SPARCengineUltraAX/download/
       Disallow: /javachips/SPARCengineUltraAX/download/

I can't say for sure, but doesn't some of this look a tad like
proprietary information?

3. So even if the respondents are right that it is "stupid" to use
robots.txt in that way, my posting at least draws attention to the risk. If
it succeeds in making just one Webmaster a bit more careful, it will not
have been useless.

4. Of course designers cannot always be blamed for misuses of their
mechanisms. But they should minimize the possibility of misuses. In the
robots.txt case it seems to me rather wrong to have a conspicuous
world-readable file that draws attention to *excluded* information. (Reminds
me of programming languages which implement information hiding by making the
author of each module list conspicuously, as the first thing you read in the
module's text, those features which are *not* exported!) This draws
attention to what should not attract attention. I think that a more
effective convention would have been to include a special marker (META tag?)
in HTML files that shouldn't be indexed, and a special file (exclude.txt?)
in the directories that should not be explored at all. Then you would only
be able to find that information if you already knew where to look.  The
robots.txt mechanism is a godsend for Peeping Toms in search of possible
secrets.

(Thanks too to Marc Horowitz <[email protected]> and
Rik Moonen <[email protected]> for their comments.)

Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel
<[email protected]>, http://www.eiffel.com

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

Date: 27 Jan 1998 13:43:51 -0500
From: Devon McCormick <[email protected]>
Subject: 4-Letter words, re: CyberSitter

 [I wrote an article on the ramifications of binary data as "bad words" for
 our local New York APL (A Programming Language) newsletter.  I think you
 can get the gist of it without the special font you need to read the APL
 code properly.  Devon]

I was thinking about the CDA (Communications Decency Act) the other day,
about how much more important it is to protect our children from bad words
than from bad laws, and I wondered what I could do to help make the 'net
as bland and harmless as television.  One danger no one has pointed out
has to do with another fine U.S. government initiative, the Clipper chip
(or whatever name it's disguised under right now).  It occurred to me that
any good encryption routine, and the NSA promises that Clipper is real good,
effectively turns its input into an output that appears random.

This raises the dismaying possibility, in fact certainty, that an encrypted
datastream will contain dirty words!  At first glance this seems to be simple
enough to remedy: we can scan the encrypted stream for dirty words and replace
them with some equivalent string then convert them back at decryption time;
in fact, someone has already written software to do this using names of U.S.
senators as the dirty word equivalents.  However, this is not as simple as it
seems.  Consider that a dirty word may be written in upper-case letters,
lower-case, or a combination of the two.  Also, there is the concern of
performance degradation.

Pondering these difficulties, I realized that since most dirty words are 4
letters (bytes) long, and that most computers do well with 4-byte (integer)
conversions and comparisons, there is a good solution: consider only the
equivalent "dirty" numbers!  Once I had had this insight I leapt to my
keyboard to answer the question that must now be burning in your mind the
way it was then in mine: just what are these dirty numbers and what can we
do with them?

The following Dyalog APL session explores some of the possibilities.  One
advantage dirty numbers have over dirty words is that you can do things
like find the "average" dirty word: this could lead to a whole new class
of forbidden words (albeit largely unpronounceable ones).

     �BADWORDS
7 4

      Apologies to George Carlin.

     BADWORDS[;0],'*','*',BADWORDS[;,3]
F**K
S**T
Q**M
C**T
F**T
D**N
P**S
 � Or, for the more squeamish:
     BADWORDS[;,0],7 3�'*'
F***
S***
Q***
C***
F***
D***
P***
     ALPNUMAV

OK, let's see what the all-upper-case dirty numbers look like:

     (�ALPNUM)�ALPNUM�BADWORDS
302078184196 357695050756 349323218180 289194005508 301743625220
     293153361412 344827581188

Account for all possible upper- and lower- case combinations by expanding
the upper-case versions with all 4 digit boolean combinations (so "1 1 1 1"
maps all-upper to all-lower, "1 0 0 0" maps all-upper to initial upper-case
letter only).

     VARBW(-/AV�'Aa')�(�(4�2)�16)
     � Assumes upper and lower alphabets are each contiguous.
     ��ALLBW�(VARBW)+��ALPNUM�BADWORDS
16 4  16 4  16 4  16 4  16 4  16 4  16 4
     BADWORDS-ALPNUM[��ALLBW]  � Check that we have what we think we do
1

     �BADVARIANTS(�ALPNUM)���ALLBW
7 16
     BADVARIANTS
1179992907 1179992955 1180005195 1180005243 1183138635 ...
1397246292 1397246340 1397258580 1397258628 1400392020 ...
1364543821 1364543869 1364556109 1364556157 1367689549 ...
1129664084 1129664132 1129676372 1129676420 1132809812 ...
1178686036 1178686084 1178698324 1178698372 1181831764 ...
1145130318 1145130366 1145142606 1145142654 1148276046 ...
1346982739 1346982787 1346995027 1346995075 1350128467 ...

     � So, the average of each bad word variant is:
     ALPNUM[�(4��ALPNUM).5+(+/BADVARIANTS)�16]
� $�
��
���
$���
Y��
%Y��
���

     � And the average variant bad words are:
     ALPNUM[�(4��ALPNUM).5+(+BADVARIANTS)�7]
J���
J��
J�"�
J�"�
J<��
J<�
J<"�
J<"�
����
���
��"�
��"�
�<��
�<�
�<"�
�<"�

     � And the overall average bad word is:
     ALPNUM[,(4��ALPNUM).5+(+/,BADVARIANTS)��,BADVARIANTS]
�ֹ�
     � So, �ֹ� the CDA!

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

Date: 28 Jan 1998 16:32:38 -0500
From: Dale Martin <[email protected]>
Subject: Re: Possible Netscape source code risks (Wilson, RISKS-19.57)

This possibility exists with ANY software project.  Personally, I feel
better about source code that's being looked at by thousands of developers
rather than a few in a company, at least with regards to "slipping nasty
things in so-called bugfixes".

Dale E. Martin | University of Cincinnati Savant Research Laboratory
[email protected]   http://www.ececs.uc.edu/~dmartin

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

Date: 1 Apr 1997 (LAST-MODIFIED)
From: [email protected]
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.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, 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 [email protected] 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 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

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

End of RISKS-FORUM Digest 19.58
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.