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…
At least 20 Berkeley High School seniors (hopefully, graduating) are apparently involved in a grade altering episode. The grade program is accessible to only about 20 employees, who must use *two* passwords. (Wow, that is REAL security!) But one of the computers was most likely left logged in and unattended. One student admitted paying $10 for the change. [Source: article by Meredith May, *San Francisco Chronicle*, 15 Jun 2000, A26]
A US federal jury today found that an aviation computer software company and a flight-computer manufacturer contributed to the 1995 crash of an American Airlines jetliner in near Cali, Colombia. 159 out of 163 passengers were killed. The jury said Jeppesen was 17 percent responsible, Honeywell 8 percent at fault, and American Airlines 75 percent responsible. Honeywell attorneys believe the pilot guessed by punching in the first of 12 options for navigational beacons sharing the code letter R instead of the correct code "Rozo", which would have carried the jet straight down a valley into Cali. The first "R" turned the jet toward Bogota, and the intervening mountains. It turns out that 95 of 8,000 navigational beacons worldwide were not coded in the database as beacons. "Rozo" was stored in another file. Apparently, Jeppesen understood the risks. 11 months before the crash, one of their memos states: "The situation with this group of navigational aids has reached a boiling point. We will have to act now to meet our customer needs." Another unfortunate example of the risks of doing nothing when safety critical problems surface. http://abcnews.go.com/sections/travel/DailyNews/Software000613.html Scott Lucero
Watching a few nights ago on Channel 4 in the UK, I saw a programme called Equinox on flight data recorders (black boxes) and and the "failures" of these to identify the cause of accidents, especially when only recording a few parameters. The case against Boeing was put, when the company adopted a different interpretation of the data, because not enough points were available to actually determine exactly what happened at certain times. This is all somewhat emotive as it was connected with the 737 rudder deflection crashes. However one view put forward was that real-time telemetry would ensure that potential problems could be spotted as they happen and this would move the problem of crash investigation from autopsy mode to crash prevention. I myself remain unconvinced. For a start to get all the real-time data logged and monitored would be a huge effort, requiring lots of technology and be expensive and hence resisted. Secondly when a problem strikes, although the pilot may have incomplete or no information about the cause s/he is the person up there where the problem is. The ground monitoring staff will only see one side of the issue and I can see a conflict between their views and the flying crew. Telemetry may well work well for the USN and test pilots or for space missions like Apollo (13 in particular), but when there are so many planes flying, will it really work as well? Any failure to get the real-time data could also lead to issues of whether a plane half-way across the ocean should fly on or turn back. However British Airways does have a system of recording lots of aircraft parameters on recorders on the flight deck. The tapes are played back after the flight to see if issues occurred and to monitor the state of the plane. This seems to be a way of spotting problems and following trends, so that fault prediction can be done and the risk of crashes reduced. Planes will always crash, often due to human error and almost always due to unforeseen circumstances. By ensuring that the flight data recorders store enough data and that a quick access means such as a separate data recorder in the cockpit is available so data is collected easily from each flight, it will be possible to reduce the accidents and provide a better chance of uncovering the cause. Relying on technology like real-time telemetry to be a magic bullet is folly. Global Research Information Systems, Glaxo Wellcome Medicines Research Centre Gunnels Wood Road, Stevenage SG1 2NY UK +44 1438 76 3222 w0400@ggr.co.uk http://ds.dial.pipex.com/lordjohn/ and http://www.lordjohn.demon.co.uk/
J.P. Morgan & Company (worth $21 billion) lost its Internet connectivity on 13 Jun 2000 because they failed to pay their $35 bill from Network Solutions for their jpmorgan.com domain: three bills ignored over six weeks. All of their Net customers were affected. (Last year Microsoft failed to reregister a domain name necessary for Hotmail service, although a computer consultant bailed them out by paying the fee for them.) [Source: Article by Patrick McGeehan, 14 Jun 2000; PGN-ed]
CobraServ (a service company that handles health insurance payments) sent me a "you didn't pay so we're going to cancel you" letter dated June 7th. Yet when I call their automated voice response system it happily tells me that my last payment was received June 5th! Almost makes me want to go back to the British National Health Service.
The story "When Background Checks Go Wrong" on http://slashdot.org at http://slashdot.org/article.pl?sid=00/06/07/211250&mode=thread is about someone who couldn't get a job because of a mistaken felony arrest that appeared on her record, and discussion of liability for the employers and private investigators. Many, many people weigh in on the commentary with their own experiences with mistaken background checks, and I post my own experiences in being mistaken for other Michael Crawford in the same schools, at the same companies, and in the arts (hint: I didn't star in Phantom of the Opera). BTW, I try to refer people to Risks sometimes on Slashdot. I think it would be helpful if more risks readers would post on slashdot and refer the readers to relevant issues of Risks. Slashdot is a very high-visibility site in the open source community and I think they could use the sober realizations that come from reading risks when writing more open-source code. Michael D. Crawford crawford@goingware.com http://www.goingware.com
I work for a large, multinational telecomm and computer firm based in the western USA. We have a standing contract with a large US-based printing and stationery firm to produce all our stationery, letterhead, business cards, etc. Having recently obtained a number of industry certifications (something I studiously avoided doing for the past 15 years, but I now find myself employed by a company which cares about these), I decided it was time to update my business cards to reflect these certifications. I followed the links from our company intranet site to the printing firm's B2B site where we can order such things. I was prompted for some information, including my Human Resources ID (HRID) and password. Well, its been two months since I ordered anything, so I'd forgotten my password. They offered a helpful "Lost your password?" link, which led me to another screen where they asked from the E-Mail address I had used. I tried all my E-Mail addresses, none of them were accepted by the system as a valid E-Mail address to send a password to. OK, fine. I called the toll-free help #, and spoke with a nice woman. I explained the problem to her, and she immediately grasped it. She suggested that I return to the main page and enter a whole new record, using a new (fake) HRID. This seemed redundant to me - I already had a valid system record with all my demographic information, and I wasn't enthused about re-entering all that information. Couldn't she just reset the password? No, she explained, she had no access to that, and had no idea who did. The only way for me to get back in would be to totally re-create my user profile, using a faked HRID. Risks: B2B e-commerce is great, but systems need to have competent human backups. The help phone # was basically the printer's sales line. The staff there knew about the WWW site, but had little technical information on it. Too, if HRIDs can be faked, then its child play for anyone to get business cards showing them to be employed by my company, whether or not they are actually employees. Finally, there as only one mechanism for triggering the forgotten password service, and that was based on E-Mail address. However, the system evidently keyed its records on HRID, because when I re-created my user profile, everything was the same as I had previously entered, except for the fake HRID (when I originally tried to re-create my user profile, I used my actual HRID, and it told me the record already existed). There's no good reason to my mind that the system should key off of HRID but use the E-Mail address for triggering the forgotten password service. In all, I found this printing company's B2B WWW site a good example of how NOT to implement B2B services. Dave Bank dirk@NOSPAM.psicorps.org
Reliable Software Technologies has just released a new program (JustBeFriends) designed to prevent e-mail macro viruses from spreading. It can be used along with or instead of the Microsoft supplied e-mail protection patch. JustBeFriends works will all versions of Outlook and Outlook Express, and is substantially simpler than the Microsoft patch. For full details, see http://www.rstcorp.com/news/jbf.html. E-mail viruses spread by exploiting existing mail programs to send themselves to a large number of new recipients. In addition, many viruses may also modify or damage the computer on which they are run. While most home and office computers are not sufficiently secure to make preventing damage to files on the computer possible, it is possible to make sending e-mail from scripts much harder. This move limits a particularly nasty way that viruses propagate. Both Microsoft's security update and JustBeFriends succeed in disabling script-based e-mail. Microsoft's approach works by internally controlling access to a large number of subsections of Outlook that can be used to gather e-mail addresses or send e-mails. Unfortunately, in order to prevent future e-mail viruses, this list of protected objects needs to be exhaustive. E-mail addresses may still be exposed if they appear in signatures, message bodies, or other documents. Future methods for exploiting flaws in Outlook to send e-mails are likely to be found. JustBeFriends works by controlling the ability of other applications to access Outlook or Outlook Express. In the event that the access comes from a script being run from the desktop or from an attachment, the access is denied. Otherwise, the user is asked to confirm that the application should be allowed access to Outlook. JustBeFriends was developed primarily by Tim Hollebeek, Research Associate at RST Labs. It makes use of advanced technology developed in part under a DARPA grant titled "Sandboxing Mobile Code Execution Environments".
Someone at out company wrote a short MS Word document (just a handful of pages) and e-mailed it, as an attachment, to several people in the company. The document contained several screenshots. For some reason, MS Word stores these images in a *completely* uncompressed format. The result was a 20Mb document which expanded into a 26Mb e-mail message. This message was too big to be delivered via modem: the pop3 server kept timing out after about 20Mb worth. The kicker is that when I finally downloaded the document via a fast internet connection and ran gzip on it, it compressed down to just 180Kb! That's a factor of over 100 to 1 compression from just a few seconds of effort. With just a few mouse clicks you can bloat your word document to multi-megabyte network-spamming size and send it to hundreds of mail boxes. There are any number of lossless image compression formats, plus any number of general purpose file compression algorithms, any of which would make a huge improvement. Even the dumbest run length encoding would make a big difference on a screenshot. But Microsoft just doesn't care: (*) Their image file format doesn't compress images; (*) MS Word doesn't compress files when it stores them; (*) E-Mail attachments are not compressed. As RA Downes says: > It's professional pride on the one side — and "who cares?" on the other. Martin.Ward@durham.ac.uk http://www.dur.ac.uk/~dcs0mpw/ Maintainer of the G.K.Chesterton web site: http://www.dur.ac.uk/~dcs0mpw/gkc/
While I generally agree with Mr. Downes that software bloat is undesirable, unnecessary, and often quite easily prevented, I take exception to the manner in which Mr. Downes and Bloatbusters make their case. For example, they do not use the same standards when measuring the size of their own code as they do when measuring the size of 'bloat' examples. Bloatbusters claims their replacement for Solar Winds' DNS resolver is only 7k. In fact it also depends on MSVCRT.DLL, the Visual C++ standard library, which is 288k. It would be reasonable to claim that since this file comes with Windows, it shouldn't be counted against Bloatbusters' totals - yet they count this file in totals where their agenda calls for a higher figure. The case against bloat is clear enough without resorting to this sort of accounting trickery. I would also like to contest Bloatbusters' claims regarding the Delphi programming language. It is certainly true that if you naively load Delphi and create a project with a single form, you will link in a lot of stuff you don't need. The same is true of an MFC application in Visual C++. The conclusion to reach is not that Delphi can only produce bloated applications, but that bloat reduction requires skill on the part of the programmer. Bloatbusters at one point refers to the size of a minimal windows GUI application, capable of displaying a window, closing itself, and nothing else. I have coded this application in both Visual C++ 6.0 and Delphi 5.0. In C++ it is 63 lines of code and a 24k EXE. In Delphi it is 59 lines of code and a 17k EXE. (Source available on request via e-mail.) These applications are very much identical line-by-line, do not depend on any external libraries or DLLs other than Windows itself, and behave identically. I believe these are the smallest possible self-contained Windows EXEs sizes for each environment. If, as Bloatbusters' site claims, "Delphi means BLOAT," then why is the Delphi app smaller? However, having gone to the trouble of writing these applications, it occurs to me that I am departing wildly from my normal style of programming in both Delphi and C++. I have not actually coded a message loop in several years, and would not expect to do so outside this contrived example. If I were writing a GUI application of any complexity, it would be frightful to consider writing it with nothing but C message loops and massive switch statements. Not only would the initial development require much more programmer effort, it would be far more difficult to maintain once complete. Windows applications had to be written this way in 1988 because there were no better tools. Today, I would consider it unforgivably irresponsible to code this way. Good management of software development risks is a very hard thing to do, and certainly, excessive code bloat represents a real risk to eventual maintainability and supportability. But it is not the only one or the most serious one. Writing code in such a way that mid-level programmers inspect and understand it in relatively short time periods is at least equally risk-preventive. Sacrificing every other consideration for the pursuit of small EXE sizes is really not the right thing to do.
> Things can be done right from the beginning, or even if not, corrected in > a negligible envelope of time. On the latter, minor point I disagree. It is *not* always trivial to eliminate bloat once the program is written. Many times it is, but sometimes it requires serious reworking of the program. Done properly to begin with, it's not only as easy to deflate as to bloat, in general it's easier just because it involves thinking ahead about the design. It's a good example of the old maxim "if you don't have time to do it right, where are you going to find the time to do it over?".
> This is a savings of 83,968 bytes, or well over half the original image > size. This is a new image only 45% the size of the original. And in less > than ten minutes. I got 83,968 bytes of bloat off my disk that fast. However, this ten minutes didn't include any regression testing so you could have at least some confidence that your refactoring of the code didn't break anything, let alone enough confidence to ship it knowing that there is 100% backwards compatibility (and willing to put your reputation and/or money on that guarantee). The real cost isn't in the 10-minute fix; it's in verifying the 10-minute fix. That is the RISK. > If this doesn't prove that bloat is inexcusable, I'll just have to send > more examples. Like everything else in software, it is a tradeoff. Let us look at the cost of hard drive space. A 20G drive can be gotten for $170. That is $8.5/GB which is less than 1 cent/MB. Your fix is worth, at best, a fraction of a cent to your customer. If this causes you to slip shipping by even one day, you've made a bad decision to work on it. Now there are places where code space isn't so cheap and this is worth doing. I've worked on projects in the past where reducing the number of floppies our product had to ship on was a significant cost savings. OEMs might want a smaller package to duplicate as they can increase the number of systems they can build per hour. Many embedded devices have a limited amount of ROM and RAM, and it is worth the effort to tighten the code up to get it to fit. > It's professional pride on the one side — and "who cares?" on the other. That isn't it. It is about knowing when it is worth taking the RISK and spending the time to reimplement working code and retest it. All the best software engineers that I know take their professional pride in making that decision correctly as well as when they reduce the bloat. Nevin ":-)" Liber <mailto:nevin@enteract.com> (773) 961-1620
> Southern Pacific Railroad INternal Telecommunication I thought the N expanded to 'Network', myself, but... Gee. Isn't anyone catching the *real* risk? Or do I just hang out on NANOG too much? The problem with putting high-cap fiber next to railroad tracks is that the trains tend to fall off of them occasionally... and there's no good place to put the backup fiber, precisely because of the reasons you wanted to put the fiber by the tracks in the first place. RISKS of assuming you've discerned all the RISKS? Jay R. Ashworth, The Suncoast Freenet, Tampa Bay, Florida +1 727 804 5015 jra@baylink.com http://baylink.pitas.com
Sprint did indeed start out as the telecommunications division of the Southern Pacific Railroad, As Douglas Jones mentions, but with an important difference. By the time SP began to resell some of its capacity to other businesses, they were not selling wires or access to wires. They were selling capacity on Supergroup 2 in the microwave system that paralleled the tracks. The acronym is suspect, also. When SP spun off the communications company, its official name was SP Communications for the first few years. It was only later that they changed the name to Sprint. Chuck Charlton, Manager, Facilities Operations Work Support Center 650.723.5225 voice 650.723.0823 fax 650.867.8057 cell/pager
The Dutch railways have been participating in a Dutch telecommunications company, and have been doing this for quite a few years already. It is very interesting to see this happen in India of course, but it is far from a new concept, and the pilot is likely aimed at local implications of this, and not at the technology as such. Bart van Leeuwen bart@ixori.demon.nl - http://www.ixori.demon.nl/
Indeed, Japan Telecom did the same thing with Japan Railways capacity in the early 90s...
Digital Watermarking
BKIHTSDW.RVW 20000504
"Information Hiding Techniques for Steganography and Digital
Watermarking", Katzenbeisser/Petitcolas, 2000, 1-58053-035-4
%E Stefan Katzenbeisser
%E Fabien A. P. Petitcolas
%C 685 Canton St., Norwood, MA 02062
%D 2000
%G 1-58053-035-4
%I Artech House/Horizon
%O U$69.00 800-225-9977 fax: 617-769-6334 artech@artech-house.com
%P 220 p.
%T "Information Hiding Techniques for Steganography and Digital
Watermarking"
Steganography can be used for sending encrypted messages, but the primary
emphasis in this volume is in the use of techniques for detecting forgery,
theft of intellectual property, and modification of a digital object.
Digital watermarking is probably best known to the general public from the
transparent logos used on cable channels to try and prevent, or at least
identify, illegally taped copies of programs. Chapter one gives us a
definition of steganography and digital watermarking, some history, and some
editorial on the counterintuitive links between the technical partnership of
encryption and digital signatures.
Part one outlines secret writing and steganography, the latter being the art
of hiding a message in plain sight. Chapter two deals with the principles
of steganography. Unfortunately, while the general principles are
explained, the details require some number theory. The formal definitions
that are used, for example, refer to axioms that are not presented in the
text. Most of the techniques explained in chapter three are graphical, but
a few are applicable to text. Steganalysis is, of course, dependent upon
the techniques being used, and various products are analyzed in chapter
four.
Part two looks at watermarking and copyright. Chapter five examines
watermarking principles and evaluation criteria. Techniques are described
in chapter six. Chapter seven deals with the reasons that copyright marking
technologies require highly robust algorithms and systems. Chapter eight
reviews digital fingerprinting, for individual identification. Legal
considerations are discussed in chapter nine, in regard to watermarking, the
Internet, and copyright.
A common problem in many collective works is that the various submissions
have differing styles and tend to overlap and repeat topics. While there
are certainly stylistic differences between the chapters in this book, the
authors/editors have kept repetition and duplication to a minimum.
copyright Robert M. Slade, 2000 BKIHTSDW.RVW 20000504
rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Third International Workshop on the Recent Advances in Intrusion Detection October 2-4, 2000, Toulouse, France, in conjunction with ESORICS 2000 This workshop, the third in an ongoing annual series, will bring together leading figures from academia, government, and industry to discuss state-of-the-art intrusion detection technologies and issues from the research and commercial perspectives. RAID 2000 is being locally organized by ONERA in Toulouse, France, in conjunction with ESORICS 2000 (http://www.cert.fr/esorics2000/). The program committee invites submission of extended abstracts, to be made available on the RAID website. Registration is available online at http://www.raid-symposium.org/raid2000/registration.html. A preliminary program is available at http://www.raid-symposium.org/raid2000/program.html. [This is abridged for RISKS, but it did not mention that the advanced registration deadline is 16 Aug 2000. PGN]
Please report problems with the web pages to the maintainer