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…
The (London) *Times* 21 Jan 1997 carries a report of the court case concerning whether the use of headlines taken from the *Shetland Times'* web site, as links back to the stories at that site, was a breach of copyright. This article is carried in full in the electronic version of The Times, at http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?1069542 though it may be necessary to register to get it by going in through their front door - which is at http://www.the-times.co.uk/ Since it is not a breach of copyright to make short extracts from an article which is in copyright, I quote: The inclusion of the headlines of one newspaper in the internet website of another newspaper was, prima facie, infringement of the copyright belonging to the original newspaper. Lord Hamilton, sitting in the Outer House of the Court of Session, so held, granting interim interdict in an action of declarator of infringement of copyright and interdict at the instance of *Shetland Times Ltd* against Dr Jonathan Wills and another. This was under Scottish Law, and I'm not sure what an "interim interdict" is, but it sounds painful for the people who were doing the copying. However it would seem that the judge was sympathetic to *The Shetland Times* because: A caller gaining access to the defendants' website might, by clicking on one of those headlines appearing on the defenders' front page, gain access to the text as published and reproduced by the pursuers. Such access was gained without the caller requiring at any stage to gain access to the pursuers' front page. Thus access to the pursuers' items could be obtained by by-passing the pursuers' front page and accordingly missing any advertising material which might appear on it. This of course is pretty much what I'm guilty of, I guess, by giving you the direct URL of the report in the Electronic Times! :-) What isn't clear to me from the article is whether it would be a breach of copyright to link to the articles without using the exact text of the headlines. [<http://www.ukoln.ac.uk/ariadne/issue6/copyright/ > has an earlier report.] Brian Randell, Univ. Newcastle, Newcastle upon Tyne NE1 7RU UK +44 191 222 7923 Brian.Randell@newcastle.ac.uk http://www.cs.ncl.ac.uk/~brian.randell/
Lucky Green is right in RISKS-18.75. Security fixes and virus-protection software are now export-controlled. Under the old ITAR, virus-protection software was part of the list of *exempted* crypto software in XIII(b)(1)(ix). Even if it used crypto, it wasn't embargoed if the software's purpose was protection against malicious code. In the new EAR, such software is specifically included as export-controlled under category 5D002 — even if it doesn't include crypto! It's now illegal to build worldwide products that are designed or modified to protect against malicious computer damage. This sounds like a manufacturer can't even fix bugs in their products if the fix eliminates a security breach, since the fixed product is "modified to protect against malicious computer damage". This is not a joke. Everybody, it's time to call your lawyers... It looks to me like the Information Warfare hawks have shot themselves in the foot. They were probably trying to prevent American products from defending foreign countries against infrastructure attacks by the US military. Instead, as usual, they just leave our own infrastructure wide open to attacks. I encourage companies to comment to the Commerce Department about these new regulations. They are listening for comments by Feb 13th; see the web reference below for details. Don't expect your comments to change anything; the NSA (which is pulling the strings here) seems to *want* the US to be wide-open to both wiretapping and active attacks on computer-based infrastructure. John [David Holland's contribution to RISKS-18.76 gave an http address that pointed to a draft version. John points out that the www.epic.org URL is correct, and so is http://jya.com/bxa123096.txt.]
The US FAA has issued a proposed airworthiness directive for Airbus A320/321 aircraft, that the elevator/aileron computers (ELACs) be replaced with upgrades, to prevent uncommanded rolls during turbulence and with specific flap configurations. This is based on field reports forwarded to the FAA by the Direction Generale de l'Aviation, the French FAA equivalent. Apparently, uncommanded rolls of up to 30\deg bank were experienced. It seems the upgrades are software upgrades, as might be expected. The FAA is quoted by Aviation Week (Jan 20, 1997, p40) as saying that there are circumstances in which the sensitivity of the FBW design "creates safety concerns". Examples of such include * Air turbulence, with partial or full flaps set, can induce roll oscillations; * If full flaps are extended and subsequently jam, and partial flaps are then selected, it becomes difficult for the flight crew to maintain the selected flight path (this is surely a reference to the Dragonair incident of 6 June 1994 in Hong Kong - see Flight International, 18-24 January 1995, p40). * When contaminants interfere with operation of the sidestick transducer unit, transient signals from the sidestick to the ELACs may induce the ailerons to `jerk' and induce an uncommanded roll, regardless of selected autopilot mode or phase of flight. The reference to autopilot modes is included because the ELACs are the EFCS's interface to autopilot functions. The A320 Electrical Flight Control System consists of seven major computers: two ELACs, three Spoiler and Elevator Computers (SECs) and two Flight Augmentation Computers (FACs) (info courtesy of Robert Dorsett and Peter Mellor). This proposed Airworthiness Directive is one of only two public documents of which I am aware which details problems with the A320 EFCS. The other is the report of an incident at Sydney (Kingsford Smith) Airport in August 1991 by the (Australian) Bureau of Air Safety. In this BAS report, some user-interface anomalies with the sidestick controllers were noted. The copilot had relinquished control to the captain on an emergency go-around, had left his hand on the stick but was unaware of making any inputs. Nevertheless, the DFDR recorded copilot inputs (both neutral and nose-down pitch) for some 12 seconds. Excerpts from the report may be found in `Computer-Related Incidents With Commercial Aircraft' <http://www.rvs.uni-bielefeld.de>. I should include the usual caveats: * Problems in control systems which are implemented by digital computers are not necessarily problems properly to do with the computers. I would guess that the first A320 problem above falls in this category. According to the reports, so did the second accident to the Swedish Gripen aircraft (see Fredriksson, RISKS-15.26 and Shafer, 14.89; following Eriksson, 14.81; Thomas, 14.82; Everett, 14.85; Ladkin, 14.88; and Stalzer, 15.04), and the X-31 accident (Ladkin, 16.89; Fuller, 17.45; Gomez, Fuller, 17.46; Fuller, Ladkin, 17.47; Mellor, 17.60; Wright, 17.65) * The fact that there are software upgrades does not automatically mean that the software was in some sense `wrong'. Such hardware is, loosely-speaking, general purpose, and one can make substantial control system changes the `easy' way, by reprogramming. Compare this with the time and expense of having to develop whole new actuators and integrate them into the airframe, as Boeing is now doing with the B737 rudder assembly (see `Computer-Related Incidents..'; also Aviation Week Jan 20 1997, p40; Flight International, 22-28 Jan 1997, p4). Having said that, two of the remarked situations represent control anomalies of a sort which may not occur with non-digital control systems. The Dragonair incident went unreported in RISKS. The flight-control computers responded to pilot inputs in a different mode from that in which the aircraft was *in fact* configured. Crudely speaking, the computers `thought' the aircraft was flying under partial flaps, whereas in fact the flaps were full down. In the third situation, contaminants in the pilot controls cause jerking of the control surfaces without feedback to the pilots. This is less clearly a circumstance which arises only with digital flight controls: for an example with conventional control systems, consider the B737 rudder hard-overs (incidents have been verified, and both the two unexplained B737 accidents are suspected cases). However, in a conventional control system, contaminants *at the pilot's end of the system* would normally result in direct feedback to the pilots. One would also expect different types of contaminants to cause problems (no, I'm not imagining that A320 sidesticks are susceptible to cola and coffee....). However, I suspect any case for considering different types of contaminants to represent different failure modes must rest on substantial differences in the type of contaminant and whence it came. Peter Ladkin
One of my first 'big' projects for Mount Allison was a web interface to the Student Information System to provide access for faculty & students. During the design stage I tried to be very careful about access control and possible attacks. In December, four months after the system was in place, a student informed the HelpDesk that she wasn't receiving the correct transcript information when she requested it. She was in fact getting someone else's marks. The source of the problem was quickly traced to the fact I had used the 'strstr' function when I should have written my own function to match the complete username. The user 'mcl' was getting the transcript of 'bmcln' instead because 'mcl' is a substring of 'bmcln'. The second problem came when I 'fixed' it. I was not careful and provided a fix with worked only for half of the cases. Finally, another student reported having problems with getting the wrong transcript, and I fixed it in all cases. The risks here include; using a debugged prepackaged function when it isn't appropriate. I knew the function's operation, I just didn't apply it correctly to my program, writing a program without a set of test data to search for mistakes. I only created test data to see that it 'worked', not looking for mistakes. Finally when fixing a problem, I only tested the known weakness, I did not look for other existing or new weaknesses. I can see why the quality of software is considered so poor. Computer Science and Programming courses do not stress testing and design specifications enough. They focus on making a program that seem to work in at least one test case. Certainly some courses do, but I completed an entire university degree including computer science without having software testing stressed in any of my courses. I am not talking formal validation, but "stress tests" used in various other engineering fields. Design specifications? Professors often gave assignments which left several points open to interpretation. Teaching by example? It is bad enough that most books and instructors do not include examples which check to see if a function failed, letting students assume 'malloc' always works. OldRisks: Does publicizing the fact I had a system 'live' which had a serious security flaw risk future jobs opportunities because of search tools such as DejaNews? Or my poor spelling? Michael C. Taylor <mctaylor@mta.ca> Programmer, Mount Allison University
Year 2000 is coming earlier for users of Apollo workstations. At 14:59 GMT on November 2, 1997, the high bit of the Domain/OS system clock will become set, and system bugs will prevent machines running unpatched software from booting. HP has released a fix, but it only runs on newer equipment, and has a bug of its own. Users of Apollo machines built before the dn3000 will simply be out of luck. Details are available at <http://pisa.citi.umich.edu/date-bug>.
Macintosh users probably have less cause for concern about the year 2000 than any other computer users, thanks to Apple's farsighted programmers. Originally, Macs stored the date as a 32-bit number representing the number of seconds since January 1, 1904 - a scheme that wouldn't come unstuck until February 2040. But Apple's programmers decided that wasn't good enough, so modern Macs use a signed 64-bit value that can cope with any date between 30081 BC and 29940 AD - more than enough for the time being. [Excerpted from Newsbytes, Connected, Electronic Telegraph, 21 Jan 1997] <URL:http://www.sat-net.com/L.Wood/><L.Wood@ieee.org>+44-1483-300800x3435
A certain set of hospital accounting packages designed in 1967 and first released in 1968 stored dates (both current and date of birth) as a signed 16-bit field representing days before or after January 1, 1900. The field overflowed in September 1989. In 1967, no one could imagine as S/360 Assembler routine being in use 22 years later. When one large service bureau had a failure because of this problem, it made *The New York Times*. Art Schor [Another instance of an old story in RISKS. PGN]
Dan Bernstein suggests keeping time in a 64-bit integer. I prefer a floating-point format — a double-precision (64-bit) float number that counts either the number of seconds or number of days before/after a given "epoch" date. The advantage of this format is that, while it's most accurate in the neighborhood of the "epoch", it can represent dates roughly covering the lifespan of the universe. Dan Hicks http://www.millcomm.com/~danhicks [Join the Navy if you want a floating date. ``Epochs on both your hawsers.'' PGN]
When Yahoo!'s People Search page (http://www.yahoo.com/search/people/) first premiered, it allowed you to look up information based on first name, last name, city, state, and phone number. Yahoo! has since removed the reverse phone number lookup, stating in their FAQ: What happened to the "search by telephone number" feature? We have elected to discontinue the reverse lookup feature because of privacy concerns that have been raised by users. However, this is not actually the case — it's still there, just in a different form. You see, Yahoo! also allows users to suppress information about themselves, by entering their phone number (http://www.yahoo.com/search/people/suppress.html). When you enter your phone number, you get a listing containing your name and full address. By using this, you can still perform a reverse phone number lookup. -DaVe mccomb@interworld.com Manager, Network & Security http://www.interworld.com/
Anders Andersson (Leaking WWW surfer interest profiles, RISKS-18.77) observes the possibility that the ad.doubleclick.net site, from a firm that sells space on a couple of dozen large web sites (*The New York Times* advertising column, 20 Jan 1997), may be in a position to save keyword lists submitted for search on the Alta-Vista search engine. What Anders Andersson may not have noticed was that when the browser called up the doubleclick site it returned more than an image; it also returned a cookie that doubleclick retrieves on subsequent accesses to its affiliated systems to develop a profile of Andersson's likes, dislikes, and usage habits. [See my item in RISKS-18.19 for more on these stealthy cookies.] Seems one without too much trouble could compile an incredibly detailed profile of an individual given one's footprints through webspace, coupled with one's search engine habits for those inconvenient times when the footprints don't lead to doubleclick's sites. A most valuable marketing tool. Howard Goldstein <hgoldste@bbs.mpcs.com>
I have recently noticed that many of my most commonly asked web pages (dilbert, altavista) regularly crash my graphical web browsers. Upon further investigation, I find that it is due to the advertisements inserted in these popular pages, linked to ad.doubleclick.net. (Presumably this is used by the page owner to generate some revenue.) The trouble is that the (apparently very redundant) web server used by doubleclick occasionally serves up a GIF gratuitously, rather than respecting the HTTP protocol. This seems to crash many versions of two popular graphical browsers. To compound the difficulty, doubleclick.net seems to have some difficulty processing mail. E-mail sent to webmaster@doubleclick.net bounced, at any rate, after several days. The exact RISK is a little murky, but the electronic medium of the web, and its enormous popularity, seems to have made it possible for one faulty provider to seriously damage the medium. Andrew Molitor, Network Systems
> There's also no guarantee that a message sent out actually arrives [...]
Neither is there any "guarantee" that a message sent on paper via the postal
service will actually arrive at the correct destination or that you'll hear
about it if it doesn't. We should be careful about our implicit
assumptions; here, the assumption seems to be that there's more of a
guarantee for paper mail ("P-mail") than for electronic mail ("E-mail").
I'm not convinced that's true.
How many times have you received P-mail that was addressed to someone else
but delivered to you because the postal service screwed up or the errant
mail was stuck to a piece of mail that was correctly delivered to you? I
doubt there are many adults in the United States who have not experienced
both of these on multiple occasions. To be sure, similar kinds of mistakes
happen with E-mail, but I've never seen any concrete evidence that they
happen more or less frequently than with P-mail.
(I have, on the other hand, seen anecdotal evidence that when the postal
service screws up, it often does so spectacularly. For example, I recently
sent a first-class, certified, return-receipt-requested letter from Boston
to New York. The postal service took 23 days to deliver the letter. When I
inquired at the sending post office before delivery about the fate of my
letter, they seemed surprised that I was upset about the delay, and mostly
clueless about what could be done about it.
And let's not forget the articles we see occasionally in the newspaper about
letter carriers dumping trailers full of mail that they didn't feel like
delivering.)
One worthwhile distinction between P-mail and E-mail is that when P-mail is
misdelivered, the culprit is more likely to be the postal service than the
sender. With misdelivered E-mail, on the other hand, the culprit is more
likely to be the sender (I'm not talking about failed delivery, which is
almost always cause by some sort of system failure; I'm talking about
delivery to the wrong person). What this says to me is that people are less
careful about addressing E-mail than they are about addressing P-mail.
When I address a P-mail letter, I check the address, return address and
postage immediately after I put them on the envelope. Then, I check them
again when I pick it up from the letter holder by my door to bring it to the
mailbox. Then, I check them again before I put it in the mailbox. How many
people are that careful about E-mail?
I take a somewhat callous attitude about misaddressed E-mail. "If you send
E-mail to the wrong place, it's your own damn fault." Many people disagree
and argue that it's the software's fault for not protecting the user from
making stupid mistakes, such as the cc:Mail E-mail address completion error
which was documented in another message in RISKS 18.77 as well as in
previous issues of RISKS.
I find that argument to be flawed. People send far more E-mail than P-mail,
Any features we put in the software to make addressing errors less likely
will make it take more effort to send E-mail. Users will say, "I don't want
it to be so hard to send E-mail," and they'll disable the features (or
become inured to them, e.g., always clicking "OK" to the "Are these
addressees correct?" dialog). In fact, people have *demanded* the features
which make it easier to address E-mail and which therefore make it easier to
*mis*address E-mail.
Misaddressed E-mail is going to keep happening until baby HAL grows up and
we have computers that are smart enough to look at what a message says and
to whom it's addressed and say, "You know, I don't think you intended to
send that message where you told me to send it." In the meantime, we should
all keep in mind the oft-repeated lunch-room-wall adage about E-mail.
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com
I once made a very embarrassing mistake, shortly after an internal job move, of sending a message (I thought) to my new boss, but in fact sending it to the old one, because they had the same first name, and out of habit, having typed "Alan", I went on to type the wrong surname. I made this mistake without putting stuff in the wrong field, without any inadvertent transposition, and without, even, any assistance from partial name matching - it was all my own work. And it got me thinking about how readily we try to slide away from the idea that we should check we've got it right before we hit the *send* key. A smooth riding, quiet car with a powerful engine makes it easy for you to exceed the speed limit, but the judge will rightly point out that you should have been more diligent in checking the speedometer. Mike Perry, Data General Ltd
Jerry Ackels <jerrya@us.ibm.com> was very helpful in explaining the source of the IBMmail problem noted in RISKS-18.77, and in ferretting out the hitherto unidentified offending address. Although *that* problem is resolved, there are many other lurking IBMmail addresses for RISKS subscribers with only a somewhat anonymous 8-character ID and no name; I suspect I will have more problems in the future. But now I know where to turn. Many thanks to Jerry, whose response follows. PGN
Here is the problem that we are facing. When you send a note to these users and get a message back saying that the user does not exist, it looks like two valid messages to us. IBMMAIL is basically a store and forward system. It provides for ANY to ANY seamless connections between mail systems. All of the SMTP mail IDs that you listed are actually SNADS IDs. The first two letters are the ISO country code that the user is from. The rest of the characters designate enterprise and user. Our machines translate this "Inter-Enterprise Address" (IEA) into a real userid and real node. That is, USFMC8LM is actually SSTARKEY at FORD. You sent the SMTP note to USFMC8LM@IBMMAIL.COM, which got to our Internet gateway and was translated into USFMC8LM at IBMMAIL, which got to our IBMMAIL machines and was translated into SSTARKEY at FORD. Then there is no way for us to tell what happened; this person could have left the company, changed userid or anything that would have deleted SSTARKEY from the AS/400 node FORD. MAILMAN is the userid on the FORD node that sent you back a note letting you know that the userid SSTARKEY did not exist. Our IBMMAIL machines received a note from MAILMAN at FORD, the address was changed to USFMCSQC at IBMMAIL, then it was sent to our Internet gateway and the address was changed to USFMCSQC@IBMMAIL.COM. As you can see from this lengthy explanation, IBMMAIL sees two messages going back and forth. Both of them are valid messages with no references to any problems. In this instance, there is really nothing that we could do. You tried to do the right thing by sending a note to the postmaster, you just had the wrong address. The one that should have worked is USFMCSQC@IBMMAIL.COM. [Apparently it did not. I tried it several times. PGN] This is the address for the MAILMAN ID at the system that was generating the error. There is a POSTMASTER@IBMMAIL.COM userid. It is monitored. [Yes, as I noted in RISKS-18.77, I also tried it several times. PGN] We have searched through the mail logs and could not find anything from your ID. I know the folks that monitor that ID. They do their best, but I am sure that you can imagine the kind of messages that we get. For every valid message, like yours, that we get we will get MANY that are bogus. Everything from "I am looking for my wife. I think she works for IBM, can you find her for me" to requests on how to get a job. It is these kinds of notes that make the POSTMASTER responses take so long. I assume that this happens to pretty much every service out there. We do our best to provide an excellent service, but we get thousands of these requests a week. Maybe you could put something about that in your newsletter. Let folks know that if we are spending too much time weeding through bogus messages, we don't have time to investigate and correct the valid problems. We are getting killed with vast numbers of messages, while only a VERY small amount of them are actually valid problems. Now I will get off my soapbox and let you know what we have done. If you run into a problem where you send to an incorrect IBMMAIL address, like the one in your note, or if an address is deleted, we will send you a note letting you know what the error is and the SMTP address in question. You probably have many more IBMMAIL users than you think. We also do HOST ALIASING. Our users have the option of changing their IEA address into a more user friendly Internet-style address. They can use their own domain of a sub-domain of E-MAIL.COM. And you will never know that the message is coming from IBMMAIL unless you look through the header and trailer info. We will send out the same error message for these users also. [...]
Please report problems with the web pages to the maintainer