You have probably read the April Fool's Day RFC 1149 (A Standard for the Transmission of IP Datagrams on Avian Carriers) (available at http://www.rfc-editor.org/rfc/rfc1149.txt). You may have read http://www.blug.linux.no/rfc1149/ which is about an implementation of it. Maybe they should try it in South Africa. They appear to have the hardware. A South African information technology company on Wednesday proved it was faster for them to transmit data with a carrier pigeon than to send it using Telkom, the country's leading [I]nternet service provider. Internet speed and connectivity in South Africa are poor because of a bandwidth shortage. The 11-month-old pigeon, Winston, took one hour and eight minutes to fly the 80 km from Unlimited IT's offices near Pietermaritzburg to the coastal city of Durban with a data card strapped to his leg. In that time, just two per cent of the data was sent over the Internet." [Source: Pigeon Transfers Data Faster Than Internet Provider (Reuters), Kamloops This Week Daily (Kamloops, British Columbia, Canada), 2009-09-11 issue, p. 4] The joke used to be about the bandwidth of a station wagon full of magtapes, and now, the hardware has been miniaturised to pigeon-size. I am amazed at the advances in computer technology. [Also noted by Matthew Kruk. PGN] http://au.news.yahoo.com/a/-/mp/6016150/pigeon-transfers-data-faster-than-south-africa-telkom/
...there was no one hired to work on deployment while I was at OLPC, with Uruguay's and Peru's combined 360,000-laptop rollout in progress. I was parachuted in as the sole OLPC person to deal with Uruguay, and sent to Peru at the last minute. And I'm really good at thinking on my feet, but what the sh*t do I know about deployment? Right around that time, Walter was demoted and theoretically made the "director of deployment," a position where he directed his expansive team of -- himself. Then he left, and get this: now the company has half a million laptops in the wild, with no one even pretending to be officially in charge of deployment. "I quit," Walter told me on the phone after leaving, "because I can't continue to work on a lie." http://radian.org/notebook/sic-transit-gloria-laptopi
In today's connected world, the time you spend in your car might be the only time you're really off the grid. But that's about to change --- the automotive and ICT sectors are collaborating to network vehicles and come up with ideas for useful applications. Whether its finding carpool buddies, swerving to avoid a collision, or avoiding traffic jams --- CATA wants those applications to be tested in Canada. [Source: Intelligent car 1,000-km corridor between Ontario and Quebec envisioned] http://www.itbusiness.ca/it/client/en/home/News.asp?sub=true&id=54501 The risky stuff starts near the bottom of page 2. A concern of mine is how motorists in vehicles without this system will interact with vehicles that do. It seems to me that expectations of intelligent response are not going to be met.
Menino's office acknowledges city employees routinely deleted e-mails By Donovan Slack and Michael Levenson, *The Boston Globe*, 13 Sep 2009 Mayor Thomas M. Menino's administration, prompted by public records requests from *The Globe*, has acknowledged that city employees were routinely deleting e-mails, a potential violation of the state public records law. This came after *The Globe* filed several requests for e-mails sent and received by Menino's Cabinet chief of policy and planning, Michael J. Kineavy -- who is one of Menino's most powerful and trusted advisers, intimately involved in nearly everything at City Hall. However, a search of city computers found just 18 e-mails he had sent or received between 1 Oct 2008, and 31 Mar 2009. The unusually low figure prompted administration officials to question him about what happened to the rest of the e-mails he was presumably sending and receiving during that period. Kineavy told them that he deletes all his e-mails on a daily basis, in such a way that they are not saved on city backup computers. http://www.boston.com/news/local/massachusetts/articles/2009/09/13/meninos_office_acknowledges_city_employees_routinely_deleted_e_mails/
Cyberwarfare is the sort of game where you don't really need to be a huge government with the largest standing army in the world and sophisticated weaponry in order to win. Any teenager in his basement can control a botnet. And a botnet targeted at a poorly secured site will take it down, never mind whether the site belongs to the US government, or to the Iranians, or the Chinese, the Russians, Indians, etc. etc. In other words probably the best way to go in a so-called "cyberwar" is defense. Harden your security. And make efforts to take down the sources of the DDoS or other attack as a way to mitigate it. Not by breaking into it -- that's not a good idea-it will very likely end up affecting an innocent party, and you might not even have taken out the actual source -- given that a lot of botnet C&Cs are usually compromised hosts, controlled by a chain of proxies from god knows where else (connecting those dots is quite tough, when a botnet is done right). Rather, by actually using the public private partnership you have, internationally, to work with upstream providers of the source to mitigate these attacks, work with the providers of your critical infrastructure's connectivity to filter attack sources etc. etc. A textbook case of "how not to do this" -- during the recent North Korea (!) DDOS: A vietnamese antivirus / security vendor, BKIS and their analysis said the command and control servers were in the UK-again, quite possibly compromised hosts were used for the C&C. That turned into a "The UK, not North Korea, is behind this cyberattack" in the media. Which doesn't sound quite right to me... Suresh Ramasubramanian: More on Networks and Nationalization with Respect to Cyberware, 21 Jul 2009 http://www.circleid.com/posts/20090721_networks_and_nationalization_with_respect_to_cyberwar/ [Legislating against the concepts of Deep Packet Inspection (DPI) or other preferential treatment of packets is not the brightest thing to do. I've seen others draw analogies to gun control using the 'guns don't kill people' argument. Network algorithms don't kill people either but that's the most I'll take that line of argument forward, it is loaded and the traps are 'easy' to find for people on both sides of the argument. jidanni]
Jenna Wortham, *The New York Times*, 3 Sep 2009 Slim and sleek as it is, the iPhone is really the Hummer of cellphones. It's a data guzzler. Owners use them like minicomputers, which they are, and use them a lot. Not only do iPhone owners download applications, stream music and videos and browse the Web at higher rates than the average smartphone user, but the average iPhone owner can also use 10 times the network capacity used by the average smartphone user. [...] The result is dropped calls, spotty service, delayed text and voice messages and glacial download speeds as AT&T's cellular network strains to meet the demand. Another result is outraged customers. http://www.nytimes.com/2009/09/03/technology/companies/03att.html
Excerpt from Mac OS X 10.6 Snow Leopard: the Ars Technica review http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars A gigabyte by any other name Snow Leopard has another trick up its sleeve when it comes to disk usage. The Snow Leopard Finder considers 1 GB to be equal to 10^9 (1,000,000,000) bytes, whereas the Leopard Finder-and, it should be noted, every version of the Finder before it-equates 1 GB to 2^30 (1,073,741,824) bytes. This has the effect of making your hard disk suddenly appear larger after installing Snow Leopard. For example, my "1 TB" hard drive shows up in the Leopard Finder as having a capacity of 931.19 GB. In Snow Leopard, it's 999.86 GB. As you might have guessed, hard disk manufacturers use the powers-of-ten system. It's all quite a mess, really. Though I come down pretty firmly on the powers-of-two side of the fence, I can't blame Apple too much for wanting to match up nicely with the long-established (but still dumb, mind you) hard disk vendors' capacity measurement standard.
... Panic at the London Evening Standard yesterday where the theatre critic Henry Hitchings filed his review of Lolita at the National Theatre, only to learn that no one at HQ could locate his copy. The panic starts early there -- 5am -- with production staff looking at the clock and imploring him to file again. Why couldn't he communicate with them. No one could understand it. Enter a hero computer boffin. The firewall, he explained, was rejecting the word Lolita. So Hitchings had to re-file substituting Lolita throughout with the less troublesome "Fishfingers". Relieved production staff re-inserted all the Lolitas at the other end. ... http://www.guardian.co.uk/politics/2009/sep/09/boris-johnson-cycling-goldschmied-rogers
Anne-Marie Corley, Quantum Chip Helps Crack Code; Experimental chip does part of code-cracking quantum algorithm, 3 Sep 2009 Modern cryptography relies on the extreme difficulty computers have in factoring huge numbers, but an algorithm that works only on a quantum computer finds factors easily. Today in Science, researchers at the University of Bristol, in England, report the first factoring using this method-called Shor's algorithm-on a chip-scale quantum computer, bringing the field a tiny step closer to realizing practical quantum computation and code cracking. Quantum computers are based on the quantum bit, or qubit. A bit in an ordinary computer can be either a 1 or a 0, but a qubit can be 1, 0, or a "superposition" of both at the same time. That makes solving certain problems-like factoring-exponentially faster, because it lets the computer try many more solutions at once. The race is on to find the ideal quantum computer architecture, with qubit contenders that include ions, electrons, superconducting circuits, and in the University of Bristol's case, photons. MIT professor Seth Lloyd, who has been researching quantum computing and communication systems since the early 1990s, says that "optical methods [using photons] have a long way to go before being useful." But, Lloyd adds, the Bristol experiment demonstrates that the components for optical quantum computing can be squeezed onto a chip, which is an important step forward. Shor's algorithm was first demonstrated in a computing system based on nuclear magnetic resonance-manipulating molecules in a solution with strong magnetic fields. It was later demonstrated with quantum optical methods but with the use of bulk components like mirrors and beam splitters that take up an unwieldy area of several square meters. ... http://www.spectrum.ieee.org/computing/hardware/chip-does-part-of-codecracking-quantum-algorithm [The rest of the article sounds as if the paradigmatic hard problem at this point is still factoring 15. PGN]
Stephanie Neil, *Managing Automation*, 12 Sep 2009 http://www.managingautomation.com/maonline/news/read/NonProfit_Targets_CyberSecurity_in_Plants_33037 The move from proprietary, non-networked control systems in the plant to off-the-shelf, open applications that share information across industrial and business networks is a double-edged sword for manufacturers. On one side, people are more productive; on the other side, SCADA and process control systems are falling victim to hackers and network viruses. Getting a handle on how to manage cyber-threats, however, has always been a bit tricky. Reporting an industrial incident to organizations such as the government-backed CERT program, which tracks Internet and network security attacks, accidents, and failures, could expose a company's network vulnerability or create a legal liability. As a result, many manufacturers keep a lid on their own security issues, which limits knowledge sharing that could help the industrial community as a whole. Enter the Security Incidents Organization, a newly formed non-profit group that provides public access to its Repository of Industrial Security Incidents (RISI). Established in July, the group maintains an industry-wide repository for collecting, investigating, analyzing, and sharing critical information regarding cyber-security incidents that directly affect SCADA and process control systems. The RISI database dates back to 2001, when it was housed at the British Columbia Institute of Technology (BCIT) as part of a research project that was shut down in 2006. At that time, BCIT faculty member Eric Byres purchased the database and continued to collect data on incidents. His company, Byres Research, was acquired by safety and security services firm exida earlier this year. Jeremy Epstein, Senior Computer Scientist, SRI International, 1100 Wilson Blvd, Suite 2800, Arlington VA 22209 +703-247-8708 email@example.com [Eric Byres is noted in two previous issues of RISKS, notably Critical infrastructure cybersecurity risks, RISKS-23.57, and also for Infoworld interviews with him and Alan Paller, in SCADA Hacks, RISKS-24.44. Please see http://www.securityincidents.org if you are interested in being involved in RISI. PGN]
Matt Richtel, *The New York Times*, 29 Aug 2009 Driven to Distraction: Utah Gets Tough With Texting Drivers http://www.nytimes.com/2009/08/29/technology/29distracted.html In most states, if somebody is texting behind the wheel and causes a crash that injures or kills someone, the penalty can be as light as a fine. Utah is much tougher. After a crash here that killed two scientists -- and prompted a dogged investigation by a police officer and local victim's advocate -- Utah passed the nation's toughest law to crack down on texting behind the wheel. Offenders now face up to 15 years in prison. The new law, which took effect in May, penalizes a texting driver who causes a fatality as harshly as a drunken driver who kills someone. In effect, a crash caused by such a multitasking motorist is no longer considered an "accident" like one caused by a driver who, say, runs into another car because he nodded off at the wheel. Instead, such a crash would now be considered inherently reckless. "It's a willful act," said Lyle Hillyard, a Republican state senator and a big supporter of the new measure. "If you choose to drink and drive or if you choose to text and drive, you're assuming the same risk." The Utah law represents a concrete new response in an evolving debate among legislators around the country about how to reduce the widespread practice of multitasking behind the wheel -- a topic to be discussed at a national conference about the dangers of distracted driving that is being organized by the Transportation Department for this fall. Studies show that talking on a cellphone while driving is as risky as driving with a .08 blood alcohol level -- generally the standard for drunken driving -- and that the risk of driving while texting is at least twice that dangerous. Research also shows that many people are aware that the behavior is risky, but they assume others are the problem. Treating texting behind the wheel like drunken driving raises complex legal questions. Drunken drivers can be identified using a Breathalyzer. But there is no immediate test for driving while texting; such drivers could deny they were doing so, or claim to have been dialing a phone number. (Many legislators have thus far made a distinction between texting and dialing, though researchers say dialing creates many of the same risks.) If an officer or prosecutor wants to confiscate a phone or phone records to determine whether a driver was texting at the time of the crash, such efforts can be thwarted by search-and-seizure and privacy defenses, lawyers said. Prosecutors and judges in other states already have the latitude to use more general reckless-driving laws to penalize multitasking drivers who cause injury and death. In California, for instance, where texting while driving is banned but the only deterrent is a $20 fine, a driver in April received a six-year prison sentence for gross vehicular manslaughter when, speeding and texting, she slammed into a line of cars waiting at a construction zone, killing another driver. But if those prosecutors want to charge a texting driver with recklessness, they must prove the driver knew of the risks before sending texts from behind the wheel. In Utah, the law now assumes people understand the risks. ...
Danny Burstein's comment "UK bought Boeing helicopters, figured they'd save money by designing their own software..." is based on an inaccurate news report and is incorrect. There was no attempt to design their own software. The report from the UK Parliament's Public Accounts Committee makes the position much clearer. (It is the purchasing nation's responsibility to assess and certify the airworthiness of the aircraft.) Conclusions and Recommendations: http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/24704.htm 3. The problems with the [Chinook] Mk3 procurement stemmed from the Department's failure to specify in the contract that it required access to the software source code in order to assess the safety risks and establish whether the helicopters would meet UK airworthiness standards. Given that software is key to the operation of most modern defence equipment, this is irresponsible. The Department should specify access to software as a clear requirement within any contract, especially where access to proprietary software is needed to provide airworthiness certification." The Original Procurement of Chinook Mk3 helicopters: http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/24705.htm 1. In 1995, the Ministry of Defence (the Department) decided that, in order to meet the long standing requirement for dedicated helicopters to support special operations, an original order for 14 Chinook Mk2a helicopters from Boeing would be changed. Six were retained as Mk2a and have flown satisfactorily ever since they were delivered, but it was decided that the other eight would be modified to become Chinook Mk3 helicopters. The Chinook Mk3 helicopters feature unique cockpit avionics which, because of the Department's budgetary priorities elsewhere, ended up being a hybrid of analogue and digital systems, rather than a pure digital arrangement as used in the United States special operations Chinook (MH47-E) and by the Royal Netherlands Air Force. 2. In 2005, the Department acknowledged that the Chinook Mk3 project had been badly handled... The hybrid digital and analogue cockpit avionics could not be shown to meet United Kingdom airworthiness standards. As a result, the helicopters could only be granted a limited release to fly, and are restricted to flying on cloudless days above 500 feet where the pilot can navigate via landmarks. This makes them completely unsuitable for use on operations. 3. One of the key reasons for not granting a full release to fly was that the software codes that maintained the instrument displays in the Mk3 cockpit could not be proven to be safe. The Department acknowledged that analysis of the code, which would help anticipate how the software, and hence the helicopter, would behave in all flight conditions, may have enabled it to certify them as safe. Boeing, in protecting their intellectual property rights, denied the Department access to the software source code. The Department accepted that the original contract, which did not mandate access to the codes, was not sufficient for the purpose of procuring helicopters that could be proven to be safe. 5. ... If the Department had not been so willing to compromise on the specification of the cockpit, it might have been able to prove airworthiness in the same way as it has for other aircraft. For example, by using the safety cases put together by the United States for the C17 aircraft, the Department has been able to satisfy the British airworthiness authorities and use the aircraft operationally, without having to resort to analysis of the flight software. The Department acknowledged that it should not over-specify changes to equipment or platforms unless it had, for example, to fit United Kingdom specific communications equipment. The report is available as a PDF file: http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/247/9780215526663.pdf
A book arrived in the post from Switzerland today in a package that was soaking wet, as if it had been submerged or left out in the rain. However, the book itself was encased in plastic, and was not only in perfect condition, but very readable and very relevant to RISKS. Bertrand Meyer's new book, *Touch of Class: Learning to Program Well with Objects and Contracts* ``gives students the edge by teaching both the fundamentals of programming and the professional-level skills preparing them for the challenges of modern software engineering.'' (Quoted from the back cover). 876+lxiv The book is dedicated to Tony Hoare and Niklaus Wirth, and I think it would please both of them very much. It is very likely to be a real value for students, professors, and software engineers alike. PGN
On 27 Aug 2009, Rob McCool reported VA gaffe as "Through a data maintenance error, the Veteran's Affairs department recently sent out automated letters" The issue probably has nothing to do with data maintenance error. The error is in the underlying ICD-9 (International Classification ... of Diseases), which is, along with CPT (Current Procedural Terminology) and, to smaller degree, HL7 (Health Level 7), totally unsuitable for anything except billing for current medical intervention. This is a problem well known in clinical research community and was a topic of many a lively discussions. The same underlying problem caused spurious assignment of a range of illnesses to Mr. deBronkart in his Google Health record (RISKS-25.64), extracted from ICD and CPT in his billing data. These coding systems are not hierarchical (or where they try to be, hierarchy is often broken), non-conservative (the meaning of the codes changes over time, with codes being re-assigned (as in quoted case), split and merged. The latter makes them unusable over any non-trivial timeframe without metadata, which is often unavailable (the source document - medical chart _should_ contain the date of each entry, which would have made maintaining the metadata possible - _if_ it was preserved in transcription. So the risk in the quoted cases is, probably, in the use of data items outside of domain for which they were designed (similarly to use of SSN for authentication). Alexandre Peshansky, Manager, OCR Informatics Core, NJ Medical School, UMDNJ CC F-1220 205 S. Orange Ave., Newark, NJ (973) 972-4897
On Tue, 2009-09-01 at 08:51 -0700, RISKS List Owner wrote: > - ----------------------------------------------------------- > WARNING! This email may be asking for account details. > bright.net would NEVER email you asking for this information. > Do not reply to this email unless you are certain of the > sender. > - ----------------------------------------------------------- > > RISKS-LIST: Risks-Forum Digest Tuesday 1 September 2009 Volume 25 : Issue 77 I can imagine cases where this could cause problems...
Please report problems with the web pages to the maintainer