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 *Computer Weekly* 7 Jun 2001, on the back page. ... a tale of cutting edge IT going off the rails. It reads, "I had an interesting journey home from London last night. I was onboard a new 100% computer-controlled train. In the middle of the Chester countryside, the train ground to a halt. The automated station-announcement system then ran through its program of station announcements in quick succession until it said the final destination." "It then attempted to open the doors (in the middle of nowhere). The guard ran to the driver's cab. The driver and the guard then ran through the carriages muttering that the computer had gone berserk and was telling them that the rear of the train was on fire. After checking, the driver, in a state of mild panic ran back to the cab, turned off all the engines, cut off all the power (leaving us in pitch darkness), and yes, you've guessed it, waited the customary - 10 seconds and rebooted the train. I wonder if anyone can confirm this wonderful story. The risks are self-evident. SCS Global Services Internet/Intranet Operations, GlaxoSmithKline, Medicines Research Centre, Gunnels Wood Road, Stevenage SG1 2NY UK
cf. http://www.chron.com/cs/CDA/story.hts/metropolitan/936841 Though not mentioned in this article from the *Houston Chronicle*, NPR reported (via KUHF?) that the elevator detected an emergency situation and automatically attempted to move to the ground floor. While that's often a good idea in case of a fire, in a flood it's the *worst* way to respond and, in this case, tragically lethal. [I was in an elevator at BBN in Rosslyn VA once when the control computer crashed. The elevator very slowly worked its way to the TOP floor, which might seem to make sense — *except* in a fire. Thus, we need an intelligent system that figures out which way to go, and therein lie even more risks — especially in a fire that results from a short caused by a flood. PGN]
The Pulse EFT network's main and backup power systems in Houston were flooded by Tropical Storm Allison, disabling their 22-state ATM network. "PULSE Enacts Disaster Recovery Program Early Saturday morning, the PULSE electronic funds transfer system experienced a major disruption of both our primary power source and our emergency back-up supply system, as a result of unprecedented flooding in Houston. A disaster recovery program has been instituted and efforts are underway to resume operations at a remote processing center located in Dallas. Until technical connections in the system can be restored, disruption of ATM and point-of-sale services at some locations will be experienced. PULSE has a proud record of 99.99% availability and we regret any inconvenience to our financial institutions, merchants, processors and cardholders that this extraordinary event may have caused. [...] http://www.pulse-eft.com/
In the Kyllo case, the Supreme Court ruled 5 to 4 that using an Agema 210 thermal-imaging device to scan for unusual heat sources in someone's house (i.e., searching for marijuana growing activities) is unlawful search if carried out without a warrant, violating the Fourth Amendment. http://www.supremecourtus.gov/opinions/00slipopinion.html http://supct.law.cornell.edu/supct/html/99-8508.ZS.html http://www.wired.com/news/politics/0,1283,44444,00.html
http://www.utm.edu/research/primes/curios/48565...29443.html One of the strangest consequences of the DMCA is that it would seem to outlaw possession of certain integers. The above URL gives the decimal form of a prime number whose HEX form just happens to be the gzip-ed C source code for DeCSS (which breaks the DVD Movie encryption — see RISKS-21.37). This observation is due to Phil Carmody. [Thanks to Mark Brader for the Subject: line!]
http://www.cnn.com/2001/TECH/ptech/06/08/pentagon.computers.ap/index.html The aggregation, inference, and sensitive-unclassified stuff is ubiquitous and often damning. This could be a harbinger of future RISKS stories.
I'm the maintainer of a free-software application called sitescooper, which reformats Web sites for viewing on PDAs. When I started writing sitescooper a few years ago, I hosted it on my ISP at http://www.clubi.ie/~jmason/software/sitescooper/ . Since this URL was quite cumbersome (especially when read on a PDA screen!) I also set up a forwarding URL with a domain called "tsx.org", which offered free URL forwarding. At that stage, tsx.org was a reasonably reputable URL-forwarding service. Since then, sitescooper has grown in popularity, and has moved to the easier-to-remember sitescooper.org domain. I left the tsx.org forwarding in place, updated to its new address, to catch old links and avoid link-rot, and forgot about it. This morning I received a mail from a potential user, who'd decided to download sitescooper and take a look. The mail stated: I'm writing about your Web site. [...] If you are aware of the way your site behaves then you should just close up shop and leave the Web because no contribution to software development is worth the hassle your site causes. If not, then I apologize for the above and I'll describe it for you. If your site: sitescooper.tsx.org is opened using a script-enabled browser (e.g., IE or NS), from a windows platform, it proceeds to plaster the screen with windows full of trashy ads that CANNOT be deleted. The windows have no controls and right-clicking the taskbar icons is disabled. THE ONLY WAY to delete this trash is to bring up the Task Manager via ctrl-alt-del, and kill the processes. NO WEBSITE SHOULD BE THIS INVASIVE. This is blatant abuse of the trust a user puts in you when they click a link to your site. Hopefully, you're not involved in it and it's being done by tsx - In which case I STRONGLY advise you to dump them as fast as possible and find a new Web host. I surfed over to sitescooper.tsx.org and took a look. Sure enough, it popped up 5 windows - 1 with no frame masquerading as a Windows alert, asking if I want to visit the BEST ADULT SITES AROUND, 2 full-screen unclosable windows, 1 normal(ish) ad window with a normal window frame, and (finally) the page I *wanted* to go to. Gah. Needless to say, sitescooper.tsx.org is now no more. I'd prefer if people hit a 404, and were forced to search Google, than run into this. The risk? There ain't no such thing as a free lunch, I guess. I'd assumed that the forwarding system would offer a consistent quality of service over several years; instead, in my opinion, they took advantage of their situation to increase their ad revenues at the expense of their users.
Greetings. The manufacturers of e-mail filtering and blocking systems continue to claim that their products have vastly improved over time --that the incidents of false negatives and false positives are greatly reduced from earlier versions. Much empirical evidence has continued in general to contradict these assertions, and here's yet another example of what happens in the real world as these systems are actually configured by users. My most recent PRIVACY Forum Digest was blocked by the popular "ScanMail" product as configured within at least one site. I only learned about this since the particular configuration was in a "quarantine for review" mode that sent out a warning. Other sites may be configured to simply delete flagged messages without such a reply to the sender. What was it about the PRIVACY Forum Digest that aroused ScanMail's ire? In the nine years since I originated the Digest, each issue has included a "quote of the day"--which usually is an interesting or amusing quote from a feature film. In the case of the most recent Digest (http://www.vortex.com/privacy/priv.10.04) I chose a quote from Peter Sellers' 1968 classic "I Love You, Alice B. Toklas!" Ah hah! The phrase "I Love You" appeared in the text of the message. It must be a virus! Or perhaps a spam? Indeed, the Digest was blocked via ScanMail's "ILOVEYOU" policy! This was done even though the message was not encoded in any way and was not an attachment. It was just simple, plain, ordinary, ASCII text, with the "offending" phrase well down within the message (not in the header). Presumably, ScanMail at various sites will be blocking *this* issue of RISKS because (horrors!) the forbidden phrase "I Love You" appears in this message as well! With such a level of "stone club" analysis at work, one can only imagine what other innocent e-mail is being injected, inspected, detected, infected, neglected, and selected by the "sophisticated" algorithms of filtering programs to be flagged, reviewed, dropped, banned, burned, or trashed. Lauren Weinstein <firstname.lastname@example.org> email@example.com firstname.lastname@example.org Co-Founder, PFIR: People For Internet Responsibility - http://www.pfir.org Moderator, PRIVACY Forum - http://www.vortex.com
For some years, I have been concurrently involved in countering spam and in designing, implementing and administering e-mail lists for marketing purposes. In both of these endeavors, as in much of life, heuristic (trial-and-error) methods are commonplace. Heuristic approaches to the development of spam filters tend to be somewhat effective. If one receives 100 pieces of spam over a reasonable period of time containing a given word or phrase, and no legitimate mail containing it, it is statistically probable that filtering mail based on that word or phrase will block at least some spam, and little or no legitimate mail, going forward. Of course, such simple heuristics are not without their risks. We recently sent an issue of our periodic customer newsletter which contained the phrase "sizzling summer." The marketers love their alliteration — in fact, the exact same phrase appeared a few days earlier in a mailing by another company in our market segment! Unfortunately, a small number of sites using simple heuristic filtering like that I described above took offense at our use of the word "sizzling," which apparently now indicates pornographic material. A better method might combine heuristics with the scoring capability in some mail server software (I'm personally familiar with Exim), incrementing or decrementing a counter based on the occurrence of given words or phrases, with actions depending on the final value of the counter. Thus, if "sizzling" is a +1 word, "video" a +2 word, and "sex" a +3 word, a threshold of 3, 4 or 5 might be used for blocking. Dan Birchall - Palolo Valley - Honolulu HI - http://dan.scream.org/ Peruse my opinions, at http://dbirchall.epinions.com/user-dbirchall [Still too many false positives and false negatives. PGN]
How do you ascertain the age of a virtual individual in an electronically synthesized image? In the real world, you can ask for some identification. My sister was frequently carded in bars (when the legal drinking age was 18) until she was 26, because she looked young. My son told me a story of not being carded at 16 when the guy in front of him was carded at 20 (when the legal drinking age was 21). Obviously you cannot reliably determine age by appearances. Perhaps you could look at the creation date of the file? ;-) [That's not very reliable either. PGN]
My name is Matt Giger and I write the EarthBrowser software that you have recently purchased us. I am writing to inform you of about a recent scam being run on our customers. This first report was about 5 PM on 6/6/01 from a customer who purchased EarthBrowser just yesterday. Apparently some files with customer information on our server have been accessed. Let me assure you that your credit card information is safe since we never store that information on our server. Also we purge all customer information on a daily basis so the amount of information they obtained was minimal, just your name, address, e-mail address and EarthBrowser serial number. The reported scam e-mail looks something like this: Please confirm [its] registration. Correct Purchase Information You account: http://www.earthbrowser.by.ru/3004001065-010605214102678/index.htm This poorly written e-mail sends you to a Web site in Russia which is an exact copy of our purchase page and presumably sends the information you enter to the thief. If you enter your credit card number on this page, they will then have it so please do not enter any information. Hopefully the poorly worded e-mail and the suspicious Web address will alert most to the fact that this is bogus. If you have received an e-mail like this one, please let me know as soon as possible so I can trace exactly how long ago they gained access. I apologize for having to warn you of this, I am taking steps to insure that our customer information remains safe. I promise to let you know of any such scams in the future, but please help me out by letting me know if you get any strange contact trying to use our relationship with you to obtain any information. Matt Giger, Lunar Software, Inc. email@example.com
A couple of months ago I was replying to a expert-witness report in an arbitration and found that his years of service calculations were wrong by four years. Then last week I received an excel file from the other side's lawyers in the case and noticed that when I cut and paste a column of dates they all automatically went back four years and a day. The problem arises from incompatibility between the 1904 date system used by excel in mac and the 1900 date system used in windows. This is a known and documented feature of excel: http://support.microsoft.com/support/kb/articles/q180/1/62.asp However, a quick search on the Web and in the Risks Forum archives suggests the risk isn't that widely appreciated. Even if one knows about the anomaly and checks for date system compatibility before cutting and pasting dates, one still could receive files from a source that already had corrupted dates. There would be no way of knowing (other than common sense if the results are not credible). It seems to me that the errors introduced into spreadsheet calculations will tend to be systematic rather than random because: 1. they will often occur when two or more sets of data are being consolidated and thus the errors will apply to the population of one set but not to the other and 2. the direction of the error will be influenced by the prevalence of macs or pcs in different institutional settings and fields, e.g., macs in universities & design and pcs in businesses & finance. Thus, for example, dates systematically advance from businesses to universities and recede from design to finance. This makes collaborative work between institutions and professions especially vulnerable. The first time (that I know of) that I encountered the problem was a practical instance with a potentially significant economic impact on several thousand employees. The fact that the data was presented in the course of an adversarial process was probably crucial to the error having been detected. I am wondering why there aren't more reports out there of encounters with this problem. Is this bug flying under the radar? Tom Walker, Bowen Island, BC 1-604-947-2213
I was recently assigned to take over a system that processes and sends data to a wide variety of scientific agencies that depend on said data. In particular, I've been asked to understand the system well enough to maintain and troubleshoot it. Naturally, the system, both software and hardware, was created "in-house" by contractors. Nothing like anything I'd experienced before. When I requested documentation, I was told there was none. The last person who had to work on the system had produced a draft of user documentation, but it was incomplete. So, I contacted the poor soul who had worked on this system before me, the one who had produced the incomplete documentation. (We'll call her Joan.) Joan was only familiar with the part of the system she had worked on (the user interface, really). So I asked her about the two people who had designed and implemented the system in the first place. I thought that they could perhaps help me with some of the questions I had. One of them had left the company that originally employed her, and wouldn't return phone calls. So I asked Joan about the other designer, who seemed to have done the bulk of the work anyway. "He's dead," Joan told me. "Heart attack." The risk? If you skimp on documentation while designing a custom system, you may find that you don't have time to go back and do it later, with serious consequences for those who follow you. This problem should be familiar to most readers of RISKS, but it bears repeating. As I write this, a problem has come up with the system and no one is even sure if it is hardware or software. When dealing with such a system, you cannot guarantee you will be able to talk to the original designer (and the only one who understands the system fully), and it might be because they've left more than just the company that originally produced the equipment. Sic transit gloria mundi... Kirt Dankmyer — 757-824-2283 — firstname.lastname@example.org CSOC UNIX System Administrator — Wallops Flight Facility [Of course, Wallops Island is where a lightning strike hit the missile launch platform when a missile was waiting to be launched to test the effects of lightning — and resulted in the missile accidentally being launched. PGN]
BKININSC.RVW 20010511 "Inside Internet Security", Jeff Crume, 2000, 0-201-67516-1, U$29.95 %A Jeff Crume email@example.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2000 %G 0-201-67516-1 %I Addison-Wesley Publishing Co. %O U$29.95 416-447-5101 fax: 416-443-0948 firstname.lastname@example.org %P 270 p. %T "Inside Internet Security: What Hackers Don't Want You to Know" Recently I started teaching a new class. During the introductions, one student admitted that he wanted to learn how to break into systems since that would teach him how to protect them, right? In the first place, I don't believe him. In the second, his thesis is seriously flawed. Yet that is the type of argument Crume seems to be making in the introduction to this book: learning how to hack will teach you how to protect yourself. It doesn't work that way. Knowing how to exploit a buffer overflow in Microsoft's Internet Information Server doesn't teach you anything about the type of systems development practices that will keep you from leaving buffer overflow loopholes in your own programs. Crume does, however, present some good, if basic, security advice. After a bit of a rocky start. Chapter one says that there are weaknesses in the net. Big surprise. Chapter two says that the Net is possibly dangerous. About the only reliable information you'll get out of chapter three is that hackers differ. By chapter four, though, the book has settled down. Here we get a decent introduction to risk analysis, stressing that some risks are not worth protecting against. There is some solid advice about security policies in chapter five, most notably, have one. Chapter seven lists some good general points to keep in mind, which then become the titles of the remaining chapters. There is a clear, if not terribly detailed, explanation of what firewalls are and do, in chapter eight. We are warned to be wary of insiders in chapter nine, which also points out that not all "insiders" are actually inside. Chapter ten outlines some of the aspects of social engineering. A detailed discussion of passwords, in chapter eleven, even covers tokens and biometrics. Network and packet sniffing is explained in chapter twelve. Chapter thirteen is weak. Ironically, it is the first chapter to touch closely on the items Crume implied in the introduction, and looks at software vulnerabilities. But these loopholes are very difficult to deal with, and the material here isn't much help. Chapter fourteen is helpful in pointing out that factory set defaults can be dangerous. The title of chapter fifteen ("it takes a thief to catch a thief") seems to be suggesting that you hire hackers. Actually, it merely suggests that you learn the vulnerabilities that they know. However, it isn't very useful in pointing the reader in the right direction. Chapter sixteen offers a grab bag of anecdotal reports of recently exploited vulnerabilities. And, of course, I have to pay special attention to chapter seventeen, on viruses. Well, Crume makes mistakes, but he doesn't make any really important ones. The background is reasonable, and the advice is sound. Chapter nineteen provides a good overview of cryptology, but some of the more important points get buried in the stories. (There is more material provided in appendix A.) Backdoors and end runs are discussed in chapter twenty. Chapter twenty one points out that even "harmless" defacement of a Web site can have serious consequences, while twenty two says the information is valuable and a good defence. Chapter twenty three finishes off with a look at some emerging technologies that are bringing forward new security concerns. One note that I should make: the text doesn't have all that much to say about the Internet, as such. Most of the points deal with security on a general basis. Which doesn't necessarily make it any less useful. This book can be read completely in a day. And, for most managers and business people it would be a day very well spent. While some chapters are weak, roughly three quarters of the material is both reasonable and technically sound, a match that happens less often than one might wish. This is definitely a volume to get to pass around among all employees--and to provide to all newly hired managers. copyright Robert M. Slade, 2001 BKININSC.RVW 20010511 email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer