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 leading Finnish newspaper Helsingin Sanomat <URL:http://www.helsinginsanomat.fi/> reported on 20 Apr 1997 that a paperclip dropped into a traffic-control computer stopped all trains in southern part of Finland for one hour Saturday 12 Apr between 22:30 and 23:30. The paperclip had been in the traffic control spare machine under the space bar approximately from Wednesday. It caused the machine to repeatedly request login for three days, filling the hard drive. After this, the spare machine started to hinder the work of the main traffic-control computer, which finally turned all the train control signs to "stop". A SW expert from the company that had made the control program found that a faulty keyboard was the reason for the incident and replaced the keyboard. The paperclip was found later in next Monday. VR Ltd Finnish Railways <URL:http://www.vr.fi/> claimed that the computer failure did not create any danger to the travellers. Jari M=E4kel=E4 [They were going at quite a clip until the Finnish ...? PGN]
There was a close call on approach to LAX on 16 Apr 1997, involving a KLM 747 inbound from Amsterdam and a Brazilian VASP MD-11 inbound from Osaka. The MD-11 pilot apparently failed to follow the air-traffic controllers' instructions for a tight turn on final approach, drifting across the approach route of the 747. The pilot of the MD-11 reportedly told controllers that the autopilot ``didn't make the turn.'' But the pilot is ultimately responsible, and an FAA spokesman said that the pilot could have overridden the autopilot. A National Air Traffic Controllers Association spokesman said that tapes suggested problems with the autopilot gear, although ``It could be the way they programmed it. It could be a crew oversight. It could be lots of things.'' [Source: A *Los Angeles Times* item, seen in the *San Francisco Chronicle*, 18 Apr 1997, A12]
In RISKS-19.07, John Brooks <jbrooks@peeras.demon.co.uk> discusses the issue of the accuracy of GPS and wonders if it increases the risk of collision between 2 aircraft flying reciprocal courses, as the aircraft can now follow that course more accurately than was possible with other navigation aids. Unfortunately, a mid-air collision has occurred in Canada between 2 commercial aircraft that was, in part, caused by both aircraft following reciprocal GPS courses. In this case, the altitude separation between the aircraft was lost as one aircraft was climbing away from the airport while the other one was descending towards it. This accident occurred near Soux Lake, Ontario, where there isn't radar coverage that could have assisted in ensuring that the planes were separated. In the report from the Canadian Transportation Safety Board, (available online at http://bst-tsb.gc.ca/air/ea95h0008.html) one of the conclusions listed was: The probability of a collision between aircraft using GPS on established air routes is significantly higher than between aircraft using conventional navigation aids because of the greater accuracy of navigation using a GPS. As a result of this, Transport Canada has suggested that pilots laterally offset their navigation tracks. However, I don't know if this has been standardized to ensure that all pilots are doing this consistently. Mike Rogers
Senators Dianne Feinstein (D, California) and Charles Grassley (R, Iowa) have introduced legislation that would bar commercial use of Social Security numbers and make it illegal for credit bureaus to disseminate Social Security numbers, unlisted phone numbers, birthdates, or individuals' mothers' maiden names. In the House of Representatives, Congressman Paul E. Kanjorski (D, Pennsylvania.) submitted legislation that would create a Commission on Privacy of Government Records and ban Social Security or Internal Revenue Service records from being posted on the Internet without an individual's written permission. [Washington Post 17 Apr 1997; Edupage, 17 April 1997]
RISKS-19.08 (techno-harassment) outlines the report of the case of a
Windsor, Ontario family plagued by someone who, apparently, bugged their
home and was able to break in on telephone conversations at will, change TV
stations, etc... all completely without detection, baffling security
experts.
This morning, CBC radio reported that the perpetrator ("Sommy") had been
caught — he was, apparently, the family's 15-year-old son. The supposed
high-tech telephone tapping was simply him picking up on another line in the
middle of a conversation.
In light of this revelation, I reread the original RISKS article. The
actions of a sinister stalker were transformed, on second reading, into the
very childish and inconsiderate running prank of an immature teenager.
With the sharpness of 20-20 hindsight, let me offer a few comments:
o Occam's Razor: The rather more exciting supposition that some nasty
person with a lot of complicated hi-tech equipment, long term schemes (in
order to have wired up the house for this kind of control) and sinister
motives was chosen before ruling out the far, far simpler, but certainly
less interesting possibility that someone within the home was doing the
dirty work.
o Square hole, round peg: Once you adopt that first assumption (hi-tech),
explanations not involving hi-tech (round peg) can't be entertained
because they just can't account for the bizarre behaviour.
o To place this in a computer RISKS context, this sort of thing happens all
the time in the software realm (a bug with mysterious magical symptoms
appears in that defies your debugging efforts). In order to understand
and fix the bug, you often have to re-evaluate you basic assumptions
about the nature and behaviour of the system in question (again, common
fodder for RISKS postings).
Ron Pfeifle
"Emeryville Horror" due to victimized family's 15-year-old son In what police apparently have suspected for some time, the "cyberstalker" who made life miserable for Dwayne and Debbie Tamai at her new house in Emeryville, ON, a small town near Windsor, was actually their 15-year-old Son Billy. [Stuff already reported in RISKS-19.08 omitted.] The family, in despair, put up their house for sale but had little hope of receiving a decent price for a house under attack. However, when police got permission to question Billy, he immediately confessed that he was entirely responsible for the mess. It had started off as a prank and he had been unable to stop it. The child is likely to receive psychiatric help. M. E. Kabay, PhD, CISSP (Kirkland, QC) / Director of Education, National Computer Security Association (Carlisle, PA) / http://www.ncsa.com
A while back [RISKS-16.74] I posted a similar bug story to risks regarding a
program which failed in October, November, and December because the numeric
representations of these months have two digits instead of one. One thing I
might not have mentioned in that post was that the solution mostly involved
"decoding" the interface. "Decoding" is a term some co-workers and I coined
to describe the process of taking unnecessary complexity out of computer
code. It's pretty amazing how some people can take a simple problem and
turn it into a complexity nightmare when code is involved.
In this particular case there was a whole big mess of C code using various
buffers, string copies, string concatenations, direct setting of characters
in strings, and numeric-to-string conversions to build a date string. I
can't remember how many lines of code existed when I started decoding it,
but I do remember that the decoded version was a simple switch statement
with three cases, each of which had one sprintf() call. The various buffers
used to hold all the intermediate pieces in the starting code resolved down
to one buffer.
I'm not the only one to notice that overly complex programming often
gets rewarded. By overcomplicating things, a few things can happen:
1) It takes more time to complete the task and usually requires
lots of extra hours. Hard work and long hours are often
perceived to be a good thing even if they're being spent on
something that wouldn't be necessary if the right solution
had been applied to the problem.
2) Overly complex code is usually very buggy requiring "heroic"
bug fixes (more hard work and long hours).
3) It's typically difficult for anyone except the person who
created the mess to really understand how it all works. This
increases that person's value and often elevates them to guru
status in the eyes of those who don't know any better.
I believe Rube Goldberg would have thrived as a programmer.
All the best programmers I've worked with have been good decoders. Not
coincidentally, interfaces these people write tend to be clean and simple.
Maybe decoding should be part of every college Computer Science curriculum.
Steve Sapovits N2K Telebase (http://www.n2k.com) E-Mail: steves@n2k.com
A friend of mine runs his own photographic processing business, and uses a certain OTS package for accounting, etc. The package in question has a name like some kind of herb, so let's call it PARSLEY. :-) My friend pays a maintenance charge which entitles him to receive automatically all upgrades to PARSLEY. He is aware of the Y2K bug, and asked his friendly support person which release of PARSLEY would be guaranteed "Millennium friendly". Well, er, ... , none, to be precise. There is something coming down the line which will be Millennium proof, but that will be sold as a new product, for which my friend must fork out a separate licence fee. Anyone else out there had a similar experience with herb-like OTS software? Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. +44 (171) 477-8422, p.mellor@csr.city.ac.uk [My *sage* advice is that *thyme* is running out. Although this kind of strongarm nonsense can really affect your *basil* metabolism, it seems to be an industry standard to force you to buy new versions. The anti-virus folks certainly make a *mint* out of it! PGN]
I wandered around the Royal Greenwich Observatory site for a few minutes, but couldn't find an explanation of the difference, if any, between GMT and UTC (on that site). The USNO clock, however, *does* show different times. Poking around here and there, you'll discover that almost everyone (except USNO) assumes that GMT is identical to UTC. For example, consider the Orlando Sentinel's timezone site at <http://www.orlandosentinel.com/hurricane/info/general/time.htm> where the USNO clock, reading UTC, is labelled as "London (GMT)" A site that appears to do PR for Greenwich, England, <http://www.longitude0.co.uk/why1.htm> reads, in part: "In 1880, Greenwich Mean Time was made the legal time of Great Britain" I'd really like to get an authoritative answer — it's starting to be as interesting as the "Is 2000 a leap year" question. Martin [Martin was not sure that this was RISKS-worthy. However, I liked it. PGN]
Labor costs for Year-2000 projects have risen 30% since last year, when they averaged $60 an hour, and they're still climbing, says an analyst at the Gartner Group. The revised labor cost works out to about $1.50 per line of code, up from $1.10, causing Gartner to up its widely cited estimate of $300 billion to $600 billion for all corporate Year 2000 projects. A study released by Morgan Stanley & Co. last week suggests that companies could save some money by replacing some code with packaged software and discarding some of the 35 million lines of code that are typical for a large company's computer system. Meanwhile, a study of 24 federal agencies by Federal Sources Inc. estimates that it will cost about $5.6 billion for the federal government to rewrite all of its code to be Year-2000-compliant. That's about 2-1/2 times higher than an estimate submitted to Congress in February by the Office of Management and Budget. (*Information Week* 7 April 1997; Edupage, 17 April 1997]
Although maybe not reported in RISKS, I have it on good authority that around 1988/89 a well-known financial institution experienced what could have amounted to a very significant loss of funds, but was fortunately confined (they believe) to test transactions, when their ATM system overwrote the transactions performed in the hour 'lost' when the clocks were put back.
>I see that type of "trusting" as qualitatively different ...
This brings to mind a discussion I once had with a McDonell-Douglas test
pilot about the risks of automated, "fly-by-wire" systems in modern
fighters. It seems the newer jets (e.g., F-22) are NOT designed to be
aerodynamically stable; an major electronic failure could result in the
aircraft literally falling out of the sky.
He argues that the electronics are designed with a greater safety margin
than other critical components. It is statistically more likely that a
control rod will break, for example, than the electronics and backup systems
will fail. Meanwhile, he says, there is an advantage in "being able to
update the performance characteristics with the next software download."
Risks, as follows:
1) Trusting computers to be more powerful than physical laws.
(aerodynamic stability vs. software control)
2) Trusting software engineers to deliver a "bug-free" product.
(Ariane-5, anyone?)
3) The potential of building a "glitch" into military hardware which an
enemy could reverse-engineer and exploit. ("The Death Star plans are NOT
in the main computer!")
Alan Hoffman Prepress consultant digital INK
> ... "the laws of physics are irrelevant, ... See the INFERNO series by Roger MacBride Allen (ACE Books, NY), where the author explores precisely these consequences of Asimov's Laws of Robotics. M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
http://server.Berkeley.EDU/BTLJ/articles/11-2/carroll.html contains a long article on legal issues surrounding spam that might be interesting to some afflicted readers. Summary: "This article considers the recognized means to avoid the tragedy of the commons--self-regulation, regulation by market forces, and government regulation--and concludes that some government regulation of unsolicited commercial solicitations in a unified medium is likely to be necessary and will be permissible under the prevailing interpretation of the First Amendment." Martin
On the risks of issuing NoCeMs I've been issuing NoCeMs for off-topic articles in several newsgroups (both global Usenet and the nyc.* hierarchy) since the summer of '96. I've received two legalese threats of legal action from posters of material that matched my criteria of being off-topic. 1. Michael Weir, a recruiter from Canada, insisted on posting job ads in an unmoderated discussion newsgroup whose charter prohibits job ads and resumes. He threatened to sue me for using his name in the NoCeM notices. He also posted a series of abusive flames about me. A search of DejaNews revealed several articles from him in Canadian newsgroups discussing his litigations and asking for personal information about a judge. Eventually he went away. 2. The "New York Theosophical Society" insists on posting in the local newsgroup nyc.seminars (usually used to announce, what else, seminars). One Bart Lidofsky responded to the NoCeM articles by saying: "I consider these messages to be a form of harassment, and will treat them as such." I have also seen several claims that the NoCeM notices themselves are "spam". Apparently, this term now applies to any traffic that the user doesn't like for any reason. I understand that other issuers of NoCeMs have also received threats, and at least one poster has been forging old-fashioned cancels for the NoCeM notices that mention his articles (another good reason to stop processing all old-fashioned cancels). Dimitri "co-proponent of news.lists.filters where NoCeM notices are posted" Vulis
Re: "Crack A Mac" contest (RISKS-19.07)
Martin Minow <minow@apple.com> Tue, 22 Apr 1997 07:51:33 -0700In a note to the RISKS moderator, Jonathan Thornburg <thornbur@black-hole.physics.ubc.ca> asked several questions regarding the Swedish "Crack-A-Mac" contest. I forwarded those questions to Joakim Jardenberg <joakim@infinit.se>, who was responsible for the contest, and he sent me some answers — which I have translated, changing Joakim's first person to third person so I can editorialize without putting words in his mouth. Jonathan asks: "Did the "around 30 minutes" installation time include the time taken to" find two small shareware programs on the net, download them, verify their digital signatures "to ensure the programs hadn't been tampered with, and set them up?" No, Joakim already had these products and had tested and evaluated them on another computer before installing them in the contest machine. The shareware programs were not signed. Jonathan: "Mac web servers may indeed offer excellent security and/or be easier to administer than some of their competitors, but if they require extra software add-ons to work reliably, then it's unfair not to count those add-ons when assessing security, ease of administration, etc." Joakim notes that installing add-on utilities is an ordinary and necessary part of a webmaster's everyday functions. This is in no way unique for the MacOS. For example, no operating system had built-in protection against "ping" attacks. Several vendors posted fixes on the Internet. Joakim wonders how many system managers who used these fixes to patch their system verified the patches using digital signatures? "To be honest, I [Joakim] think that these questions — attacks — are a bit silly as they don't have anything to do with overall system usability. I wanted to test a narrowly-focussed security area, and the Mac fulfilled my expectations. Look for some other tests in 'Crack-A-Mac, the Next Generation.'" - ----- I would point out that Jonathan's concerns are quite real, and will become more important as Internet-based software distribution becomes more pervasive. PowerTalk, a now discontinued variant of the Macintosh operating system, supported RSA digital signatures, and they are supported by the major Macintosh file archiving product. Both Java and Microsoft's Active-X support code signing which, ignoring the issues raised in several previous Risks posts, is will be an essential part of a well thought-out Internet distribution strategy. Martin Minow minow@apple.com P.S.: PowerTalk, in addition to supporting digital signatures and secure (encrypted and authenticated) networking, added considerable complexity to the MacOS, proved quite difficult to program effectively, and was not well-received in the marketplace. I suspect that many of the PowerTalk ideas will be re-invented and re-implemented over the next few years.
Addendum to DES Challenge RISKS (RISKS-19.09)
Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de> Mon, 21 Apr 1997 14:37:04 +0200 (MET DST)Apparently, the organizers of the Swedish effort have now come to the conclusion that a source code release is beneficial. According to their web page, they are working on a release which includes other kinds of integrity checks. Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
Re: 11-digit dialing (Seecof, RISKS-19.09)
Lauren Weinstein <lauren@vortex.com> Thu, 17 Apr 97 16:45 PDTMark Seecof reported on the availability of 11 digit local dialing in San Diego. Be warned that *counting* on this always working may be somewhat premature. Here in the (818) portion of L.A. over the last year or so, I've noted exchanges where 11 digit dialing of local numbers worked and others in the same area where it was impossible. Even worse, in some cases it would only work sporadically even in those exchanges where it had at one time been observed to function. The trend is definitely toward permitting 11-digit local dialing. The widespread introduction (delayed far too long, in my opinion) of area code overlays depends upon this functionality. But be careful about expecting such dialing to work every time at this point. --Lauren-- Moderator, PRIVACY Forum www.vortex.com
Reminder on Privacy Digests
Peter G. Neumann <RISKS moderator> 17 Apr 1997Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum is run by Lauren Weinstein. It includes a digest (which he moderates quite selectively), archive, and other features, such as PRIVACY Forum Radio interviews. It is somewhat akin to RISKS; it spans the full range of both technological and nontechnological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". PRIVACY Forum materials, including archive access/searching, additional information, and all other facets, are available on the Web via: http://www.vortex.com * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available.Please report problems with the web pages to the maintainer
xTop