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…
In an article in this morning's New York Times, John Markoff discusses the US
DoD's "quietly proposing strict new controls on the export of inexpensive but
powerful computer workstations that can have military uses." [See my Note,
below.] The article highlights a DoD meeting yesterday with industry
executives, at which the DoD expressed concerns "about cheap high-speed
computers being diverted to the IRA and the Cambodian Resistance Movement as
well as traditional worries that such computers might be used in anti-submarine
warfare applications" — according to one executive. The proposed "Draconian"
controls would require hardware and software changes that would restrict the
applications that could run on inexpensive engineering workstations, audit all
programs run on the machines, and limit their ability to connect to computer
networks. These restrictions "appear partly to reverse the effort by the
Coordinating Committee for Multilateral Export Controls, known as COCOM, to
ease the limits on many high-technology goods, including computers."
[Note: Yeah, sure. ALL computers can have military uses. But there
must also be some folks who are most scared by the PEACEFUL uses! PGN]
I have been following this debate with interest and amusement. Why? Because I work in the Systems Group of the Technical Publications arm of a well known photocopier manufacturer (look at the email address!). We spend a large part of our time manipulating character codes between the various hosts we use. A large part of our work is machine aided translation, and it is essential that we can handle (effectively) any character that anyone, anywhere might wish to use. We have actually standardised on the Xerox Character Code Standard (XCCS) o0, partly because it's our own standard, and partly because (so far as I know) it's the only comprehensive character set standard. We await the Unicode standard with some interest. So what are the RISKS? - ASCII is woefully inadequate. I suppose it was barely adequate in the days of punch cards, but today it is unacceptable. Increasingly, European consumers demand that their consumer products "talk" to them in their language. ASCII can't even do plain accented characters, much less an 'L' ogonek! In several European countries it is legally mandated that products must deal with the host language correctly. - Manufacturers extensions to ASCII are even worse, because they're all different, still inadequate and sometimes wrong. Further, they generally steal "rarely used" character codes from the standard set, for example the open and close square bracket are generally re-used for the AE and A-circle digraphs in Scandinavia. This makes Scandinavian VAXen a pain to use! And did we ever find out what the IBM PC's y-umlaut is actually for? So far as I know it's not used in any language, and appears to be a corruption of the Dutch ij digraph. - With the freeing of Eastern Europe, the demand for products that can deal with Cyrillic and Eastern European characters is going to rocket. - Much of the conversion software available is very poor. Can I make a plea to word processor designers to have an option in their "export file" commands to retain character codes they don't understand, in some form (for example in form <nnn>, where nnn is the octal/hex character code?). To be presented with a file in which every accented character, or sometimes every character, has been replaced with a question mark and asked "Can you do anything with this" (as I have been) is a considerable pain. - Since we cannot even agree how to convert ASCII into EBCDIC and back, I am not greatly encouraged - I don't like to think about the costs to industry associated with all the effort involved in translating between character sets. (Of course, the costs of doing the translation itself are another matter!) What we need is a single, centrally administered, extensible character set standard. Getting people to use it will be a different matter. The Unicode effort has already run into political problems where the Japanese and Chinese will not share a character code for the same kanji character. If the world is ever to become a global village, it would be nice to be able to send each other email and have it readable at the other end! Regards, Hugh Davies, Rank Xerox, Multinational Customer & Service Education- Europe, Welwyn Garden City, Herts. England. (o0 If you would like a copy of the XCCS, so you can find out what an L ogonek is, the part number is XNSS058710, available for a nominal fee from Xerox Systems Institute, 475 Oakmead Parkway, Bdlg. 4, Sunnyvale, California 94086, USA.)
Perhaps it has been mentioned (or will soon to be mentioned) about the use of ASCII for use in other countries, but ... Perhaps we have overlooked the risk of forgetting the origin of words and what an acronym *originally* meant. "ASCII", as we all remember, stands for American Standard Code for Information Interchange, the key word being "American". Would it not be stretching things a bit to expect non-"American" language nuances (like umlauts) to automatically fit in? Reminds me of the saying (paraphrased): When all you've got is a hammer, everything looks like a nail. Kim L. Greer, Duke University Medical Center, Div. Nuclear Medicine, POB 3949, Durham, NC 27710 voice: 919-681-5894
When I stated that 50% of the population is of below-average intelligence, I
should have used "median" instead of "average," of course. Boy, did a lot of
people jump on me for that one! Of course, the IQ test is normalized so that
100 is the median, so perhaps I should have said that 50% of the population has
an IQ of below 100, which is how I usually phrase that statement.
None of this changes the basic point of my message. It just reminds me of how
e-mail makes it easy for people to pick on sloppiness, while being unaware of
the fact that others are simultaneously doing the same thing. If I had made
that slip at a conference, one person would have pointed it out in Q&A and I
could have corrected myself at once, so that everybody would agree on the
proper terminology. Instead, I found myself typing basically the same mail
answer perhaps 10 times.
Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
>The cartridge ultimately chosen for the M16 was originally a ``wildcat'' round,
The original round used IMR ("improved military rifle") powder, which burns
quickly. The Ordnance Department switched to ball powder produced by
Olin-Mathieson, which burns much more slowly. The AR-15 was designed so that
the gas port stayed closed through the combustion. The ball powder was still
burning when the gas port opened, and let it burn into the gas tube.
In addition, the different powder also had the effect of increasing the cyclic
rate of fire from 750-800 rounds per minute to over 1000, which exacerbated the
jamming problems.
Another change not mentioned was the icreased "twist" of the rifling from 1 in
14 inches to 1 in 12. This causes the bullet to spin faster, and thus makes it
more stable. This was not a good thing, however — it meant that the bullet
would be more stable as it passed through the victim, instead of tumbling
around and causing more damage. The increased damage was one of the origional
AR-15's selling points over the M-14, and a central part of its design theory.
SOURCE: James Fallows, "Two Weapons". Unfortunately I don't know the source of
this article — all I have is a Xerox. I'll try to find out. It's a very
interesting piece, also mentioning similar stories about the F-16 fighter
plane, Spencer's lever-action rifle of the Civil War era, and the
Mauser/Springfield '03 during the Spanish-American War.
Ty Sarna sarnat@rpi.edu
Further, for 9-track tape, sensing a notch implies that the tape is to be read
only. Inserting the write ring allows one to write to the tape. Audio
casettes operate on a similar principle as tapes and floppier diskettes -
recess/notch means read-only - so it is the 7/2" diskettes that deviate from
the standard.
Which is more fail-safe? Arguably the "standard", where notch implies
read-only. However, no system is fool-proof ... because fools are so
ingenious. :-)
Jordan Kossack (713) 270-9056
Get ready to encounter another. 8mm (Exabyte, video) tapes have a small sliding panel that covers a hole to prevent writing, while 4mm tapes (DAT and DDS) have a similar but smaller panel which covers a hole to allow writing. Bob Jewett jewett@hpl-opus.hpl.hp.com
On 8mm video cassettes you write protect by sliding a piece of plastic
so that it is "in the way". This is equivalent to the stickers on a
a 5.25" floppy. Also for the above list: Umatic videotapes have a small
piece of plastic that does a write enable.
Douglas Krause, University of California, Irvine dkrause@orion.oac.uci.edu
BITNET: DJKrause@uci.edu
8 mm video tape cassettes (used by Exabyte data tape drives) have the feature
that when you flip the write protect tab, it is visible as a red flag. To me
this says
"Danger, your data is safe."
Much as I prefer 3.5" disks over the 5.25" format, there's one big advantage to the older disks' method of write protection. For our student labs here, we purchased 5.25" disks without a notch, easily obtainable from any large distributor. We then modified a disk drive so that it would write these disks despite the lack of a notch. When we lend these disks out in the lab, we have a high degree of confidence that the contents will not be changed, since the write protection cannot be defeated without cutting a notch or modifying a drive. (Well, there may be ways around it, but they are relatively obscure.) This really cut down on the virus problems in our lab. On the other hand, with 3.5" disks you can pry out the little slider, which prevents accidental modification of the disk, but a malicious user has only to wedge something into the hole to make the disk writable. A. Michael Berman, Dept. of Computer Science, Glassboro State College, Glassboro NJ 08028 +1 609 863-6521 UUCP: njin!gboro!berman
Upon my first reading of it, Cliff Stoll's message informing us about a contest for the "Most Useful Computer Virus" (RISKS 12-27) elicited in me a reaction that I didn't really understand. Various parts of my brain simultaneously said "That's neat," "Huh?", and "Whoa...". But at the time I couldn't put my finger on just why I had such equivocal feelings about the idea. As I read later responses, a question occurred to me: "What's bad about a 'bad virus'?" Is it its bad effects...you know, erasing my disks, slowing down my system, sending e-mail to my mom accusing her of wearing combat boots? I didn't like any of those answers... I think those viruses which have been dubbed as "harmless" (for instance, those which print a message on your screen then exit forever) are harmful too, because they decrease my confidence in the expected functioning of my system and make me paranoid about using software. Then I said to myself, "Suppose there was a 'good virus.' I mean a REALLY GOOD virus. Like maybe a virus which would get me free pizza all the time, or would explain to me just what the hell non-homogeneous Poisson processes are and how I can make them go away. What would happen in the exceedingly fortunate event that my system got 'infected' with it?" My answer was that I would wish I could just have run the program under my own volition. It should be clear what I'm getting at...all viruses are bad, because they take me out of control of my system and make me afraid to do things with it. Now, the issuer of the contest challenge, Fred Cohen, does forbid "entries that have been released into a computing environment without the permission of the owner...", but, for a virus to be a virus, it has to enter a computer without SOMEBODY'S knowledge: otherwise, in effect it's just a boring old remote procedure call, with a needlessly kludgey way of getting executed. Why copy code around when, if users really wanted to run it, they could just get their own copies? The answer, I suspect, is that they may or may not want to run it, but WE know what's best for them! You could argue that I feel this way just because I am fortunate enough to have some technical savvy...if I weren't a congenital computer nerd, I might be grateful for somebody arranging for a virus to hop onto my system and clean up all my old junk files (and order me a pizza), then quietly vanish. But I think that this notion is incoherent: either introducing such a "beneficial virus" is paternalistic (and to be avoided because you should instead educate your users and give them the knowledge and tools to maintain their systems safely themselves), or it's just a kind of remote system administration (and to be avoided because there are more efficient and less needlessly complex ways of accomplishing the same task). Cliff writes: > [Dr. Cohen] points out that malicious and unauthorized viruses have > given a bad name to viruses. I'll say! Would he really say? Some of the arguments I presented above are practically plagiarized from _The Cuckoo's Egg_, so I'm not sure. I feel a great deal of trepidation in writing this note; I'd be mortified if Cliff, whom I admire enormously, got mad at me for suggesting that he was smokin' Mother Nature when he wrote something, which seems to be what I'm doing. Urp. Of course, I'm certain that part of his motivation is that Dr. Cohen is plainly a "white hat," and that the idea of code roaming around in a network looking for opportunities to do good is what we technical types call "way cool." What I'm suggesting here, though, is that the idea deserves careful scrutiny lest our cool idea translate into somebody else's increased powerlessness (or, alternatively, somebody else's decreased system performance). Brian Rice Data General Corp., Research Triangle Park, N.C. DG/UX Software Quality Assurance rice@dg-rtp.dg.com +1 919 248-6328
In 1981-1983 I wrote a virus for the Apple ][ while an undergrad at
Texas A+M, mostly as a demonstration to friends that such a thing really was
possible. The intended "target" was my own disk collection, which was to be
kept in strict quarantine so the virus wouldn't escape accidentally. The idea
was to see how quickly the virus would spread within my own disk collection if
I used my disks "normally". The virus itself was intended to be entirely
asymptomatic: it did nothing more than check for incompatibilities with
programs or DOS, check for damage to itself, copy itself, and increment a
generation counter each time it infected a new disk. It could easily be removed
from a disk by using the Apple ][ utility "Master Create".
"Virus 1" DID unfortunately prove to have obvious (if inadvertent)
symptoms, so was considered a failure. I don't believe it ever escaped. A few
months later, using what little free time school work left us, we came up with
"Virus 2". This virus appeared to have no symptoms, so after a while several
friends interested in the project deliberately infected their own disks as part
of the test. The first hint we had something had gone wrong was when pirated
copies of the game "Congo" at UIUC (a friend of mine had finished at A+M and
gone off to grad school at UIUC by this time, taking copies of the virus with
him) started behaving strangely: the game would still run, but its graphics
would smear. (Apple ][ users there were quite perplexed: every time they
tracked down a working copy of the game to get a fresh pirate copy from, it too
would prove to have stopped working. Running "Master Create" or booting from a
write-protected disk was not an obvious cure back then for such a "mysterious"
problem.) We quickly wrote an "immunizer" utility and distributed it at UIUC as
a "cure for the smeared graphics problem with Congo".
But what if Virus 2 spread faster and farther than copies of the
(nonviral) immunizer program? We analyzed what had gone wrong and created
"Virus 3" to displace the close-but-not-quite-right Virus 2. Amazingly (in
retrospect), this strategy appears to have actually worked. We never noted any
symptoms, and I guess nobody was looking for a "computer virus" back then in
the absence of a red flag demanding attention. And so we heard nothing more
about my virus "in the wild"...
...until 1985 (or thereabouts). By this time the microcomputer lab at
UIUC was under siege from a vicious virus that would randomly erase infected
disks at boot time. Frantic investigators into the problem discovered some
disks had a form of partial immunity: instead of erasing themselves, they would
merely crash. They could then be fixed up with Master Create, and all would be
well. The cause of the baffling immunity? They were found to have been
previously infected with an undetected asymptomatic virus... Virus 3! (And
that really is the last I heard of it.)
I'm in the process of writing this story up for a journal; if you have
any old Apple ][ DOS 3.3 48K slave disks you'd like to look for my virus on,
send me e-mail and I'll tell you how. It would be very interesting to find out
what generation counts the virus got up to! (I only have copies of the virus
from my own collection.) PLEASE NOTE any candidate disk must be absolutely
unmodified standard "slave" DOS 3.3, or my extra-cautious virus would not have
attempted infection. Such disks became progressively rarer in the mid-80's as a
plethora of improved DOS's from various sources became available; it appears
quite likely my virus went extinct as a result. Also please let me know if you
remember hearing anything about Apple ][ viruses around 1981-1985. I have since
heard of at least one other very early Apple ][ virus, called "Elk Cloner".
(That virus did "call attention to itself".) Thanks.
— joe@montebello.soest.hawaii.edu
Please report problems with the web pages to the maintainer