The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 18 Issue 77

Monday 20 January 1997

Contents

o Playboy strikes again
PGN
o Potential misery in Missouri: Taxes For Telephiles
Mike Coleman
o Leaking WWW surfer interest profiles
Anders Andersson
o Re: Handwritten signatures used for verification
Dave Finkelstein
o Re: UPS use of handwritten signatures, Lauren Weinstein article
PGN
o Blaming the safety people
Joshua Levy
o The Millennium problem: another too-young case
David R. Vinograd
o Y2036, Y2038, and the superiority of UNIX
D.J. Bernstein
o Re: More Y2K humor: Split the difference
Tony Lauck
o Re: More on fired contractor...
Carlie Coats
o Re: Taco Bell-issimo
Vincent Weaver
o IBMmail flame on -- albeit out of character
PGN
o Re: Risks of miskeying e-mail addresses
Darin Johnson
Niall Murphy
o Irrelevant risks of miskeying e-mail addresses
Lawrence H. Smith
o Chuq spoofing Spaf, and the archives
Adam Shostack
o Privacy Digests
PGN
o The SEI Conference on Risk Management - Preliminary Program
Carol Biesecker
o Info on RISKS (comp.risks)

Playboy strikes again

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 17 Jan 1997 9:25:52 PST
TCI's cable-TV provider in Springfield, Missouri, was testing its planned
inclusion of the Playboy Channel (to begin in February), when the Cartoon
Network channel suddenly began airing the Playboy video along with the
regularly programmed Flintstones' audio.  The results were perhaps more
noticeable than they might have been, because bad weather had closed the
local schools and children were at home.  [Source: Associated Press item in
the *San Francisco Chronicle*, 17 Jan 1997, AS2.  Maybe the program was
something about Sharon kissing the Barney Stone?]

There seems to be something magnetically RISKS-attractive about the Playboy
Channel, which last summer appeared unscrambled in the Palo Alto area
because of a power-failure-induced chip failure (RISKS-18.50).  A PC program
[a nicely overloaded acronym, since the program was presumably not
politically correct!] had previously appeared in the *Jeopardy* time-slot in
the Chicago area for 10 minutes, due to a screwup (RISKS-18.22).  Of course,
what comes around goes around; 10 years ago the Playboy Channel was
intentionally disrupted by a CBN employee, with satellite-spoofed
programming declaiming ``Repent Your Sins'' (RISKS-10.62).


Potential misery in Missouri: Taxes For Telephiles

Mike Coleman <coleman@chez-gnu.cstp.umkc.edu>
Fri, 17 Jan 1997 17:43:51 -0600 (CST)
Being the technophile, or perhaps just temporarily insane, I decided to try
filing my taxes using the IRS's and State of Missouri's "Telefile" system.
These systems allow the user to key in the figures from a simple return on
their touch-tone phone.  The systems also compute several values and speak
them back to the user so that said user can record them for future
reference.

Observations:

