Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
From the October 18, 1995 Vancouver Sun
"Man seeks to clear his name after police error"
A Tsawwassen whose photo was wrongly placed on a "Crimestoppers" episode linking him to bank-machine fraud says he wants his name cleared and those responsible to pay. ... Sonny Walker, 19, withdrew money from a Richmond Savings Credit Union bank machine on Dec 25, 1994. On the same day, someone used a stolen card at the same machine. Because the clock in the video camera filming bank customers indicated Walker withdrew his money at the same time as the fraud occurred, the bank forwarded his photo to Richmond RCMP. But the video-camera clock was wrong. Rachael MacKenzie, manager of public relations for Richmond Savings admitted Thursday. It was out by about one hour. ... When the [Crimestoppers] episode first ran, Walker heard about it from friends. ... Walker and his mother went to the police right away. Even though he protested his innocence and insisted a mistake had been made, Walker was interrogated for 45 minutes. ...
The Crimestoppers episode ran throughout the summer. Walker continued to protest his innocence to police, but said he got nowhere. ... Finally, in September, Colleen [his mother] called the bank to complain. MacKenzie said the call was the first she heard of the Crimestoppers episode, and she immediately had the bank check its records. "Within 2 or 3 days, we knew the timing was wrong," she said. "We made a mistake on the evidence. Thee is no question we feel horrible about this."
MacKenzie immediately sent a letter to police notifying them of the error and criticizing police behaviour. "We are concerned that you passed this photo on to Crimestoppers with no prior notice to us and that you idn't attempt to re-contact us after your initial discussions with Sonny's mother," MacKenzie said in her letter. But two weeks later, Walker's sister saw an hour-long Crimestoppers special in which her brother's face was displayed as part of the fraud episode, with an addendum stating that the suspect and his family deny the allegations. ...
Crimestoppers' police liason officer Dave Baker refused to comment except to say there was a "screw-up, but I don't know whose." ...
Risks? The usual dose of human stupidity, and as BC Privacy's commissioner put it: "Our assumption is that technology can't make mistakes, but once again we are shown it does make mistakes."
Sarah Holland sholland@cis.compuserve.comThis item is bouncing around Apple lately. Apparently, the VP of Compaq considers it too much of a RISK to make an important presentation on a PC. Mike Crawford crawford@scruznet.com http://www.scruznet.com/~crawford
From Guy Kawasaki's MacWay mailing list... I wonder how many closet Macintosh users are out there!
From the "Feedback" column in this week's "New Scientist":
FEEDBACK was present when the International Data Corporation held its annual European Information Technology Forum in Paris recently. Top executives from top computer companies Lotus, Oracle, Hewlett-Packard, IBM and Compaq all gave speeches. So did Bill Gates of Microsoft, who was in France to launch Windows 95.
Needless to say all the speakers relied on electronic "slides", stored in a computer and projected by a video system. The picture quality was fine, but several speakers had a lot of trouble controlling the computer. Perhaps they do not often use the equipment they sell to the public.
Whatever the reason, their slides kept refusing to change, or changed too soon. When Andreas Barth, senior vice-president of Compaq, took the stand he announced that he was not going to risk the same embarrassment.
So he was using an Apple Mac to show his slides.
It took a moment or two to appreciate the full significance of Barth's remark. The vice-president of a huge company that has built its success on selling PCs that run Windows was admitting to a top industry seminar that he dare not use a Windows PC for his presentation, and was using the rival Mac system instead.
Compaq's Mac presentation progressed without a hitch. But Feedback was more than a little disappointed to see that Bill Gates had already left the hall. So there was no chance to see the look on his face.
One is left wondering how many of the other presenters secretly identify with Barth and, in the privacy of their own homes, use Apple Macs instead of PCs.
Newsgroups: alt.folklore.computers,alt.folklore.urban
[Via Mark Brader <msb@sq.com>]
Rob J. Nauta (rob@redwood.nl) wrote: : Anyway, there is an urban legend about a professor who wrote his thesis
: about the earth's core in a file called 'core'. In the weekend however
: a coreseeker wiped out his file. And, the clever person who wrote the
: backup script had added a filter so that core files weren't backed up ...
This was definitely not a legend at my school, UC Santa Cruz. There are eight "colleges" at UCSC, and each has a required course that all freshman have to take, which supposedly makes up the "core" of the college curriculum. Thus, it was known as the "core course." At the time (12 years ago) about 50% of campus CPU cycles were used to run nroff for writing papers (the other 50% were for playing rogue.) Less imaginative freshman would use "core" as the filename for their beloved papers, with occasional unfortunate results.
Ross Oliver reo@netcom.comTHERE IS NO SECURITY ON THE INTERNET (see RFC 1281 if you do not believe me). The Internet addresses one thing and one thing only: delivering the mail (packets). It is solidly on the A of Availability.
Consequently, there is no "flaw" in the Internet, rather there may be a flaw in the design of a module which makes use of the Internet, or there may be a flaw in people's expectation of the Internet, but not the net itself, it does its job very well.
It is probably best to think of the Internet as "the world's biggest party line" (if that does not translate well outside the US, I apologise but have no idea what other terms are common).
Unless the user takes steps to ensure the security of a message/file/etc., to authenticate that something actually came from where it appears to have, and that it does not contain anything you might not want to receive, then he/she/it/other has no-one to blame than themselves and certainly not the 'net (have noticed a certain tendency of the lemmings to be wont to blame *anyone* else, mob rule/mob IQ & all that).
When I examine a virus my favourite tool is DEBUG, when reading a message that came from "somewhere", I use Vern Buerg's LIST. Both have the endearing quality of assuming nothing for me.
Misplaced trust is really is not a prerogative of digital usage but "to really screw things up takes a computer." I suspect that we are rapidly reaching a point where we are going to have to reassess trust in objects for which no one is accountable.
In 1969, when the first Internet connections were made, the government relied on strong encryption not only for confidentiality but also for accountability, strong encryption which was the responsibility of the sites. I suspect that the Internet is rapidly returning to that paradigm.
PadgettOn page 24 of the October 16, 1995, issue of PC Week, an article ("Mark your target--objects in the field) describes how the U.S. Army with Magnavox Electronic Systems is designing an AFATDS (automated field artillery tactical data system) which can use battlefield intelligence data in conjunction with programmed standard operating procedures to direct artillery file onto enemy forces in a matter of seconds.
The development of an AFATDS should come as no surprise to anyone familiar with the military. The U.S. armed forces have historically relied upon fire support such as artillery to reduce enemy forces and so reduce the number of American casualties. In addition, the military is downsizing and so has to "do more with less". By automating the control of artillery fire, the military is hoping to literally get "more of a bang for the bucks". A well-designed functioning AFATDS has the possibility of being a critical "force multiplier" which could deter "enemy" forces from even tangling with U.S. forces.
However, as readers of this digest are aware, there are two main dangers from automating such a process to the point where there is little room or time for human control of the system. First, there is the problem of intentional sabotage. I would not put it past the capabilities of an "enlisted hacker" to spoof the AFATDS into mistaking the Officer's Club as a concentration of enemy troops. AFATDS could give a "fragger" the chance to do a lot more damage than he/she could do just using a grenade or gun.
Second, there are the problems of unexpected software bugs which could misdirect fire or even abend the entire system. Given that the consequences of either misdirected artillery barrages or losing artillery support altogether could literally be a matter of life or death, it would be interesting to find out how Magnavox plans to deal with these problems.
This is more than just a theoretical topic since it is possible that AFATDS could be implemented as soon as next year according to the article.
Dave GrafRecently I ordered a copy of a book via *The Daily Telegraph*. You collected three tokens, sent a small cheque for the postage, and waited the customary 28 days or so before the book arrived.
I came home one day to find five parcels:
Of course if the mailorder computer system has done that to more than myself, the risk is obvious. The company will go bust. I hope I don't have their software or operations procedures anywhere near anything critical I use. [They are indeed in your Doghouse. PGN]
RISKS-17.40 quoted *The Boston Globe* describing a high-level executive at a Manhattan health company accidentally e-mailing an erotic video of herself to 400 coworkers. While the story makes for interesting gossip, with
the lack
of details I have to wonder if it is more of a male fantasy embodied as urban myth. 1) Has anyone heard of such a neat video e-mail system being commercially available and in common enough use that a "health company" would be using it for company-wide
communications? 2) If there are e-mail systems with video capability, are they so cheap, small and convenient that people have cameras on their laptops as well as on their office desktop machines? 3) Even if there were such systems, has anyone devised
video compression algorithms so good that it would be practical to send video e-mail over a modem from one's laptop in the hotel? Without some corroboration, I think that the body of evidence does not support the story as being the bare truth.
I'm going in for a top-secret clearance, and was talking to the person who's responsible for sending off the paperwork. She's excited: seems that you can now submit the forms over the Internet, thus saving the need to send stacks of paper. You obviously don't sign the form (no digital signature capability); at some point in the future they said I'll be asked to sign a hardcopy.
I suggested that it made me uncomfortable to have all that personal information being sent over a public net without any form of protection, so they agreed to submit mine on paper.
The risks of sending any sort of confidential information over the net have been described to death, so there's nothing new. It just amazes me that the U.S. government office responsible for handing out clearances could be so unaware of the risks as to allow it. Further, as holding a clearance is generally something that's not supposed to be discussed except for those with a need to know, it seems odd that they would be willing to accept the information leading to a clearance over a public network.
P.S. For those who haven't had the pleasure of applying for a clearance, among the information they ask for is where you've lived, worked, been married to, travelled to; also any treatment for psychiatric conditions, use of drugs, criminal record, organizational memberships, communist party affiliation, etc. So there's plenty there that some people might not want posted on bathroom walls.
That's right. It's happened again. That's six times in a month. This time, however, it happened during a visit of the National Air Traffic Controllers Association and U.S. Rep. Frank Mascara, a member of the House Committee on Transportation and Infrastructure.
This time the FAA blamed a three-minute commercial power failure, and said the backup generator kicked in within 20 seconds. During the outage, controllers maintained radio communications. The FAA said weather was clear and no flights were delayed. There were high winds in the area. Since the radar system was installed a year and a half ago, there have been at least nine recorded outages. Because of the frequency of the outages, the FAA is considering UPS. (A few travellers may be considering sending themselves by UPS as well - AT).
Alan Tignanelli[UPS and DOWNS are not good for ATC systems, but they are OK for airplanes (as long as the DOWNS can be followed by more UPS). Oh, for non-US readers, in Alan's context, the first UPS denotes Uninterrupted Power Supplies, and the second denotes United Parcel Service. PGN]
Three-minute outage blanks approach radar at McCarran
* A union official contends equipment at Las Vegas' airport is outdated, but an air traffic official disagrees.
by Keith Rogers, *Las Vegas Review-Journal*, 19 Oct 1995
Three air traffic controllers who were tracking aircraft approaching Las Vegas experienced a 3 1/2-minute radar outage Tuesday night, raising concerns with their union that it's time for new equipment. But Paul Strybing, assistant air traffic manager at the Las Vegas Terminal Radar Approach Control, said, "At the time this took place, we had five other radar displays that continued to operate fully. At no time was there any loss or disorientation of traffic."
In a statement Wednesday, Daniel Maddaus, president of the National Air Traffic Controllers Association Local-L30, the union that represents controllers for the Terminal Radar Approach Control, said, "This outage lasted long enough for an average air carrier to travel about nine to 10 miles unseen by air traffic control." The Las Vegas approach control handles aircraft up to an altitude of 17,000 feet within a 40-mile radius of McCarran International Airport. "The likelihood of a midair collision zooms," Maddaus said [...]. "You have aircraft pointed at each other with minimal separation."
Three of the five controllers working that shift were affected by the outage and were able to switch to other radar screens, Maddaus said, but, "the problem I have is the equipment is old and prone to more failures."
[...] "The flying public pays for the most complex air traffic control
system in the world. What they are getting is a very large bureaucracy and 1950s and '60s technology."
Strybing said the radar system is 1970s technology "and continues to work extremely well." "It's an extremely reliable system that has the best track record of any system configuration of its kind in the world. There are redundancies and backups." The outage at 10:02 p.m. Tuesday to what is called the Multiplex Display Buffer Memory lasted 3 minutes, 21 seconds and caused three radar screens to go blank, Strybing said. [...]
Marketry [See RISKS-17.39] said this week that it was dropping plans to sell data gather from the Internet. While some company (anyone know who?) is still collecting the information, Marketry president Norm Swent, announced Marketry's "resignation as manager of the e-mail Internet Interest Selector list."
Who says a little e-mail can't make a difference? ;->
Marc Rotenberg, EPIC rotenberg@epic.org>I always felt that parity checking was not enough - I want ECC memory.
Of course, if you have ECC (error-correcting) memory alone, you have the same problem, unless you ALSO have error detection.
This is an old RISK. For a 20-year-old warning, see E.W.Dijkstra, "On a Warning from E.A.Hauck", EWD 525 (reprinted in "Selected Writings on Computing", Springer-Verlag, 1982).
In RISKS-17.26, I reported that Northwest accidentally erased me from their records, I showed a letter I sent to the president of the company, and I promised to keep RISKS updated.
Well, there were two interesting developments.
First, an "aide to the president" called within a couple of days, and said that when another Daniel Frankowski sent in a change of address, they applied it to my account instead. Northwest rectified the error (as far as I can tell), satisfying requests (2)-(4) of my original letter, but did not satisfy my request for
I am probably going to cave on this, because I do not have the desire to spend the time on it.
What this experience tells me is that if a customer service rep tells you that you are out of line (as one did me), just go yell to someone else. Your service does depend on the person serving you, not just the company. This is probably obvious to RISKS readers.
Bob_Frankston@frankston.com writes:
> I was surprised to see TV news stories and front page articles giving
> instructions on how to derail a train from which bolts to remove to how to
> defeat the electronic system checks.
Actually, the information is far from secret. Any bright 13-year old with an interest in trains could tell you how to do it. Anyone with any sense of mechanical aptitude can just *look* at the rails and see how they go together. The "hard" part is fooling the block signals. And that's described in just about any article on how they work. For that matter, you can *watch* railroad employees test crossing signals and the like by placing a set of jumper cables between the rails.
So it's pretty obvious that both connectivity along the rails, and *between* the rails are checked. From there, it's but a moment of thought to any of the *many* ways of getting around them.
Leonard Erickson leonard@qiclab.scn.rain.comDate: Tue, 17 Oct 1995 10:32:22 -0700 From: Tracy Pettit <tnpetti@nppdnet.com> Subject: Re: The Johnson Bug (RISKS-17.39)
[....] it sounds a lot like the stories about poisonous snakes wrapped in imported carpets or burglary victims finding their pet Doberman choking on severed fingers. I believe there have been a book or books published on these types of stories [....]
These stories are more properly called urban legends. There are four well-written books on them by Jan Harold Brunvand, a professor at (I think) the University of Utah:
The Choking Doberman
The Mexican Pet
Curses! Broiled Again!
The Baby Train
(There are a number of other books by other authors as well, but I do not have a list.) They should be available at your local bookstore.
Aside from being an entertaining read, the books really show why it can be dangerous to accept things at face value without checking the facts. I think most people would be surprised by how many of these stories they've heard, or even repeated as true... I was.
--DaveIn RISKS-17.40, Sean Reifschneider notes that some modern disk drivers intended for portables have extensive error management built in, and asks "but how does it report the problems."
All SCSI devices can implement an extensive error logging command protocol defined in the ANSI SCSI Standard (ANSI X3-131-1994), including commands to initiate self-test sequences and commands to report errors. Presumably, the device's manufacturer would provide a vendor-specific utility to monitor the device. In the Macintosh community, there are several very competent third-party disk driver vendors who are certainly technically capable of writing this utility.
My experience, however, is that modern SCSI disks are extremely reliable, and there isn't much cost/benefit in doing this: remember, the personal computer user community does not — and should and should not — need to know about technical details within their computer systems. Here, a comparison with modern computer-infested automobile control systems seems relevant: how often do you want to examine the engine logs?
Martin Minow minow@apple.comI read Prentiss Riddle's comments on the risks of Java with considerable interest. This seems to me to be one example of a larger problem that seems worthy of considerable discussion in Risks. The Microsoft Word viruses that have come to light recently provide another example. (Simply stated, a Word document can contain a "macro" that executes when the document is opened. Someone finally realized that this macro can do something nasty to the unsuspecting recipient of the document.)
The more general concept that many folks are propounding is that we will regularly exchange "objects" containing both data and code by mechanisms such the World Wide Web and various kinds of object request brokers. The broader supposition seems to be that the concepts of applications and data files as we know them will disappear.
I've been viewing this with growing alarm for some time. It seems to me that if all this does happen, it will be possible to turn all sorts of nasty things loose. It also seems that scanning for nasties is not going to be able to catch them. Monitoring various kinds of system calls might have a better chance but this seems inadequate as well as cumbersome.
Am I missing something? Does anyone have some good solutions?
Charlie WertzRisks readers might be interested in knowing that the NSA National Cryptological Museum now has a web page at:
<http://www.nsa.gov:8080/museum/>
It includes a brief tour with pictures of some of the exhibits.
Adrian adrianh@cogs.susx.ac.uk +44 (0)1273 678367 http://www.cogs.susx.ac.uk/users/adrianh/There will be a six-paper minitrack on Risks in End User Computing at the Twenty-Ninth Hawaii International Conference on System Sciences in January, 1996. Most of the papers will focus on spreadsheet risks and spreadsheet
errors.
Three of the papers are available online. If you are interested, please use the following URL.
http://www.cba.hawaii.edu/panko/h6reuc.htm
You can also access these papers through links in my home page, which is listed below.
The papers add to past findings. Wherever quantitative errors have been studied in spreadsheeting, they have been found in disturbingly high numbers. Galletta et al.'s paper extends this to the debugging phase. In addition, controls on spreadsheeting and end user computing are at best informal.
Aloha, RayWorld Wide Web: http://www.cba.hawaii.edu/panko
Prof. Raymond R. Panko, Decision Sci., Coll. of Business Admin., U of Hawaii
2404 Maile Way, Honolulu, HI 96822 (808) 956-5049 Fax: (808) 956-9889
Please report problems with the web pages to the maintainer