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…
[ I was recently reminded of this one by a thread in a newsgroup I frequent ] It seems that in the OS/2 (2.1 and Warp) TCP/IP stack socket descriptors are system-wide. That is, they aren't per-process file descriptors, so if you can discover the number of some other process's socket (and netstat -s will helpfully list all the open sockets on the system) you can send(), recv(), shutdown() or do many other fun things with it. Risks include the fact that anyone with telnet access to the machine (and OS/2 telnet security is a risk in itself) can write a program to subvert any TCP/IP server running on it. A shame, because otherwise it's one of the better non-Unix implementations of the BSD socket API. Pete
Summarized from the *Detroit Free Press*, 11 April 1996, p. 4B. John O'Valle was convicted in 1987 on charges of cocaine and weapons possession, and was expected to serve 20 years in prison. Later on, however, the sentencing judge reduced the sentence on technical grounds, making him eligible for release in 1992. The reduction was noted in O'Valle's written file, but not in the Department of Corrections' computer records. (Neither O'Valle nor his lawyer was notified of the change.) In January 1996, prison officials reviewed his records and discovered the discrepancy. However, there is now a new problem. In 1995, O'Valle was convicted for possession of marijuana while in prison, a felony. Had he not been in prison at the time, he would have been guilty of a misdemeanor and not subject to jail time. So now O'Valle is serving time for a felony, which (presumably) never would have happened had he been released on time. State officials aren't sure what to do. Officials aren't sure what happened. O'Valle's warden says that sentencing formulas are complicated, and the prison camp program and parole programs were in "transition" during the time O'Valle entered the system. Perhaps a new story with an old moral: if you have replicated data sets, make sure that the data sets are consistent. Jim Huggins, University of Michigan (huggins@umich.edu) [The O'Valle course runs twistingly around. PGN]
I don't mean "critical" as in "film-at-eleven," but as in its size or penetration has reached a sufficient point for a process to occur. In ten years on the net, I've only come across a couple other people with my last name. Websearches never revealed anything but links to my own data. But within the past few weeks this has changed. RISKS had an article about www.switchboard.com, which lists some 350 Roebers. A new websearch finds a dozen Roebers. And suddenly the e-mail has started coming in-- "My name is <something> Roeber. Might we be related?" And this is all happening at once. It shouldn't be long before we have the whole family tree worked out. I can't say there's a hard risk to this, other than the usual ones of privacy and how the net is making this an ever-smaller world. (But I do hope none of those 350 www.switchboard.com hits are actually federal witnesses in the American witness protection plan. Pretty soon they'll stick out like sore thumbs.) Frederick Roeber roeber@iea.com - roeber@cern.ch - roeber@caltech.edu [Frederick has gone from being a Roeber Baron to being a DisRoeber, in short order. This must be where the Roeber meets the load. PGN]
It seems that a friend's friend [name altered] decided that he wanted to only have a single name, Smith. When Smith had his name legally changed to just Smith one of the things that he had to do was get a new drivers license. So he headed on down to the local DMV. It seems that the state of Oregon (at the time at least) had a computer system that required that both a first *AND* last name be entered for every persons license. Of course Smith only had one name (and the paper to prove it). So after struggling with the system for a while the diligent workers asked Smith to come back in a couple of days when they would have a license for him. And, sure enough, a couple of days later he returned to find a license with just the name Smith on it waiting for him, all seemed to be well. While on a road trip, which Smith is prone to, he was pulled over for some sort of traffic violation. When he was offered up his license as per request the police officers were concerned with his lack of a second name (first or last? you decide). When they looked him up, he was not in Oregon at this time, they could not find any such person as "Smith" in the Oregon registry. At this point the police officers began to get suspicious. After much investigation, and a great deal of lost time and frustration on the part of Smith and the local constabulary, it was determined that the state of Oregon had done the following: Failing to get the system to accept a single name for a drivers license they inserted a fictitious second name "Jay". They then simply altered the printing process so that only the name "Smith" actually appeared on the license. So to find Smith in the Oregon listing one would have to look under "Smith Jay". The risks? Well, I believe trouble with the law would be obvious in this case. It might also cause problems in terms of employment where security and background checks are done as well as insurance. I believe that the least that could have been done would have been to explain to Smith what had been done to make this work. It might also be more appropriate to have a preset second name like "No Second Name" that could appear either in the list, on the license or both. Colin Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/
I was filling out an application for a summer job. Time was of the essence, so the company's normal employment application was FAXed to me. Printed in landscape mode, the bottom question, about whether I'd been convicted of a crime, got cut off by the FAX machine. Since various companies ask the question in different ways (some ask only about felonies, others include traffic citations, etc.), I decided that the best approach was to write in, "I have not been convicted of a felony" and to initial it. I then FAXed the application back. I received a phone call within the hour asking if I was a felon. I had written the word "not" a little lower on the page, and _it_ got cut off on the return trip. The situation was resolved, but somewhat amusing. I've fought laser printers that can't print closer than 1/4" to the edge of the page before, so I should have known about the problem, but I forgot. RISKS: You think of FAX as being WYSIWYG, but it isn't quite. And you can't (easily) see what the recipient will get. Drew Dean <ddean@cs.princeton.edu> Department of Computer Science, Princeton University
The Netherlands and the Dutch-speaking region of Belgium have an organization to define the language (Dutch) spoken in the two counties. This organization reformed the Dutch language the last time in 1947-1954 by printing "Het groene boekje" (the little green book) _Woordenlijst Nederlandse Taal_. This book defines the rules and words used in the Dutch language. In the last few years, there has been a feeling of unease with the spelling: it was felt that there were to many "illogical" words. So, a committee was formed to reform the language. But they proposed a radical change — for example, the use of "c" sounding like "k" would be abolished. There was protest (and the grounding of a "We love the letter C" group) and the politicians told the committee to soften its proposal. It seems that they did this (in a very short time) by simply removing rules that were too radical, and then removing a bit more. (Nobody actually knows for sure: interviews with committee members result in a lot of finger pointing and "It works for me".) So, version 2 came out, and is now law. It must be introduced in the schools, government and media. There is one snag: the rules are not "complete": the rules given don't even include the spelling of words given as examples, and there are cases without any rules. Nobody uses the green book; people use dictionaries. But the major publishers found the rules and the words in argument, so introduced their own rules. Each publisher has different ones. Major newspapers also have an internal dictionary, and they did the same. One major encyclopedia publisher even found the new rules so bad that it refuses to use the new spelling. The RISKS? I have to write my thesis *after* the new spelling becomes law, and I have to write it in Dutch. Now my only problem (and that of Microsoft, Lotus(oops IBM), Word-perfect (whoever owns them), etc), is *which* Dutch. This whole case is a textbook demonstration of the RISKS of language specifications and the influence of politics on "natural" or "logical" designs. 20.5 million people have to live with the consequences. Peter Van Eynde [It's logic Jim, but not as we know it.]
There has been another side effect of the daylight savings time change, with the Netscape Navigator browser: caches have incorrect times and no longer work properly for documents that change frequently. Netscape Navigator version 2.x for Windows and Unix platforms is an hour off in its cache-file handling. If a user tries to reload a page that has changed within the last hour, the browser still thinks its cached version is more up to date and won't retrieve the new version. (After an hour, this is no longer an issue.) This has been a problem with news organizations (such as ours), chat/bulletin boards, and java applets that need to be updated frequently. Netscape's "force reload" procedure (shift key + reload button) doesn't always work either: the only solution is to flush the memory and disk caches before a reload, or to set them to size zero. Netscape has made no official statement, but apparently has said the bug won't be fixed in the next version of the software (2.1) but in the one after that (3.0 (Atlas)). The Macintosh version does not suffer from this bug, nor do versions 1.x, or browsers from other manufacturer. The risk (aside from the obvious one related to programming for time changes) is trusting that a market-leader software company is going to have bug-free software. John F. Whitehead OnLine Technical Director 919-821-8605 jfw@wral-tv.com http://www.wral-tv.com [This problem was also reported by CurtAkin@aol.com and Prentiss Riddle <riddle@is.rice.edu> — next message. PGN]
[...] One workaround is said to be to run Netscape in California time, e.g. under Unix: setenv TZ PDT ; netscape & Defying the RISKS tradition of intoning that "the risks are obvious", one could draw the following lessons: — Time-dependent functions should be tested using multiple time zones and both DST- and non-DST dates. — In networked applications, local time issues can cause more than just local problems. Prentiss Riddle <riddle@rice.edu> http://is.rice.edu/~riddle RiceInfo Administrator, Rice University
My university recently (ca. January 1, after a testing period of about a month) instituted a new dialup service, for which students and faculty are charged 75 cents per hour peak and 60 cents off-peak. A couple of days ago I logged on and saw something like the following in my logon message: > Charges THIS month to date 500 minutes for a cost of $ 49.59 > Charges LAST month (total) 2089 minutes for a cost of $ 24.76 (Note that these aren't the exact figures, but you get the idea.) Needless to say I was consternated. After complaining to the admins, I learned that the billing discrepancy arose from the change to Daylight time. Night owl that I am, I happened to be logged in at the exact moment that 2:00 a.m. EST became 3:00 a.m. EDT. Needless to say, this was the first time they had dealt with the changeover. Happily, the problem has since been fixed, but the risk is self-evident. Lorne Beaton <beaton1@server.uwindsor.ca>
The March 1996 issue of IEEE COMPUTER contains an article on the rise of computer crime ("Security and Privacy TC," by Deborah Cooper and Charles Pfleeger, pp. 118-119; TC = Technical Committee). Based on a table of statistics obtained from the CERT Coordination Center, the article claims that computer crime is undergoing a "dramatic escalation." Whether or not this is true, the article is seriously flawed, and it points out the risks of shoddy statistical reasoning. Here is an excerpt from the table, which has the heading, "Computer Emergency Response Team (CERT) statistics show that computer attacks are on the rise." YEAR INCIDENTS REPORTED ========================== 1988 6 1989 132 1990 252 1991 406 1992 773 1993 1334 1994 2341 On first glance, this certainly appears to be a "dramatic escalation" in computer crime... or does it? Let's look at how much information was not presented in the article. The table heading discusses "attacks," but the table column says "incidents." So what exactly is an "incident?" Is it a report of an alleged attack? (Likely, given that CERT is usually the recipient of unsolicited reports.) Or is it a verified attack, meaning that erroneous reports were somehow weeded out? If it was verified, how was it verified? The article doesn't say. I wrote to Pfleeger with this question, and he responded that "the source of these statistics is CERT" and I would "have to contact them for the interpretation of their data." In other words, Pfleeger, Cooper, and IEEE COMPUTER published a table of statistics that the authors did not not themselves understand. So I wrote to CERT, and their response indicated that an "incident" is a report, and that they "don't talk to law enforcement people at all" to verify that an attack is real "unless a site requests us to." The abuse of statistics gets worse. While the number of incidents in the table is approximately doubling every year, so is the population of the Internet (source: The Economist, July 1995). In other words, the number of incidents grows linearly with the size of the population, which is completely unsurprising. This fact is not mentioned anywhere in the article. Pfleeger argued (by email) that "technical and physical security controls" have improved since 1988, and yet incidents have continued to increase "in spite of improved protection." That is an interesting hypothesis but hardly a reason to ignore the growth of the Net as a possible source of increased reports. The CERT representative reported that she didn't "know why the authors of the article didn't mention the relationship between the number of incidents and the number of Internet users." Similarly, the visibility of CERT has grown greatly since 1988, and this could account for an increase in reported incidents. Again, this is not mentioned in the article. Both Pfleeger and CERT say that measuring CERT's visibility is a non-trivial task, and I agree. Still, the effect should have at least been mentioned in the article. Footnote 1 of the table mentions that "some incidents have ongoing activity for long periods of time (i.e., more than a year)." I asked Pfleeger whether "ongoing activity" meant "ongoing penetration of a compromised system," or "ongoing interaction with CERT," since the phrase is ambiguous. Pfleeger DIDN'T KNOW and suggested I ask CERT. He also didn't know whether the phrase "some incidents" referred to a majority or a (possibly insignificant) minority. By highlighting the incidents with long ongoing activity, the table takes on a negative slant. After all, one could just as easily have focused on the opposite, saying that "some incidents lasted only a few minutes." My intuition and experience tell me that security incidents are indeed increasing. In other words, I believe the basic premise of the article. Nevertheless, the article's reasoning is flawed and contributes only to the prevalent misinformation about computer crime and security. Dan Barrett dbarrett@ora.com http://www.ora.com/item/bandits.html Author, "Bandits on the Information Superhighway" (O'Reilly & Associates)
To see if any of my personal WWW home pages have been indexed by web crawlers, I sometimes query the popular web search engines with my first and last names. Imagine my surprise when, amid the usual links, I found several that referred to caller-id files! Upon visiting the links, I discovered many text files containing a column of phone numbers and a matching column of people's names. The files were broken up by month and year, and contained hundreds of listings each. Some of the names in the list were 'Pay Phone' and 'City of XXX' and 'State of XXX'. Often, a name and number would be repeated several times in a row, presumably denoting multiple calls from one number. When I removed all but the fully qualified host name from the URL address, I was presented with the first HTML document that I'd found on this server. It was functional, yet spartan: clearly intended for the page-developer's use only. From it, I ascertained that the phone lines from which the caller -id's were taken were all named after different kinds of sexual activity. Forgive me for jumping to conclusions, but I believe that these files were created by a phone-sex service. Perhaps they are used to identify satisfied customers, or to help direct incoming calls to the proper 'talent'. The RISKS: too many! First, it is foolish to allow proprietary information be stored on a server connected to the internet. Second, any time that you dial the phone, unless you're calling from a Pay Phone or the State of XXX, the marketeers at the other end probably know who you are. Finally, free access to demographic data may be hazardous to your marriage, or job, or whatever.
Sean Reifschneider reports that Social Security Administration employees sold SSNs and "mother's maiden name" info to a credit-card fraud ring. Many credit card issuers require "activation" of newly-issued cards, i.e. the recipient must call a toll-free number and give this kind of "identifying" information before they can use the new card. Actually, the weakest link is "the clerk who's paid $12K/year" at the credit-card issuer. Recently I received a new card, called the number, and adamantly refused to give my SSN over the phone. The somewhat flustered clerk eventually activated my new card, having received only the credit-card number and the zipcode (postal code) printed on the accompanying letter. No SSN, no "mother's maiden name," NOTHING else. If all I need is the card and the letter, why pay off SSA employees? I have written to the credit-card issuer, no response yet. --paulr
>The "problem" is due to a new release of Pegasus which added a directed >confirmation header field as well as keeping the old confirmation header The new header was added precisely because the old version was causing problems with mailing list, but people have to upgrade the reading version not the sending version to gain the full benefit. However, this whole thing shows the common risk that users will demand certain features of a product ("read" receipts are a very popular feature of Pegasus) without realising the full implications (namely they will get a reply from every Pegasus user on the mailing list, and possibly compromise the privacy of those subscribers). There is, however, a very simple solution for MajorDomo and probably for listserv, just filter out the offending headers. The standard MajorDomo already filters out Return-Receipt-To:, a rather more common, non-standard header, with similar effects. Adding such filters to MajorDomo is a reasonable local customisation. Although there are now safe standards for achieving these results, which shouldn't propagate through a properly configured list server, it will be many years, if ever (commercial factors, rather than good technical design are now controlling the e-mail market), before they are widely implemented, and more ad hoc methods of meeting the market demand for this feature will arrive first.
Two things about automatic e-mail confirmation, although the risk is nothing new to RISKS readers... Recently, on a mailing list I maintain, a Pegasus (the name of a Mac/Windows e-mail reader) user posted a message with a line: > X-Confirm-Reading-To:http://daisy.uwaterloo.ca/~pjyamamo/
While I tend to disagree with your preference for "e-mail" over "email", that pales in comparison for my dislike of the use of "email" as other than a mass noun. Sentences like "send me an email" or "I received an email today" bother me intensely. "Mail" is a mass noun --- no native English speaker would replace "an email" with "a mail" in the above sentences! But many casually do it with "email", even though "email" is just "electronic mail". Listen everyone, it's "send me some email" or "send me an email message" or "send me a piece of email" etc.. (So, maybe PGN is correct after all. Maybe we do need the hyphen to remind people that "e-mail"/"email" is a modification of "mail".) Davin Milun milun@cs.Buffalo.EDU http://www.cs.buffalo.edu/~milun/ Cory Search - Aquaria index: http://aquaria.cs.buffalo.edu/ [And PGN left all of Davin's "email"s intact. Am I ("Am I" = the French pronunciation for "email", sort of) Nice?]
<> [...] "co=F6perate", "na=EFf", and "Bront=EB.". [...] ... <> Usenet (at least NNTP) is generally 8-bit transparent, and any European <> soc.culture group will tell you that ISO 8859-1 usually works [...] Nothing is so simple as it seems at first sight. There is not only ISO 8859-1, but also ISO 8859-2, ISO 8859-3 etc. For a practical example of the difficulties, see soc.culture.esperanto. (Esperanto has the endearing feature that stripping supersigns tends to cause a lot more confusion than in say Czech.) Most people there have given up and are using the ugly method of a trailing x (which is human-readable yet machine-tractable). [...] Using multipart/mixed and separate charsets for each section? While that would be acceptable to people who have MIME, it would add to the bulk of the headers that one has to skip in a plain text reader. Of course, that's assuming that each contributor only posts in one charset. Multi-charset contributions would be worse still... I guess it'll be a long time before I can put my name on my Esperanto postings properly (the r should be \v{r}, and the i should be \'{\i}). Jiri Baum
Please report problems with the web pages to the maintainer