1.  Both systems provided my authentication information in an unsealed
packet through the USPS, even though I had not requested this.  Ergo, it
would be quite simple for someone else to file for me.  Ugh.  (Hmm, if I
couldn't file because someone beat me to it, would that count as "Denial of
Service"?)

2.  Both systems use a number as a "user id".  The IRS number seemed
suitably mysterious, but the Missouri number was quite familiar, being of
the form "ABACADADB".  Familiar, that is, because that pattern is also a
perfect match for my Social Security Number.  Ugh.

3.  The user-interface for the IRS system was nice enough, albeit somewhat
tedious.  The Missouri system, on the other hand, had the annoying habit of
rattling off figures at unexpected moments without providing the rattled
user a means for having them repeated.  Ugh.

Each item seems to involve a poor solution to a problem that has superior
solutions that are well-known and relatively simple.

Mike Coleman   http://ctr.cstp.umkc.edu/~coleman


Leaking WWW surfer interest profiles

Anders Andersson <andersa@Mizar.DoCS.UU.SE>
Fri, 3 Jan 97 23:52:00 +0100
I notice that AltaVista's inline advertisements link to a server outside
Digital, "ad.doubleclick.net", and that the URL includes the user's list of
keywords being searched.  I'm concerned that these URL's may occasionally
leak information about the user's interests and inclinations to third
parties, information which the user may prefer to keep private.

This is not a new problem that appeared with the inline ads, since also the
Referer: field of the HTTP protocol discloses to a target server exactly
what AltaVista index page led the user to it.  However, this requires that
the user willfully follows that link.

If sensitive information being leaked via the Referer: field is a problem,
the user may obtain client software that withholds Referer: data, either
conditionally or unconditionally.  Also, a user who has asked AltaVista for
"gay" pages is probably not too concerned about accidentally disclosing this
fact to the maintainer of said "gay" pages.

However, the doubleclick.net ads appear to bear no relationship to the
keywords being searched, and they appear not only in the URL for the
hyperlink to follow, but also in the IMG SRC URL.  This means that in order
to avoid disclosing my keyword lists to doubleclick.net, I have to disable
automatic loading of inline images when using AltaVista!

Why is it that when I perform a search for, say, "gay OR nazi AND
scientology", AltaVista tricks my browser to give this very search string
away to an advertising company by means of an inline image (the contents of
which has nothing to do with my search)?  I think I can trust the AltaVista
maintainers not to save my keyword lists for future analysis, but what about
an advertising company?

It's kind of serendipity reversed.  When you open a book to look up
information on a specific subject, the book scans your mind to find out what
other interests and hobbies you have.

Anders Andersson, Dept. of Computer Systems, Uppsala University
Box 325, S-751 05 UPPSALA, Sweden   +46 18 183170   andersa@DoCS.UU.SE


Re: Handwritten signatures used for verification (Hall, RISKS-18.74)

Dave Finkelstein <davef@xcert.com>
Tue, 07 Jan 1997 16:51:11 -0800
I was in Las Vegas between Christmans and New Year's, and decided to
purchase some sunglasses from The Sunglass Hut, a large chain of sunglass
retailers in the U.S. and Canada (and perhaps other countries as well).  I
paid for my purchases with my Visa card, the receipt was placed in a special
holder, and I was asked to sign the receipt with an electronic pen.  The
salesman said that they can transmit the signature during the verification
process as an additional check; the signature sent is compared with what
Visa has on file.  I was told that the signature isn't sent always, only in
circumstances where a card might be being watched for unauthorized charges.

All this information came from the salesman; I'd be interested to hear
if anyone has any details about this system.

David Finkelstein, Xcert Software Inc., davef@xcert.com http://www.xcert.com
604.640.6210 (tel)  604.681.6220 (fax)


Re: UPS use of handwritten signatures, Lauren Weinstein article

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 17 Jan 1997 9:25:52 PST
The latest issue of PRIVACY Forum Digest, Friday, 17 January 1997,
Volume 06 : Issue 02, Moderated by Lauren Weinstein (lauren@vortex.com),
has an excellent piece of analysis on the United Parcel Service (UPS)
use of handwritten signatures:
    YOUR SIGNATURE FOR SALE? -- A PRIVACY Forum Special Report
by Lauren, who reports on the results of his investigations on this problem.
Information on how to find that issue on the web, or to subscribe to either
of the privacy digests is noted further on in this issue.


Blaming the safety people

Joshua Levy <joshua@intrinsa.com>
Fri, 10 Jan 1997 16:35:27 +0000
Story from the Boston Globe via Institute for Global Communications
<labornews@igc.apc.org>:

To summarize, a company's president has been arrested for manslaughter after
two of his workers were killed in separate accidents, a year apart.  One was
pulled into a machine which lacked basic (and legally required) safety
devices, the other was crushed by a front-end loader with inoperable brakes.
The company had been fined hundreds of thousands of US dollars for dozens of
previous safety violations.  The RISK is contained in the following quote.
Bowley is the president; Codinha is his lawyer:

Codinha said Bowley had ``safety officers'' working in the junkyard when the
accidents occurred. ``This should have been their [the safety officers']
responsibility,'' Codinha said.

This guy seems to believe that you can ignore safety laws simply by hiring
"safety officers" and blaming them when people get killed.

Joshua Levy <joshua@intrinsa.com>

  [The incidents are not particularly computer related, but the last
  paragraph may be more widely applicable than generally realized.  PGN]


The Millennium problem: another too-young case

"David R. Vinograd" <D.R.Vinograd@city.ac.uk>
Mon, 20 Jan 1997 16:56:43 +0000 (UT)
The Halifax Building Society (Savings & Loan) members who were not sent
voting papers for conversion (to a bank) as they were too young - born in
1890s and ages over 100 (e.g., (19)97 - (18)93 = 4).  [Reported on UK radio
last week]

David Vinograd, Director of Computing Services, City University, Northampton
Square, London EC1V 0HB, England +44-171-477-8170 D.R.Vinograd@city.ac.uk


Y2036, Y2038, and the superiority of UNIX

"D.J. Bernstein" <djb@koobera.math.uic.edu>
18 Jan 1997 09:00:21 -0000
In *CACM*, January 1997, page 15, Robert L. Glass reveals his shocking new
discovery that UNIX time, a 32-bit signed integer representing the number of
seconds after 1969 TAI, will overflow in mid-January 2038.  (``And even
sooner for smaller-word processors.'')

``This is one of those `surely I'm wrong' kinds of findings,'' Glass
writes. ``Surely the designers of Unix anticipated such a problem and have
provided for it.''

Harrrumph. A certain so-called operating system stores time as a 32-bit
unsigned integer representing the number of seconds after 1899. This will
overflow in February 2036. Apparently Glass doesn't realize that UNIX was
cleverly designed to keep on ticking for *more than a million minutes* after
that other system dies of tachyon exposure.

This is all very well known to UNIX programmers. (Proof: A quick search with
DejaNews reveals that there was a ``UNIX will outlive your pathetic OS''
thread on comp.unix.advocacy, one of the most technical UNIX newsgroups, a
few weeks ago. Q.E.D.)

---Dan

P.S. In all seriousness: I'm converting my data to 64-bit signed times,
stored big-endian in 8 bytes, followed by 8 bytes for nanoseconds and
attoseconds just in case. This won't last for more than a few hundred
billion years, but neither will the Sun, and in any case I plan to throw
a big programming party on 1 January 2000000001 to upgrade to 128 bits.


Re: More Y2K humor: Split the difference (Brader, RISKS-18.76)

Tony Lauck <tlauck@CERF.NET>
Fri, 17 Jan 1997 06:34:59 -0500
For as long as I can recall, the voter registration system in Wellesley,
Massachusetts has used a three-digit field for Date of Birth.  When I first
saw this, I was puzzled and figured that it was probably the result of some
elderly residents celebrating their 100th birthdays.

Why three digits instead of four?  Were they conserving holes in punch cards?

  Tony Lauck, P.O. Box 59, Warren, VT 05674
  tlauck@cerfnet.com    http://www.ultranet.com/~tlauck/

    [Maybe they were hanging Chad as a warlock,
    although might have better been in Salem.  PGN]


Re: More on fired contractor... (Horiuchi, RISKS-18.75)

Carlie Coats <xcc@hpcc.epa.gov>
Fri, 17 Jan 1997 08:15:39 -0500
In many contracting situations, it is *illegal* for the contracting agency
to be involved in detailed management.  On EPA contracts (with which I am
familiar), for example, the EPA management specifies *what* and *when* but
is forbidden to even suggest *who* or *how* -- that is left for the
contractor management to determine.

In such circumstances (sub-sub-contracts), the "who has been fired"
information will have to traverse at least 4 layers of bureaucracy (and more
probably 7-10, since in the EPA case it will go through at least 2 layers of
Washington bureaucracy between the prime contractor and local project
management, and maybe two more layers between local management and computer
operations (and computer operations and the computer-operations
contractor)).

Risk: It will take *weeks* to deal with the situation, not hours.

Carlie J. Coats, Jr., North Carolina Supercomputing Center, 3021 Cornwallis
Road, Research Triangle Park, N. C.  27709-2889 1-919-248-9241 coats@ncsc.org


Re: Taco Bell-issimo (RISKS-18.76)

Vincent Weaver <weave@Glue.umd.edu>
Fri, 17 Jan 1997 08:29:25 -0500 (EST)
Living in Maryland, I got the Taco Bell item on the local news.  What was
more interesting was what Taco Bell did upon discovering that somehow they
were losing money.  Apparently, instead of checking the receipts or asking
the clerk, they immediately suspected it was a hardware/software problem and
had technicians treat it as such.  Apparently, they caught the guy only
because he was bragging to co-workers about what he had done.  The risks
here are enormous.  They actually brought a computer professor from a nearby
college on the newscast to explain the risks.  [And something else... the
clerk had a history and a criminal record when he was hired.  Taco Bell
refused comment on that].

Vince Weaver  weave@glue.umd.edu


IBMmail flame on -- albeit out of character

RISKS List Owner <risko@csl.sri.com>
Mon, 20 Jan 97 7:52:22 PST
RISKS does not generally take potshots at the often miserable service
provided by some of your favorite (or least favorite) Internet service
providers (as well as wannabes who still don't provide decent Internet
service), although we have had a few messages in RISKS on this subject, and
on the pain that is caused -- particularly to list administrators.  This
time, my patience has run out.  For a very long time, I have been getting
bouncemail from "System Mailman" <usfmcsqc@ibmmail.com> on every issue of
RISKS, telling me that

  "Your note to SSTARKEY on FORD of [date/time] could not be delivered
  because SSTARKEY is not currently a valid userid on node FORD."

The bouncemail tells me absolutely nothing else to give me a clue.  On the
RISKS lists I maintain (at CSL) or know about (BITNET), there is no RISKS
subscriber named STARKEY and no node named FORD.  I suppose I could bother
all of the altruistic folks who are already providing redirection services
(.mil, .uk, .mit.edu, .xerox.com, .dec.com -- many thanks!), but that seems
unlikely to be productive, and, besides, I should not have to do that each
time something like this happens.  [Oh, yes, you guessed correctly; IBMmail
is not the only offender.]  So, I have sent e-mail to various addresses at
IBMmail -- including Postmaster, Action, Help, and "System Mailman"
<usfmcsqc@ibmmail.com> -- TO NO AVAIL.  So, a veil is now withdrawn, and I
hope that by my going public, someone else will be inspired to do something
useful -- such as one of the many IBMmail subscribers prodding an
administrator at IBMmail to modify their BARFmail facility, or someone who
knows STARKEY telling him/her to let me know what alias is being used, or
anything else that might help.  Not only do I *not* get a response from
IBMmail with some excuse such as perhaps that they are incompetent or
otherwise impaired, I also do not get a bounce that "System Mailman" could
not receive my message.  IBMmail administration seems to be a veritable
electronic black hole.

IBMmail flame off.  PGN

Incidentally, I'm hard-pressed to keep up with the backlog these days.  (I
just deleted, without reading, 15 pieces of what appeared to be unsolicited
advertisements in the RISKS directory, which came in over the weekend.  I
just hope that none of them was a well-meaning RISKS contribution!)

  I notice that AOL seems to have shot itself in the foot by going to
  flat-rate charges.  The 17 Jan 1997 media reports indicate AOL is now
  asking its customers not to use their services so much, because of the
  difficulties of other people gaining access.  Reportedly, many folks are
  threatening to sue because they cannot get the access they think they
  deserve -- and are paying for.


Re: Risks of miskeying e-mail addresses (Joseph, RISKS-18.76)

Darin Johnson <darin@connectnet1.connectnet.com>
17 Jan 1997 19:15:19 GMT
When I was in grad school, I once got a letter from a professor that berated
a fellow student for not attending seminars and how he'd better get his act
together if he wanted to keep working with that prof.  I could not
understand why I was "cc'd" on the letter, as it would have been
unprofessional to do so.

Looking closer at the e-mail, I figured out what had happened.  The
professor had typed the subject into the "To:" field, which was something
like "Please attend all ai symposiums in the future".  The only thing the
mail understood from that subject was that there was a mailing list called
"ai", which it promptly sent the letter to (even though it was busy giving
errors about the rest fo the subject).

The reply was short, "now that the whole department knows I'm lazy, can we
meet in private about this?".

Why does this happen?

   - Too easy to hit the final carriage return and then say oops.
   - The software (generic unix mail) failed to treat the entire
     e-mail as faulty.  If one of a group of instructions is faulty,
     the entire group should be invalidated.
   - Mail was sent to the back-end before the addresses were verified.
   - Aliases set up with the same name as common words, a longer name
     would have been harder to mistype.
   - Apparently there was no warning that there was no subject given,
     or it was ignored.

The risks?
   - Software systems not keeping up with society; thus a simple system
     for sending memos and ideas evolves into a full communications
     paradigm that is widely used, except it's the same old software
     with the same old assumptions.
   - And of course, using easy technology for something that should have
     been done the old-fashioned way.  A tendency to sit behind the desk
     and control the world from the console in front  of you.

The old rule applies - never say anything on usenet or e-mail that you
wouldn't mind being posted in the office lunchroom.  Chances are, it just
might end up there.


Re: Risks of miskeying e-mail addresses (Joseph, RISKS-18.76)

Niall Murphy <nmurphy@iol.ie>
Sat, 18 Jan 1997 10:14:13 GMT
The chances of mistyping an e-mail address and getting a valid one are far
higher than Gerard A. Joseph recently suggested. On Lotus CC:mail, which use
at work, as you type a name it searches for a match in a predefined list. I
am sure many other mail systems work in a similar fashion. In my case the
list includes the entire company of a few thousand users.

I have a long time friend in California, to whom I would say just about
anything. Because of distance/time difference e-mail is our main social
means of communication. His name is Michael. My boss, about whom I might
occasionally say things that I would not want him to hear (or read), also
has the name Michael. One day about five minutes after I had sent a message
to my long time friend, my boss shouted over the partition in the office -
"Hey Niall, I think you meant this mail for someone else." It took about 2
seconds to realise what had happened and 2 seconds to start sweating. I had
typed Michael, and got the first Michael alphabetically. I needed only one
more letter to make the name unique and then the return key made the
selection. I had pressed an R instead of an M. Event though the wrong
address was at the top of the message as I typed, I never noticed it.

Luckily the mail was a harmless one, but I was far more careful in future.

The risk of course is that with such a system, especially if it can be
customised to select only people to whom you regularly send e-mail (I do not
know enough about CC:mail to know if this can be done), then the chances
become quite high that the misdirected e-mail goes to someone you know. This
can easily be more embarrassing than having it go to a random person
somewhere in cyberspace.

        Niall Murphy


Irrelevant risks of miskeying e-mail addresses (Joseph, RISKS-18.76)

Lawrence H Smith <Lawrence.H.Smith@williams.edu>
Fri, 17 Jan 1997 11:22:34 -0500
While misaddressing provides trivial access to information in the e-mail
(the unintended recipient didn't go to any effort to obtain it), it's
irrelevant.

Far more relevant: "Nothing about the Internet" provides *any* privacy to
*any* e-mail content, whether delivered to a valid address or not.  Thus, you
should *never* commit "intensely private" (or embarrassing, or fiscal, etc.)
content to e-mail. A stamped, sealed paper mail document (or a telephone
connection) is far more secure & reliable.

There's also no guarantee that a message sent out actually arrives, nor that
you'll hear about it if it doesn't. It is *often* the case that mail is
looked at only by the addressee, mail sent to a valid address arrives there,
and you get a bounce message for invalid addresses, but there are no
"guarantees" on *any* of this. The system works well enough most of the time
that naive users perceive it as "like paper mail, only faster and cheaper" -
a perception which is deeply flawed.

Lawrence H Smith, Instructional Technology Specialist, Office for
Information Technology Williams College  413-597-3073 lsmith@williams.edu


Chuq spoofing Spaf, and the archives

Adam Shostack <adam@homeport.org>
Fri, 17 Jan 1997 12:54:07 -0500 (EST)
Spaf's follow up was in 6.54, not 18.54 as noted by our overworked moderator.

  [Yes, Thanks.  I fat-fingered it by force of habit -- 18 is sort of an
  automatic number for me in the RISKS context these days, and it was
  getting late.  As Yogi Berra once <supposedly> said, it gets late early.
  I caught the error as soon as I looked at the hardcopy.  It is now fixed
  it in ftp.sri.com and catless.ncl.ac.uk archive copies, and was on the
  csl.sri.com website -- where only the most recent issue is available.  PGN]


Privacy Digests

"Peter G. Neumann" <neumann@csl.sri.com>
22 Jan 1996
Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems.  RISKS will continue to carry general discussions in which
risks to privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein, with some support from the
  ACM Committee on Computers and Public Policy.  He manages it as a rather
  selectively moderated digest, somewhat akin to RISKS; it spans the full
  range of both technological and non-technological privacy-related issues
  (with an emphasis on the former).  For information regarding the PRIVACY
  Forum, please send the exact line:

     information privacy

  as the first text in the BODY of a message to:

     privacy-request@vortex.com

  You will receive a response from an automated listserv system.  To submit
  contributions, send to "privacy@vortex.com".

  Information and materials relating to the PRIVACY Forum may also be
  obtained from the PRIVACY Forum Archive via ftp to "ftp.vortex.com",
  gopher at "gopher.vortex.com", and World Wide Web via:
  "http://www.vortex.com".  Full keyword searching of the PRIVACY
  Forum Archive is available through the World Wide Web access address.

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
  run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
  comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
  forum, and was established to provide a forum for discussion on the
  effect of technology on privacy.  All too often technology is way ahead of
  the law and society as it presents us with new devices and applications.
  Technology can enhance and detract from privacy.  Submissions should go to
  comp-privacy@uwm.edu and administrative requests to
  comp-privacy-request@uwm.edu.

There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places.  If you are very
short of time and can scan only one, you might want to try the former.  If
you are interested in ongoing discussions, try the latter.  Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.
                                                  PGN


The SEI Conference on Risk Management - Preliminary Program

Carol Biesecker <cb@sei.cmu.edu>
20 Jan 1997 19:43:44 GMT
The SEI Conference on Risk Management - Preliminary Program
Managing Uncertainty in a Changing World.
7-9 April 1997
The Cavalier Hotel
Virginia Beach, Virginia

The SEI Conference on Risk Management provides a unique forum for exchanging
ideas and experiences with experts and professionals who practice or study
acquisition and risk management. It is a tremendous opportunity for you to
increase your awareness and to advance your knowledge and skills by exposure
to the latest methods, tools, techniques, and some of the best practices in
the field of system development and acquisitions.

The conference is geared toward government, industry, and academic managers,
practitioners, change agents, and researchers.  Managers will learn how to
improve their ability to make informed decisions and to gain better control
of their project's cost, schedule, and technical content.  Practitioners
will increase both their awareness of risks and their ability and skills to
avoid or mitigate them. Development and acquisition professionals will gain
insight from the experiences of leading experts and professionals, learn
about the latest developments and technological issues, and learn how to
manage uncertainty in a changing world.

If you haven't attended an SEI Conference on Risk Management in the past, you
may want to attend the 1997 conference.  Here's why:

* Recent Congressional action as well as DoD policy emphasizes the requirement
  to improve acquisition practices and management of risk.

* The Fiscal Year 1996 Defense Authorization Act directs that "...the process
  for acquisition of information technology is a simplified, clear, and
  understandable process that specifically addresses the management of risk,
  incremental acquisitions, and the need to incorporate commercial information
  technology in a timely manner."

* DoD Directive 5000.1 "Defense Acquisition" (March 15, 1996) provides for
  "...a streamlined management structure and event-driven management process
  that emphasizes risk management and affordability and that explicitly links
  milestone decisions to demonstrated accomplishments."

For registration, contact registration@sei.cmu.edu.
For additional information about the conference, contact

SEI Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
  Phone, Voice Mail, and On-Demand FAX 412 / 268-5800
  E-mail customer-relations@sei.cmu.edu
  World Wide Web http://www.sei.cmu.edu
  or specific questions to 412 / 268-7388

[Abridged for RISKS.]

Please report problems with the web pages to the maintainer

Top