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…
RISKS will be more or less off the air from now until July 24. I will probably not be able to answer many of your queries and requests during that period even when I am on-line. Continuations of recent ongoing discussions are likely to cease as of this issue. However, please send in all interesting NEW items that you encounter.
For our 10th anniversary RISKS issue on 1 August 1995, I would be very happy if a few of you would submit (by 24 July) concise and well-reasoned think-pieces on what we might have learned in the past 10 years, with respect to some aspect of the RISKS experience. Have things improved? Or are we collectively treading water — or being washed out to sea? What is missing? Are the real problems technological or otherwise? (The best reflective contributions might even wind up as Inside Risks columns in the CACM!)
I hope you all have a pleasant summer.PGN
That was the headline on a piece in *The Times* (London) on 15 June 1995 about a Barclays Bank computer system that deals with loans and mortgages to bank staff. It was running a new accounting system, and it refused to generate monthly repayments for more than 100 staff named Fiona. Nobody else was affected, including a Ffyona. Numerous Fionas were sufficiently honest to contact the bank and ask why their repayments hadn't been deducted. It isn't clear how long the lucky Fionas would have had their repayment holidays if some of them hadn't owned up. The bank is adamant no hacking was involved. A spokeswoman blamed `a blip' and added, `Our systems people say that they knew how to solve the problem even if they could not explain what precisely had caused it.'Peter Ilieve email@example.com
The Royal Majesty is the cruise ship that ran aground off Nantucket. There is a good article in *The Boston Globe* 19 Jun 1995 by David L Chandler entitled "Embarrassing lessons for navigators". It is a good "risks style" article that covers various issues including the question of whether the GPS system indeed failed and was 17 miles off. It discusses issues of the user interface — is navigation information presented in such a way as to actually be usable during hectic periods? It brings up question of whether it is safe to turn off Loran, the Valdez accident, and other pertinent issues.
Nothing particularly new for Risks readers, but it is worthwhile to note reasonable articles in the newspapers.
------- Forwarded Message
*** Subject: TROJAN ALERT: PKZ300B.EXE / PKZ300B.ZIP ***
**************************** Important Notice *************************
Some joker out there is distributing a file called PKZ300B.EXE and PKZ300B.ZIP. This is NOT a version of PKZIP and will try to erase your harddrive if you use it. The most recent version is 2.04G. Please tell all your friends and favorite BBS stops about this hack.
Product Support PKWARE, Inc.
As reported in the June 16 New York Times, further investigation of the 5 Jun 1995 NY subway crash (which killed the motorman and injured 54 people) indicates the distance between signals is shorter than the stopping distance of a modern train. Speculation right after the accident had focused on a possible emergency brake failure. However, even with the brake engaged, tests showed it takes approximately 360ft for the train to stop. Unfortunately, the rear of the forward train was only 288ft from the signal. It now appears that the motorman ran the red signal, which tripped the emergency brake and slowed the train from about 32mph (the maximum speed after climbing the hill leading to the crash area) to 14-18mph at the time of impact.
The signal spacing was set in 1918 when trains were shorter, lighter, and slower than modern trains. The Transit Authority has been upgrading the trains without upgrading the control system. A familiar RISK.
The immediate response has been to limit speeds on the section of track where the accident occurred. When a TA official was asked if speeds will be reduced in other areas, the official said "we don't know where the potential trouble spots are." I guess we're just going to wait for more accidents to find the areas that need fixing. Another familiar RISK.Mark Stalzer, firstname.lastname@example.org
One of the risks that continues to haunt me from that article (and apparently others as well since my mother mentioned it to me when we discussed the article) is this:
(The people in charge of repairs to the building had installed strain gauges connected by wire to readouts in the main office.)
One time, the readings went off the chart, then stopped. This provoked more bafflement than fear, since it seemed unlikely that a hurricane raging on Lexington and Fifty-third Street would go otherwise unnoticed at Forty-sixth and Park. The cause proved to be straightforward enough: When the instrumentation experts from California installed their strain gauges, they had neglected to hire union electricians. `Someone heard about it,' LeMessurier [the building designer] says, `went up there in the middle of the night, and snipped all the wires.'Chuck Weinstock
I remember once reading a paper with a synopsis something like this:
This paper is in two parts.
In Part 1, we prove that it is impossible to play a fair game of telephone poker.
In Part 2, we give an algorithm for playing a fair game of telephone poker.
The apparent paradox, of course, was that the algorithm in Part 2 was actually unfair with a probability that could be made as small as desired by making the crypto keys long enough.
I wish I remember the title or author of the paper. Anyway, such things leave me with the distinct impression that Internet gambling is no less feasible than any other kind of electronic commerce.Andrew Koenig email@example.com
[For the short-term future, we will see many small-scale efforts such as this one, whether or not they are soundly based. In the long-term, we still need a secure infrastructure and trusted servers and trustworthy individuals and more laws (and lawyers) to give it a real semblance of "fair". (We might refer to this as "secure infostructure".) PGN]
It occurred to me that the stories in comp.risks are often sensationalistic enough to warrant widespread media coverage. In fact, a good chunk of stuff posted here is drawn from the media, with commentary added.
One risk commonly mentioned here is that "the public" or "the media" haven't got enough understanding of computer risks, and that we're all going to suffer as a result — recently there's been discussion of lawyers who don't understand computers, etc.
Has anyone tried convincing some television producers to add a computer risk segment to their news programs? There's easily enough material that's interesting enough that's already part of their program — to make it a proper segment all that would be required is the addition of a brief editorial highlighting for the public the general nature of the particular risk. I think it would be interesting enough to sell (but then as a regular reader of comp.risks I'm biased :)
I don't have the background or the experience or the connections or anything else to try and make something like this actually happen, but I'm sure that somewhere out there in RISKS land, someone does...
Imagine the benefits of having computer risks dealt with sensibly on CNN. Here in Canada the late night news just ran an extensive segment on the risks of cellular phones and radios interacting with medical equipment, so it's not like the media is opposed to the idea. What with all the hype about the Internet these days, I think there's a major window of opportunity...Justin firstname.lastname@example.org
CALL FOR PAPERS
The Internet Society Symposium on Network and Distributed System Security
February 22-23, 1996
San Diego Princess Resort, San Diego, California
GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following:
David Balenson, Trusted Information Systems
Clifford Neuman, USC Information Sciences Institute
Donna Leggett, Internet Society
SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist.
Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page.
Deadline for paper submission: August 14, 1995
Notification sent to authors by: October 16, 1995
Deadline for camera-ready copy: November 13, 1995
Submissions must be received by 14 August 1995. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 14 August. If electronic submission is difficult, submissions should be sent via postal mail.
All submissions and program related correspondence (only) should be directed to the program chair:Clifford Neuman
Dates, final call for papers, advance program, and registration information will be made available at the URL:
Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 16 October 1995. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 13 November 1995. [Program committee and a few others deleted. PGN]
I, too, am glad to see that Multics is still used. It is a system that was far ahead of its time in many respects.
In MTS (the Michigan Terminal System), a system contemporaneous with Multics which is also still in use, we solved the problem of the operators entering a bad time in a slightly different way. During initialization, the system compares the current time with the time in the last billing record recorded. If the current time is earlier or too much later (more than 12 hours, unless the day is Sunday in which case 18 hours is ok) it complains and asks the operators to confirm that the time is ok. This has several advantages: it doesn't use hard-coded dates, it is a more precise check, and it never makes the system unusable. Of course this has become less important as modern machines maintain the time of day even when not running and the clock rarely needs to be set at all.Mike Alexander, Univ. of Michigan Mike.Alexander@umich.edu MAlexander@aol.com
Last fall I worked on the 2Market home shopping CD. This is a CDROM catalog with pictures of products from many popular mail-order catalogs, with QuickTime movies of TV commercials, and sound clips of record albums.
One of the features of 2Market is that items go on sale. Of course the sales have to be prepared in advance, and the user will only get it right if their clock is set.
Knowing my own habit of living in the year 1904, the Macintosh beginning of history (for no reason I can really fathom), I convinced the designers to let me put in a warning that your clock is off. The warning is placed in the message box that is normally used to inform the users that items are on sale. Any date that is before we shipped the CD, or after (I think) a year after the CD shipped warns the user to reset their clock. Shorter times afterwards give the user the number to order the next CD.
Let's hope they always remember to update the code when they ship new versions... I'm not with Medior anymore to remind them.Mike Crawford Mike_Crawford@QuickMail.Apple.Com
The following recent news release from the Wireless Institute of Australia suggests that some people are getting very nervous, following the Prodigy defamation case in the USA:
The name of the gateway is just one of those ironic little twists. :-)
PACKET GATEWAY DEMANDS STAT. DEC. FROM AMATEURS
The Launceston Institute of TAFE [Technical and Further Education] in northern Tasmania, which runs an amateur radio packet-to-Internet gateway known under the acronym of LITGATE, is requiring radio amateur users to file a statutory declaration with them.
The relevant wording of the declaration says: "That I agree to take full personal responsibility for any information or data which is sent from my station, or from a station operating under my callsign.
"That I will not hold the Launceston Institute of TAFE responsible for the content of data received through the LITGATE, whether such data is of an offensive, improper, illegal or other unacceptable nature."
Basically, what the Launceston TAFE requires is that radio amateurs wanting access to LITGATE must say they will accept responsibility for all messages under their callsign, whether pirated or not, and agree they will absolve the Launceston TAFE from responsibility for any material placed on its system.
Whether such a statutory declaration is legally binding would be a matter of conjecture. (Thanks to Victorian Division President, Jim Linton VK3PC, for details on that item).
I hope somebody can convince these people of the stupidity of their decision, as they clearly don't understand some of the technical issues. For those not involved in Amateur Radio, we "hams" operate our own computer network, using our radios as the physical layer.
In some places, known as "wormholes" or "gateways", operators transport message over long distances via Internet, replacing the slower chain of short-range VHF or UHF radio links. The traffic leaves the net again at some remote point and rejoins the Amateur packet radio network.
It's important to realise that the wormholes and Internet are merely being used as a medium for conveying this traffic from one part of the Amateur packet network to another; the Amateur traffic is effectively "quarantined" from other Internet traffic because Amateur Radio licence conditions forbid non-Amateurs (e.g. other Internet users) from conveying message by Amateur Radio. So, it would be very hard to argue that LIT is a "publisher" of any Amateur packet radio traffic passing through its gateway.
I might add that it is a trivial matter to "pirate" another Radio Amateur's callsign.-Richard Murnane (Amateur station VK2SKY)
>hatred against Prodigy, which appears to be practicing the most control of
>any provider (though still nothing like a newspaper) has people cheering
I think the risk is overstated, because (and only because) the underscored
assertion is contradicted by Prodigy's own words:
> "We make no apology for pursuing a value
> system that reflects the culture of the
> millions of American families we aspire to
> serve. Certainly no responsible newspaper
> does less when it carries the type of
> advertising it published, the letters it
> prints, the degree of nudity and unsupported
> gossip its editors tolerate."
If Prodigy chooses to back off on their editorial control to, say (and the decision does say), Compuserve's or AOL's level, they won't be liable for the content they carry. Until then, they're providing a specific and valuable — no irony intended, for any who might think newspapers aren't valuable — service, and can be held responsible to the standards of that service.Jim Hill email@example.com
I see your point, and hope you are right that the ruling will not have the broad effect I fear (though I have already heard it cited in exactly the manner I have described in a NPR report on another cyber-case)
However, it is worth noting that your exhibit does not prove that Prodigy wanted to be a newspaper. It merely shows that Prodigy cited as an example of controlling content, newspapers. They could have cited restaurants that control dress codes, that would not have made them a restaurant. To say, when one is tired, that even horses get tired if you work them too long, does not make one a horse.
To say that you have some rights, similar to one entity does not make you that entitity. This is the kind of square pegs in round hole legal thinking that I think harms the emerging character of the net.Bob Morrell firstname.lastname@example.org
"Certainly no responsible newspaper does less" in terms of controlling content — "the letters it prints" — says to me that they are *at least* as responsible as any newspaper.
It's not just an example, it's an explicitly stated minimum standard. One doesn't have to be a prodigy (sorry ;-) to infer liability.
I do agree with you that "rabid" is on target for too much of the anti-Prodigy froth.
I will also say I was wrong to suggest earlier that moderated groups and lists should be held to that standard. Only the ones that claim it for themselves.Jim Hill email@example.com
Please report problems with the web pages to the maintainer