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…
In the morning rushhour of 25 May 2006, circuit breakers cut out at 7:55am in Maryland, then in Queens, then in Philadelphia. By 8:03, Amtrak, New Jersey Transit, and (Baltimore-Washington) MARC trains were coasting to a standstill (without air conditioning, overhead lights, etc.). Four trains were stranded in the tubes under the Hudson River, another in a tunnel in Baltimore. By evening, Amtrak officials were still unable to locate the triggering event, although it was noted that some of the electrical transmission equipment dates to the 1930s. Service was expected to return to normal on 26 May. The impact on commuters was of course severe. [Source: Patrick McGeehan, *The New York Times*, national edition, 26 May 2006, C12; PGN-ed; Just one more reminder of the risks relating to an inadequately commitment to public transit, and the continued ability of single point failures to propagate? PGN]
Personal electronic information on up to 26.5 million military veterans, including their names, Social Security numbers, and birth dates, was stolen from the residence of a Department of Veterans Affairs employee who had taken the data home without authorization. [Comments about no evidence of data misuse (yet) and no health/financial records, but deeply embarrassing to VA. No mention of a statement that this incident was not reported for several weeks. The previous CardSystems Solutions breach in June 2005 was noted, affecting 40 million credit-card accounts. [Source: David Stout and Tom Zeller Jr., *The New York Times*, 23 May 2006 PGN-ed; yet another ...] http://www.nytimes.com/2006/05/23/washington/23identity.html?ex=1306036800&en=eb1c02a63fedca31&ei=5090
NASA's 800-pound Demonstration for Autonomous Rendezvous Technology (DART) spacecraft was supposed to circle a defunct orbiting Pentagon satellite. A report released on 15 May 2006 indicates that DART moved to within 300 feet of the satellite 472 miles above Earth, and then lost control — crashing into the satellite. The report says the collision was based on faulty navigational data from the main sensor that caused DART to "believe that it was backing away from its target" rather than approaching. Investigators concluded that DART had determined that it had spent too much fuel on the approach, because of the inaccurate data, and was in the process of shutting down when it collided. The investigation also concluded that the evaluation of fuel consumed was also in error (overestimated), and also faulted the mission's management style, lack of training and experience, avoidance of expert advice, and lack of internal checks and balances. [Source: Alicia Chang, AP item, Newsday, 15 May 2006; PGN-ed. Thanks to Lauren Weinstein for spotting this one. PGN] http://www.newsday.com/news/nationworld/wire/sns-ap-spacecraft-mishap,0,4358085.story?coll=sns-ap-nationworld-headlines
The National Transportation Safety Board has released a preliminary report on the 25 Apr 2006 crash of a Predator UAV while on U.S. border patrol. "The pilot reported that during the flight the console at PPO-1 'locked up', prompting him to switch control of the UAV to PPO-2. Checklist procedures state that prior to switching operational control between the two consoles, the pilot must match the control positions on the new console to those on the console, which had been controlling the UAV. The pilot stated in an interview that he failed to do this. The result was that the stop/feather control in PPO-2 was in the fuel cutoff position when the switch over from PPO-1 to PPO-2 occurred. As a result, the fuel was cut off to the UAV when control was transferred to PPO-2." http://www.ntsb.gov/NTSB/brief.asp?ev_id=20060509X00531&key=1
Dr. Brendan Nelson, Australia's minister for defence, has considered "getting out of" a billion dollar purchase of Super Seasprite helicopters, because "You could not have 100 per cent confidence in the software program that supports the pilot flying the helicopter to 100 per cent safety". He has upheld the ANZAC tradition of blaming the imperial overlords, US firm Kaman Aerospace and their subcontractors. Full story in "The Australian" of 15th May 2006, online at <http://www.theaustralian.com.au/story/0,20867,19136512-601,00.html>. Full disclosure: the author is a postgraduate student at an Australian university, and Dr Nelson was minister for education before he became minister for defence. [Dr. Nelson is obviously also not a RISKS reader, or he would have ample evidence that "100% confidence" in a software program — or even worse, in the system in which it resides — is impossible. PGN]
The Los Angeles Opera was supposed to have been presenting the world premiere of *Grendel*, a new opera by Elliot Goldenthal this Saturday. Unfortunately, computer problems have forced a delay. A press release issued today says ... "The technical rehearsals ceased on 23 May when computer malfunctions caused a large pivoting platform, central to scenery designer George Tsypin's large-scale set, to stop working, causing the platform's internal mechanisms to break. The platform, which uses 28 individually operating motors to move horizontally and vertically and pivot a full 360 degrees at a variety of speeds, must bear the weight of up to 15 performers at a time. Solving the malfunction of the computer system and correcting the failure has severely compromised the rehearsal time necessary for the success of the production, which demands extensive technical work." http://www.metoperafamily.org/operanews/news/pressrelease.aspx?id=1189 http://www.losangelesopera.com/pdf/press_release/Grendel%20opening%20postponed.pdf
From the CBC link at: http://www.cbc.ca/toronto/story/to-gotransit20060502.html Risks of an unprotected public electronic sign should be obvious... GO Transit signs insult PM, CBC News, 2 May 2006 Technicians with GO Transit are working to make its electronic message boards hacker-proof after the scrolling signs were programmed to read "Stephen Harper Eats Babies" over and over again. Officials say someone used an inexpensive remote-control device to tamper with the narrow advertising signs installed in the system's trains along the Hamilton-Toronto route. The message was seen on Thursday and Friday, and appeared again on three separate signs on Monday. Gerry Nicholls, one of the commuters who reported seeing the message, told the *Toronto Star* he thought he was "hallucinating" when he read it. None of the other commuters on the packed train seemed to react to it at, he said. As it happens, Nicholls is vice-president of the National Citizens Coalition, the conservative think-tank formerly headed by the prime minister. "I worked with Stephen Harper for five years and never once did he, in that time, eat a baby," he told the newspaper. Text messages destined for the scrolling signs are transferred from a computer to hand-held, remote control device that retails for less than $25. GO Transit employees then move from car to car with the device, transmitting the messages to the signs. GO Transit officials said they bought the signs six years ago and they were not password protected. It is the first time someone has hacked into the system, they said.
Being a pilot and armchair meteorologist, I woke up Tuesday morning and did what I do every morning. I check the weather. I have various sinks bookmarked and one of my favorites is the ADDS system at http://adds.aviationweather.gov/ They have a Winds/Temps page at: http://adds.aviationweather.gov/winds/ for which yesterday morning (Tuesday) the surface winds map showed this: http://www.benjammin.net/www/images/ruc00hr_sfc_wind.gif (saved on my website because I saved the .gif and mailed it to the site webadmins to let them know something was wrong even to my non-certified meteorologist eyes) They e-mailed back (rather promptly I might add) to let me know that in fact the National Weather Service got bad data that morning and that the graphic was in fact wrong. NWS was working on fixing it. Of course there was no mention on the website that something was awry with what I was seeing, but my own brain told me - "I don't think so!" Thus, an interesting failure of mechanisms that gather data and transform it into useful images for the rest of us. Mechanisms that apparently have no built-in method of error detection through a history of one input data set to the next. I just thought I would share with the rest of you. Ben Kamen - O.D.T, S.P. ben@benjammin.net http://www.benjammin.net
How many times have we seen this? How many more times will we see this?
The North East Ambulance Service is equipped with satellite navigation,
which comes with the usual AI for giving driving directions. Said AI isn't
fully informed on roads too narrow for the ambulance model. Said AI selects
for short distances without factoring for traffic patterns and driving
speed. Result: long delayed arrival at an accident scene and a delayed
arrival at hospital afterward.
In this case the patient's mother offered to point out a better route, but
was not allowed. A rapid response team that arrived before the ambulance did
could have stayed with the ambulance and led a better route, but didn't.
[Source: British SATNAV service misdirects ambulance, *The Mirror*.
http://www.mirror.co.uk/news/tm_objectid=17083544&method=full&siteid=94762&headline=sham-bulance--name_page.html
Also noted by Joel Baskin, who included this pithy quote:
The service's patient forum said: ``SATNAV can be effective when used
with local knowledge. But it shouldn't be relied on by itself.''
PGN]
The irony of the situation relating to proposals for required data retention, as I noted in: http://lauren.vortex.com/archive/000175.html is that many incredibly bad and dangerous concepts — like government-mandated data retention of this sort — will virtually always be linked to laudable ideas (like fighting child abuse) that we all agree are important goals. A cynical view would be to assume that this is done purposely to push "evil" laws using "noble" hooks. This clearly does happen sometimes. But I believe that in the majority of these cases we're dealing with legislators and others who genuinely believe in their causes, and either don't have the will or background to recognize or understand the horrible collateral damage that their proposals would do. Casting such persons as being purposefully evil is probably unproductive and unfair. Instead, we need to help them see the "big picture," rather than just the narrow focus of their good intentions. For after all, the road to hell still does indeed remain paved with good intentions. Lauren Weinstein: +1 (818) 225-2800 http://www.pfir.org/lauren http://lauren.vortex.com DayThink: http://daythink.vortex.com
Thursday, May 18th, I turned on my TV at 8:00 PM to catch the final episode of "That '70s Show" only to find static. Checking another TV and finding only static as well I reasoned my Comcast cable TV was out-of-service. I tried calling comcast (800-COMCAST) to report the outage and only received a message that there was an outage in my area (I think they use caller id for this as I have received this message in the past when calling) and due to unusually high call volume all representatives were busy. Since Comcast already knew of the outage I expected it to be resolved in a little while and decided to pay some bills and check e-mail while I waited. Only then did I find out that my Comcast Internet was out as well. This is the first time an outage has affected both services I receive from Comcast. A few calls to friends and family confirmed that service was out all over the Indianapolis area. Fortunately, as I was to find out later, my phone service is not through Comcast as it appears that all of Comcast's phone customers lost service as well. It turns out a very localized power outage was to blame for the outage. The Risk for customers? Putting too many eggs in one basket can cut you off from the outside world in a hurry. The Risk for Comcast? Never assume your backup generator will be there when you need it. Test, test, test for power outages before they happen. Some news reports of the outage: http://www.indystar.com/apps/pbcs.dll/article?AID=/20060519/NEWS01/605190512 http://www.theindychannel.com/news/9242765/detail.html
Interesting article on recent congressional testimony regarding use of SSNs: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9000482&source=NLT_AM&nlid=1 I wasn't there, but based on the article there seems to be a serious misunderstanding that the SSN is just fine as an *identifier*; the problem is that it also gets used as an *authenticator*. Switching to a different number (as the article discusses) that is used for both purposes will have the same problem. This quote sort of summed it up for me: "The Social Security number is the only unique identifier in our country that enables a credit grantor, or a credit bureau, or a bank, or an insurance company, or an investment firm to be sure that the consumer they are doing business with" is legitimate, according to Randy Lively Jr., CEO of the American Financial Services Association. In other words, they're using it as both an identifier and an authenticator. Until Congress understands the problem, there's not much hope of solving it through legislation.
> I still don't know enough about this class of potential accidents to offer > definitive comment. But from what I can tell, automobile incidents will > replace aircraft ones for the RISKS community. The more things change, ... Once again, aviation was there first. I can't seem to find any details after all these years, but there was an incident with, I think, a Fokker airplane some years ago. I'm pretty sure I read about it in Flight International and it happened in Europe (or, at least, not in the US). The WOW (Weight On Wheels) switch didn't make when the plane touched down, so the system wouldn't let the pilot throttle back. The pilot ended up going off onto the taxiway and then going back around onto the runway before bringing the plane to a halt, I think by pulling a circuit breaker. The impression the article gave was of an airplane zooming around on the ground while everyone else dove for cover. I don't even think this was a fly-by-wire airplane, just one with safety interconnects. Another bit of evidence illustrating why adding back-up safety systems can make the entire system more dangerous. See Perrow on "Normal Accidents", for example. The article about the ValuJet accident, in Atlantic Monthly, was one of the best I've seen on this. Mary Shafer Retired aerospace research engineer reunite.gondwana@gmail.com or miliff@qnet.com
(Daley, RISKS-24.26) Jim, I noticed your contribution to RISKS and just wanted to point out a possible misunderstanding re how PINs are encrypted in ATM nets. DES (or 3DES) keys are used in these nets to compute a message authentication code (MAC) as an integrity and authentication check on a transaction between and ATM and a bank. The PIN is then XORed with the MAC to encrypt it. Thus one is not encrypting the PIN by passing it through the DES/3DES algorithm, as your text suggested. Rather, the algorithm is generating a pseudo-random bit string by virtue of being used to compute the MAC on a transaction. Each transaction contains a serial number, ATM ID, user account number, and other parameters that make the transaction likely to be unique, relative to the key that is shared on a pairwise basis between each ATM and a bank. Steve
The same challenge existed for magnetic striped cards in the form of magnets and magnetic field devices. they didn't succeed for a few reasons: 1)zappers hesitated to attach when it inconvenienced them selves. 2) the stripe or rf device is a pointer to a remote data base. after the zapping, the remote data base is still easily accessible. 3) there are always counterattacks to the zapping such as reduce range sensitivity and signal shielding. jerome svigals (father of the magnetic striped card).
A note of some significance here in the Pacific Northwest is that a "Redd" (pron. "redd") is a place salmon carve out of a stream bed to spawn. This (perhaps more universal) definition does not show up on dictionary.com, but a web search of "salmon redd" will supply many hits. Dale Gombert <GombeDWG@dfw.wa.gov>, ITS4 WA Dept. Fish & Wildlife, Marine Resources, 16018 Mill Creek Blvd., Mill Creek, WA 98012-1296 1-425-379-2317 [Also noted by Al Stangenberger, UCB Center for Forestry. PGN]
> Far more likely is that their billing system is written in COBOL, and uses > BCD arithmetic. I'm not impressed with the proposed representation. There is *no* advantage to representing things in decimal. You are representing *numbers*, abstract entities that exist independent of the base they are represented in. In *any* fixed representation, there will be limits — a largest (and smallest) possible exponent, the maximum number of fractional bits/digits that can be represented. This can lead to either of two errors: * overflow: the number becomes too big for the representation * precision loss: the fraction is too long for the system to represent, and the least significant bits/digits are dropped, leading to rounding errors. One example would be calculating interest. Say you advertise a rate of, say 2.75%, compounded daily. That means you need to divide .0275 by 365. The result is an infinitely long repeating fraction, regardless whether you express it in decimal or in binary. Decimal only provides an advantage if you are dividing by 5 or 10, which produces a finite fraction in decimal notation but an infinite one in binary. If you want to represent numbers without loss of either significance (overflow) or precision (rounding error), you can use any of several package, you can write in Franz Lisp, which allows arbitrary-sized numbers as a built-in type. Or you can use any of a number of arbitrary precision packages available on the web. Just do a search for the words arbitrary precision or rational arithmetic. Using either of those techniques, you have _no_ loss of either precision or significance(*) until the very end when you have to convert it to money units for billing and round to the nearest cent. But that is inevitable regardless of the representation you choose, an artifact of our monetary system which has no unit smaller than one cent. * Until you run out of memory, if your calculation goes on long enough and the numerator and denominator get big enough.
Workshop On Trustworthy Elections (WOTE 2006) Robinson College, Cambridge, United Kingdom June 29 - June 30, 2006 http://www.win.tue.nl/~berry/wote2006/ Held in conjunction with 6th Workshop on Privacy Enhancing Technologies Robinson College, Cambridge, United Kingdom June 28 - June 30, 2006 http://petworkshop.org/2006/ Announcement and Call for Contributions The workshop is organized by IAVoSS, the International Association for Voting Systems Sciences, in association with the 6th Workshop on Privacy Enhancing Technologies. It follows in the tradition of the series of workshops devoted to cryptographic voting methods, such as WOTE '01, the DIMACS Workshop 2004, FEE 2005, and the NeSC Workshop on e-voting and e-democracy. Scope and Objectives Democracy and voting systems have received considerable attention of late, with the validity of many elections around the world being called into question. The US experience demonstrates that simply deploying technological "solutions" does not solve the problem and can easily exacerbate it. The aim of the workshop is to present and discuss promising technologies and schemes to achieve high assurance of accuracy and privacy in the casting and counting of votes. The challenge is highly socio-technical in nature and requires an excellent understanding of the potentialities and dangers of technological approaches as well as an appreciation of the social, legal and political impact. The workshop thus aims to bring together researchers and practitioners from academia and industry as well policy makers, voting officials, whose work relates to electronic voting systems, to evaluate the state of the art, to share practical experiences, and to look for possible enhancements. The overall aim then is to stimulate discourse between the various stakeholders and enhance the understanding of voting technologies and practices. [See full announcement for suggested topics. PGN] The workshop will consist of invited keynote presentations and contributed presentations. Panel discussions are also anticipated and submissions of suitable topics, with or without a moderator or example participants are welcome. The intention is is to encourage plenty of discussion and so work in progress submissions are most welcome. Accepted papers, abstracts and panel proposals will appear online. A separate category of presentations, Informal Communications, encourages preliminary ideas or status updates and requires only a short summary be submitted that may even relate to submissions to other conferences. Our intention is to publish a special edition of selected papers in a major security journal. Acceptance of an extended abstract does not preclude publication elsewhere. Submissions from PC members are welcomed. There will also be an opportunity to demo systems and prototypes the evening of Wednesday the 28th. Contributions To contribute a presentation, please submit an extended abstract summarizing a technical contribution or a position paper summarizing your research. Contributions will be selected by the expected interest in the topic and the potential for stimulating exchange of ideas among the participants. A submission must be a PDF file of at most 8 pages, in letter-or A4-format, using at least 10pt fonts and no non-standard character sets. Submissions should be sent as an attachment by e-mail to peter.ryan@ncl.ac.uk. All submissions must be received by midnight (UK time) 2 Jun 2006. Notification of acceptance will be sent by 9 June, 2006. General Chair: Peter Ryan (University of Newcastle, UK) Program Chairs: David Chaum (Votegrity, USA), Ron Rivest (MIT, USA) P Y A Ryan Professor of Computing Science School of Computing Science University of Newcastle Newcastle upon Tyne NE1 7RU UK Tel: +44 191 222 8972 Fax: +44 191 222 8788 peter.ryan@ncl.ac.uk http://www.cs.ncl.ac.uk/people/peter.ryan
For those of you going to USENIX and interested in the voting issues, an excellent workshop is being organized in conjunction with USENIX Security in Vancouver, and will take place on 1 Aug 2006. The program and other information are already online. http://www.usenix.org/events/evt06/
Please report problems with the web pages to the maintainer