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…
On Monday, 13 Jan 1997, Vineyard.NET was apparently attacked by a spam-for-hire company. The organization, "CV Communications," connected to our SMTP server and started sending us advertisements for its own spamming services. I discovered the attack after approximately 66,000 messages were sent. Most of them went to subscribers of AOL and CompuServe. I contacted the spammer, using the phone number at the bottom of each message he was sending out, and demanded that he stop. Spamming is a known problem on the Internet. I'm hopeful that law-enforcement agencies will start seriously looking into this problem, as I think that there is a limit to how effective technological solutions can be. However, there are several solutions that I have thought of. 1. Limit the number of RECV recipients permitted in each SMTP transaction. Rather than sending out tens of thousands of messages, we were hit with a few hundred messages that each had more than 100 recipients. We have therefore modified our netperm-table file to limit the number of recipients that each SMTP connection can have. 2. Disallow transiting. Vineyard.NET's SMTP server is used both by our customers to send out messages and by others on the Internet to send us messages. But it shouldn't be used by others on the Internet to send messages through us to third parties. We have therefore modified our SMTP server so that it can tell the difference between an internal connection and an external connection. External connections are not allowed to transit through us to other external mail servers. 3. Reject messages that come from "suspicious" sources. We have not implemented this yet. However, it seems reasonable to reject out of hand any SMTP message from certain kinds of hosts. For example, you might want to reject those from addresses that do not have a valid domain name, or from hosts that appear to be dialup addresses. I have written an article about this spamming incident which will appear in my 28 Jan 1997 Packet column. You can view it at http://www.packet.com/garfinkel on Wednesday January 29th. I have also made my modified SMTP server available. It is located at http://simson.vineyard.net/hw/spam2/smap.c . This is a modified version of the Trusted Information System's SMAP server, part of their firewall toolkit. It is my understanding that FWTK is no longer being maintained by TIS, which is a pity. Simson L. Garfinkel, Visiting Scholar, University of Washington, Columnist for PACKET <http://www.packet.com/garfinkel> and The Boston Globe.
Last summer, contractors at Commonwealth Edison's LaSalle nuclear power station were filling cracks in a concrete floor by pumping them full of foam grout. What the workers didn't know, though, was that a tunnel ran beneath that floor, carrying water for some safety systems at the plant, and their grout was pouring through the cracks into the water. The grout partially clogged the tunnel, compromising safety at the plant for 10 days before Edison — when pushed by federal inspectors — finally figured out what was wrong. [*Chicago Tribune*, 25 Jan 1997, front page] The NRC levied a $650,000 fine for what they called a "very significant safety problem." Without getting into a debate about nuclear power, I think one could point out the risk in thinking that there are any non-critical jobs where critical systems are concerned. Paul Bissex pb@well.com http://www.well.com/user/pb/tech/ [Grout, Grout, Dammed Slot! PGN]
A program error caused Schwab's computers to omit a significant number of mutual funds when investors used Telebroker to track holdings by phone, leading some of them to believe themselves broke. The problem existed from Monday afternoon through late Tuesday evening scaring scores of investors. Janus, Putnam and Schwab's own funds were among those omitted from net asset calculations. Tracey Gordon, Schwab spokeswoman: "We were making some system changes when there was a program error." On why the problem went on so long: 'Mutual funds are priced once a day. We found that it would be cleaner and simpler to wait until the next regularly scheduled market change to update the system'. Cleaner and simpler for Schwab, presumably. Gordon said investors who made panicky trades as a result 'would be made whole' but there'd be risks in determining both the who and the how much. Norm deCarteret
My full name is Michael Steffen Oliver Franz, which makes my initials "msof". I usually use these initials in internal correspondence, and I have an e-mail address "msof@sprynet.com". Now, I just installed Microsoft Office 97 on my computer. Curiously, Office 97 automatically replaces some occurrences of "msof" by "Microsoft Office". For example, this happens in the "initials" box in the Word Annotations dialog. I am not yet sure how far-reaching this automatism is, but the prospect of having my name replaced without my knowledge is frightening. You can see this strange effect for yourself if you type "msof" at the start of a line in Word and then wait for a short time. Michael Steffen Oliver Franz franz@uci.edu (university business) and msof@sprynet.com (private)
An article in the Swedish newspaper Svenska Dagbladet (1997 Jan 24) currently available on their web site http://www.svd.se/ describes research carried out by Ericsson Saab Avionics by Karin Johansson that suggests that computers, especially those carried on high-altitude aircraft flights, may be at risk for cosmic radiation. Johansson and her colleagues carried out experiments on SAS transcontinental (Atlantic) flights that measured one [bit] error per memory chip per 200 hours. The article notes that a modern personal computer may have 64 such chips. This means that an ordinary laptop PC may expect an error every three hours, or about twice during an atlantic flight. [Assuming you brought enough batteries.] The problem is worsened when the flight path is over the North Pole because the earth's magnetic field, which normally protects against cosmic radiation, is directed such that the protection is lessened. Karin Johansson notes that the computers used to control the aircraft itself "are not the absolutely most modern, and consequently their electronic circuits are not as small and sensitive." However, component manufacturers are not interested in building electronics for such a small market as avionics, so the aircraft manufacturers must use the electronics available in the marketplace. To protect against error, aircraft computer designers will use parity and error-correcting circuitry to prevent a single-bit error from propagating into other computation. Summerized and translated by Martin Minow, minow@apple.com
The Shetland Times has obtained a preliminary injunction against the Shetland News to prevent the News's web site from linking to Times documents. Part of the judge's reasoning was that the advertising material on the "front page" of the Times could thus be bypassed. I did an AltaVista search on the phrase "Shetland Times" and came up with lots of links into the depths of the Shetland Times site. Presumably DEC has committed the same offense as the Shetland News, and their new European mirror site might be vulnerable to a similar challenge. Given the usual response to any attempts to remove "offensive" or "illegal" material from the Net, I'm surprised that I didn't turn up dozens of third-party links into the Shetland Times site, in defiance of the reasoning behind the injunction. Prabhakar Ragde, Department of Computer Science, University of Waterloo Waterloo, Ontario CANADA N2L 3G1 (519)888-4567,x4660 plragde@plg.uwaterloo.ca [There were several longer messages with similar points. PGN]
The judgement, as I believe it should be interpreted, means that it is the duplication of the headlines themselves which breached the copyright law. Whether they link to the original Shetland Times articles or different articles on the same story is irrelevant. The judge believes that the headlines constitute a separate work. It think that his decision was in line with the intention and spirit of the copyright law. Also, I note that RISKS contributions with URLs seem to be increasingly giving away the registered account information, namely http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?10695 This contains '10695' at the end, which is what identifies the user and now permits anyone to access The Times site in that guise. Watch out for a change in personal preferences ! John Pelan (J.Pelan@qub.ac.uk) [Note, in the above the '10695' is in fact a truncation of the full set of digits that were in the URL that Brian had posted. In a side message, Brian recommends that in the future that he/we indicate when such alterations are made. PGN]
>Macintosh users probably have less cause for concern about the year 2000 >than any other computer users, thanks to Apple's farsighted programmers. This gem illustrates just how nasty the Y2K issue is. The internal representation of the date is only one small Y2K problem. The others include: - are the library functions robust? Are they correct? (E.g., can they tell you whether 2000 is a leap year? The date of Memorial Day in 2017? The date of Easter in 2004? The number of business days between any two arbitrary dates?) - do the developers actually call these functions, or do they write their own? - do the developers always display 4-digit years? If not, do they always truncate the year correctly? - do the developers alway require 4-digit years? If not, how do they interpret shorter years? Bottom line: if mac programs are intrinsically Y2K safe due _solely_ to the representation selected by the godlike system designers at Apple, then all C++ programs are intrinsically bug free and fault tolerant since that language was designed to include resources to help make software engineering manageable. Bear Giles bear@indra.com
Ahh, but how do your _applications_ store dates? If only the last two digits are stored on disk then you have a problem, no matter how many bits your system clock uses. Good hardware design only provides a false sense of security when the programmers get sloppy. Jonathan Stott, CWRU Dept. of Physics, School of Graduate Studies jjs17@po.cwru.edu jstott@poly.cwru.edu http://poly.phys.cwru.edu/~jstott/
This isn't particularly novel. DEC's VMS operating system (designed in the mid-1970s) also implements the date as a 64-bit signed integer giving the number of microseconds since the Smithsonian base date of (I think) 17th November 1858. +ve numbers are regarded as absolute values, -ve ones as deltas, but even so the VMS clock is good for many millenia. In addition to that all date displays use a 4-digit year. There is a well-known bug filed against VMS pointing out that the date displays will be incorrect after Dec 31st 9999. The bug was accepted by DEC with the note "we will fix this in a future major architecture." Steve
In RISKS 18.78, Dan Hicks wrote: > I prefer a floating-point format ... Note that if you are measuring intervals by subtracting timestamps, then the use of floating point numbers for the timestamps can lead to hard-to-debug errors in accuracy. The Patriot missile failure in Dhahran was caused by a similar error: values from the system clock (integer number of tenths of seconds since powerup) were converted into floating point values to do the intercept math. After some number of days of operation, the point floated, and the accuracy suffered. [See RISKS-13.35] While it can be argued that this merely means that intervals should not be measured by subtraction like this, I think that floating-point system clocks would only increase the RISK of such an error. Frederick G.M. Roeber, Netscape Communications Corp., 501 E. Middlefield Rd. Mountain View, CA, USA-94043 +1 (415) 937 3180 roeber@netscape.com
The obvious defense against hostile or undesirable web sites is to not visit them in the first place. This process can in fact be automated in netscape's browser. This saves bandwidth and your time! The basic premise is that the browser may optionally execute a function on every URL before it is accessed to determine whether a direct connection should be made or a proxy should be used in the process. This affords the opportunity to [mis]direct the browser to fetch the document from an invalid source. this is a good approximation of not getting the document at all. We sit behind a fire wall, so all WWW access has to funnel through a proxy. If I tell netscape to fetch an external document using a direct connection, the connection attempt will fail, and the document will not be accessed. Netscape will put a broken image icon in its place. Here are the nuts and bolts to do it, but some assembly is required: Under options/network preferences/proxies, select "automatic proxy config" and tell it which file to use. Call it something like "file:///HOMEDIR/.netscape/proxy.pac", replacing HOMEDIR with your home directory; the actual code is included below. Next, go to options/general preferences/helpers and create an application helper of type "application/x-ns-proxy-autoconfig" for suffix "pac", handled by "navigator". Install this java-script code to do the actual filtering. call it "file:///HOMEDIR/.netscape/proxy.pac", as mentioned before. ================ function FindProxyForURL(url, host) { if ( isResolvable(host) && ! shExpMatch(host, "[0-9]*") ) return "DIRECT" ; else if (host == "advertising.quote.com") return "DIRECT" ; else if (host == "ad.doubleclick.net") return "DIRECT" ; else if (shExpMatch(url, "*:*/ads/*")) return "DIRECT" ; else return "PROXY webcache:8080; "; }
Net.abuse (spamming, mailbombing, systematic trolling, etc) are being fought via filters, among other things. This leads to unexpected risks for innocent bystanders. Having a similar domain name as a known net.abuser can make you guilty by confusion: if a spammer operates from earthFOO.com, and you are earthBAR.com, people are going to confuse the two domains. This has already happened (for suitable values of FOO and BAR — the common earth prefix was actually used). If it happens in a discussion, it can be (and has been) corrected. If it happens in a router, filter, or other software, it can be difficult to even detect. A similar thing applies to IP numbers. Many sites now block all IP addresses belonging to problematic sites. If at a later date those addresses are reclaimed by the ISP and re-assigned to another client, that client will still be blocked. Given the worries about IPv4 numbers running out, especially for smaller ISPs, this isn't unthinkable. I have an aggressive junkmail filter (http://www.iki.fi/liw/mail-to-lasu.html) You don't have to worry about it, since I've sent you mail.
I put the following in my /etc/hosts (yea, unix-centric, too bad): 127.0.0.1 localhost ad.doubleclick.net End of problem. I suppose if not already running a WWW server one could even put in a simple script invoked by inetd : #!/bin/sh echo "Content-type: image/gif" echo "" cat /usr/local/etc/nyah-nyah-nyah.gif if it makes you happier.... I suppose the risk is if ad-avoidance becomes popular enough that browser makers make it easy, then everyone does it, then an unintended consequence might be the hastening of the "pay-per-viewing" of the internet. John
A side benefit of proxy-server/firewalls is that they somewhat mask the identity of web-browsing folks behind them. When I refuse cookies and access Internet resources through the firewall of a large organization I get much of the anonymity I might want. I suggest that ISP's should offer to proxy their small customers' browsing just to give them this benefit.
Actually, the risks of misaddressing occur in any communication medium. We all receive paper mail that isn't for us; since most of us check addresses before opening mail, privacy is usually preserved at least (as it would be if we used the electronic equivalent of envelopes — encryption). We all receive phone calls that aren't for us; since the telephone is an interactive medium it is customary to verify the identify of the person at the other end before exchanging messages, thus preserving privacy and ensuring that the message reaches the right person. In 18.77, darin@connectnet1.connectnet.com (Darin Johnson) writes: >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. Actually, the place where this event is most common is on the MU* (MUD, MUSH, MUCK, MOO, MUX, etc.) systems, where it is known as a "mav". When sending a private message (page, whisper) to someone, it is very easy to 1) send a message to the wrong person, typically somebody else you are talking to or 2) mistype the command so everybody in the room sees the message. On fancier systems which allow a user to automatically reply to the last person who paged them, it is common (especially when the net is lagging) to get a page from person B while typing a reply to person A and thereby accidentally send the reply to person B. Despite a lot of fallout and embarrassment from these incidents, nobody has come up with a good way of reducing them — if people won't double-check what they type, there's nothing software can do to save them. Also in 18.77, Lawrence.H.Smith@williams.edu (Lawrence H Smith) writes: > ... naive users perceive it as "like paper mail, only faster and cheaper" - > a perception which is deeply flawed. Actually, the perception that paper mail is reliable is deeply flawed. Comparing the performance of the US Postal Service to that of the net in my nine-plus years on the net, I would have to say that paper mail is at least as bad if not worse. The post office loses several pieces of mail on me every year. Their latest goof-up was to misdeliver a piece of mail to the wrong address (wrong *state*, even!) three times before bouncing it back to me. Now, this failure mode is shared by electronic mail, but the post office took two months as opposed to a few hours. --James W. Birdsall
The university of Guelph has a simple policy for creating e-mail accounts: first initial, last name (i.e., tburgess@uoguelph.ca). This scheme works great as long as their are no duplicates (ie Tom Burgess). If there are duplicates then they start adding numbers to the e-mail ID or simply using first names. When my brother came to Guelph my Dad tried sending e-mail to jburgess@uoguelph.ca which was not my brother's e-mail account. My brother had been given the account joel@uoguelph.ca. Luckily the person who got the e-mail was nice enough to look up the correct address and forward it to my brother. The RISKs? E-mail ID schemes like this work great as long as there are no duplicate names. The moment there are duplicate names then a lot people are going to start seeing other people's e-mail. As for Kamens's (RISKS 18.78) comment about paper mail vs. e-mail. I think it would be fair to say that it is easier to get an e-mail address wrong then a paper address wrong. E-mail delivery systems only have the e-mail address to go on when delivering mail. If your e-mail ID doesn't match then tough it bounces. Mail addresses have fields like name, address, city, country and postal code to assist in delivering mail. Failing that post offices can open mail in hopes of finding the correct address. I know people who have worked in post offices in small towns and they say they can usually determine where to send a letter simply on the name alone (even if the address is incorrect or missing). University of Guelph, Computer Science Major E-mail: tburgess@uoguelph.ca URL: http://eddie.cis.uoguelph.ca/~tburgess
In RISKS-18.78 Mike_Perry@DGE.ceo.dg.com and others discuss the problem of verifying e-mail addresses as correct, rather than just hitting the send key. The obvious solution ("Do you really want to send this? y/n") would undoubtably work no better than it does for file deletion. It occurred to me that perhaps what's needed is verifying something besides words on the screen; that if I am dealing with two kinds of sensory data something is more likely to click. e.g. a voice saying: "Sending mail to Ann Landers <al@annland.org>, OK?" and my saying "yes" or "no" (well within a modern machines abilities). Perhaps even do a little scan for hot words and have it ask: "Do you really want to use the word 'braindead' in your mail to 'boss'?". Although this is probably silly regarding e-mail (and adds a host of risks of its own) such warnings attached to particularly risky commands and forcing a person to do something *unusual* to continue could prevent a lot of errors, if not overused. (Note, something similar happens when the WinNT 4.0 license appears on the screen while installing that product. To continue you have to hit F8, and only F8. You are pretty much forced to at least glance at the license in order to continue. Annoying but rather slick. Taking it one step further: the key could needed could be chosen at random from the non-letters.) David Fetrow, Biostatistics, University of Washington
> ... AOL seems to have shot itself in the foot by going to flat-rate charges. Complicating the access problem (which I haven't experienced personally) is that AOL keeps putting up a piece of software that seems to block internet traffic. Despite repeated attempts to explain the problem, this software still appears (almost every other day) without the original problems getting fixed. I believe it's very hard to determine whether the new pricing has anything to do with their problems as long as they keep putting up software that doesn't work. /BAH
*** EARLY REGISTRATION DISCOUNT ENDS JANUARY 31 *** Fourth ACM Conference on Computer and Communications Security (Preliminary Technical Program) Zurich, Switzerland April 1-4, 1997 Sponsored by ACM SIGSAC For more information, including registration and hotel information, see: http://www.zurich.ibm.ch/pub/Other/ACMsec/index.html [The program looks really interesting. PGN says, "check it out."]
Please report problems with the web pages to the maintainer