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 Australian Transport Safety Bureau (ATSB) has released its preliminary report regarding the take-off of an Airbus A340-500 flown by Emirates that nearly turned into a disaster. http://www.atsb.gov.au/publications/investigation_reports/2009/AAIR/pdf/AO2009012_Prelim.pdf http://xrl.us/bescyd The pilots used a laptop to develop the flight plan which involved a reduced-power take-off. The performance calculation used to determine the power settings required on the engines were based on an incorrect value. The weight of the aircraft was entered as 262 tonnes instead of 362 tonnes. Neither the pilot nor the co-pilot caught the error during cross checks, The co-pilot attempted to rotate the aircraft to commence the climb, but it failed to respond since the engines were delivering power for a much lighter craft. The pilot selected maximum thrust and the aircraft finally became airborne, but not after having suffered three tail strikes, overrunning the end of the runway and knocking out some ground infrastructure. They dumped fuel and landed successfully. The airframe suffered damage to structures made from composites and apparently no-one is quite sure how to repair it as this has never occurred before. RISKS readers will recall a similar incident which did not end so happily. In October 2004, a 747 freighter was launched down a runway with its engine delivering insufficient power, due to errors made in calculating the take-off profile. 250 metres beyond the end of runway it managed to climb into the air, and 100 metres further it struck an earth berm, severing the tail. The craft crashed and all seven crew members were killed. http://www.flightglobal.com/articles/2006/07/04/207571/canada-old-data-led-to-october-2004-crash-on-take-off-of-mk-airlines-747.html http://xrl.us/bescyb
This article tells how the custom of having a celebrity make the first move to open the tournament backfired when he made two consecutive moves with the White pieces as a joke. This caused the software feeding the games to the outside world to freeze up and they were not able to get it working again that day. http://reports.chessdom.com/news-2009/mtel-masters-software-r1 The beginning of the last paragraph was rather amusing: "The technical staff of Mtel Masters proved useless and could not repair the live feed."
"Canada's tax agency is stockpiling hundreds of old computers containing sensitive taxpayer data that officials are unable to delete. Police warned federal agencies two years ago that their disk-erasing software was unreliable, but the tax agency failed to buy new software. Since then, tax offices around the country have been storing the old hard drives in locked facilities. Some have resorted to smashing the computers to destroy the data, but police say that technique has mixed results. To properly destroy a drive, they say, it should be run through commercial equipment that slices it into bits no bigger than the width of a pencil." [from *The Week* mag. 8 May 2009, page 8]
Colin Percival, who happens to be the FreeBSD Security Officer, has created the "scrypt" key-derivation function that he's presenting at BSDCan 2009: > We estimate that on modern (2009) hardware, if 5 seconds are spent > computing a derived key, the cost of a hardware brute-force attack against > scrypt is roughly 4000 times greater than the cost of a similar attack > against [OpenBSD's] bcrypt (to find the same password), and 20000 times > greater than a similar attack against PBKDF2. http://www.tarsnap.com/scrypt/ There's a sixteen-page paper that describes the algorithms and logic behind these conclusions.
When you view your iCal birthday list on iPhone or iPod, the birthdays of people over 75 disappear. They look like an appointment that has repeated too many times, because the software cannot handle events that occur more than 75 times. [PGN-ed; MacWorld's Christopher Breen suggests duplicating the entry — which he notes works just fine unless someone lives over 150.] http://www.macworld.com/article/140596/2009/05/iphone_repeating_birthdays.html Steve Bellovin, http://www.cs.columbia.edu/~smb
An employee at Johns Hopkins Hospital may have leaked the personal information of more than 10,000 patients in an identity fraud scam. Some 31 individuals with connections to Johns Hopkins have reported identity thefts since 20 Jan 2009. JHU security people have identified a single employee working in patient registration, who is expected to be indicted. Law enforcement agencies suspect the thefts might be part of a fraudulent driver's license scheme discovered in neighboring Virginia. [Source: Tim Wilson, DarkReading, 13 May 2009, PGN-ed; TNX to Jeremy Epstein] http://www.darkreading.com/insiderthreat/security/privacy/showArticle.jhtml?articleID=217400831 http://www.oag.state.md.us/idtheft/Breach%20Notices/ITU-168293.pdf
Bill Turque, Data About Students Dispersed in Breach E-Mail Included Personal Information, *The Washington Post*, 23 May 2009 http://www.washingtonpost.com/wp-dyn/content/article/2009/05/11/AR2009051102299.html The D.C. agency that handles college financial aid requests said yesterday that it had accidentally e-mailed personal information from 2,400 student applicants to more than 1,000 of those applicants. The Office of the State Superintendent of Education (OSSE) said it has notified all students of the breach, which occurred when an employee of the agency's Higher Education Financial Services Program inadvertently attached an Excel spreadsheet to an e-mail. The information included student names, e-mail and home addresses, phone and Social Security numbers and dates of birth. The disclosure involved the "DC OneApp," an online application that allows D.C. students to apply for a series of grant programs. They include DCTAG, which provides awards of up to $10,000 toward the difference between in-state and out-of-state tuition at public four-year-colleges in the 50 states. The accidental disclosure went to about 1,250 DCTAG applicants. OSSE never publicly announced the breach, which occurred Wednesday. It did express regret for the incident in an e-mail sent to students and parents the next day. A parent made the e-mail available to *The Washington Post* over the weekend. The agency urged all recipients to immediately destroy the spreadsheet attachment. It also offered one-year subscriptions to a credit-monitoring service to help students guard against identity theft or other fraud. "The OSSE takes very seriously our responsibility to keep personal information private and sincerely apologizes to everyone for any inconveniences," the e-mail said. The agency said it was taking steps to shorten Social Security numbers on any reports or spreadsheets and was reviewing policies and security measures for handling confidential student information. Parents reacted angrily to word of the breach. Brenda Thomas, whose daughter Leah is a senior at Maret, a private school in Northwest Washington, said she was `livid'. "We tell her how important it is not to give her Social Security number out, not even to join Facebook, for goodness' sakes." Even more irritating was that she was recently informed by OSSE that Leah, who will attend Stanford University this fall, was ineligible for assistance because the family exceeded income guidelines. "And now this," Thomas said.
The Homeland Security Information Network (HSIN) platform for sharing sensitive but unclassified data with state and local authorities was hacked recently. The initial penetration in late March was brief and limited, and was followed by a more extensive one in early April, using the HSIN account of a federal employee or contractor. The bulk of the data obtained was federal, but some state information was also accessed, and contained some administrative data (telephone numbers, e-mail addresses, but not SSNs, drivers' licenses, or financial data). [Source: Ben Bain, Homeland Security Information Network suffers intrusions, *Federal Computer Week*, FCW.com, 13 May 2009; PGN-ed; thanks to Jeremy Epstein.] http://fcw.com/articles/2009/05/13/web-dhs-hsin-intrusion-hack.aspx
A controversial French bill which will disconnect people caught downloading content illegally three times has been given final approval. It would be fun (for the non-French, at least) watching them try to enforce it. See for reference "The source of semantic content" in RISKS-16.87 (http://catless.ncl.ac.uk/Risks/16.87.html#subj3). The situation is much more complicated now; with mobile devices which can pick up content from the "data cloud" any time, anywhere, how can they even begin to define legally "downloading content" and "disconnect people"? Full story at: http://news.bbc.co.uk/2/hi/technology/8046564.stm
There are many kinds of risks with targeted keyword marketing on the web. This is merely one example. Univerally keyword based marketing campeigns are not protected for "string" or "checksum" uniqueness. The "Uniqueness" option may emerge during this finance system crisis, but it will not be cheap. Source: 11 May 2009 http://www.interest.co.nz/ratesblog/index.php/2009/05/11/kiwibank-discove rs-the-perils-of-google-adwords-with-100-interest-campaign/ Kiwibank has launched a campaign aimed at business customers with the big 4 Australian owned banks that offers `100% interest' in their business. It even has its own website and readers are encouraged to search on "100% Interest" to find out more. The pitch is that Kiwibank is 100% interested in the customer's business. This campaign even has it's own website to inform would-be customers. The trouble with the Google Adwords approach is that it is vulnerable to ambush by a competitor. That is exactly what happened today when Westpac bought the sponsored link for 100% interest. Blogger Dan Roberts from Xebidy Strategic Design also wrote a blog about it to prove a point. Another one here on the need for better bank marketing did the trick too, putting it near the top of the natural search rankings.
(Re: RISKS-25.66) Following the news story about a youth near Sydney, Australia who couldn't get help from emergency services (RISKS-25.66), the focus in that excerpt was that the emergency dispatch computer system "needed" a street address, and the call receivers were stuck because they wouldn't/couldn't override that requirement. It turns out there's another risk from the story, courtesy of the just completed inquest: Complicating matters was that when other people in the emergency services systems wanted to listen to the call to try to get a hint as to where he was, it was a lot harder than it should have been: "Superintendent Patrick Paroz told Penrith Coroner's Court he made two separate requests to the state emergency services for copies of 000 calls made by the Sydney Grammar student. "He did not receive them until almost a day later. ... "A disc containing sound files of the calls had to be driven from the city to Katoomba because computer firewalls in the ambulance service system prevented police receiving them by email." http://www.news.com.au/story/0,27574,25396246-421,00.html
700 reasons why air traffic control systems may be hacked: A recent audit in the U.S. has found more than 760 high-risk vulnerabilities in Web applications used to support Air Traffic Control operations. These give attackers a way to gain access not just to underlying Web servers but potentially to other more critical backend systems. http://www.itbusiness.ca/it/client/en/home/News.asp?sub=true&id=53123
Here's the full report http://www.oig.dot.gov/StreamFile?file=/data/pdfdocs/ATC_Web_Report.pdf It includes identification of which are the 11 ATC sites with ANY kind of protection, so that now terrorists, hackers, and other trouble makers know which are the hundreds of sites without any protection. It is important for government to be open to the people in identifying problems, but some stuff needs to be kept confidential from potential trouble makers.
On Government IT competence Linda Gorman's note is a partisan rant where it suggests that government is uniquely incompetent. That rant doesn't belong in RISKS. In many years of consulting to government and (often large, sometimes huge international) business, I've seen nothing to suggest that government IT designers and creators are any less able than those in business; indeed, it has often astounded me that some businesses manage to operate at all, considering how grotesquely bad are their IT operations. If there's any difference with government IT in the USA, it may be simply where politics trumps good IT; or, for example, where protected entities like the FBI end up doing their IT work out of the sunlight of dispassionate good judgment (something I've often seen in business); where underfunded entities are asked to perform miracles on inadequate budgets (also often seen in business); or where the rewards to vendors are large and oversight is lacking (amazingly, also found in business). I could provide examples of any of this from businesses whose names everyone knows. The proper response to these problems, no matter where they occur, is to exercise that dispassionate good judgment and oversight. Businesses have many ways of concealing their IT incompetence that aren't available to government, especially the option of simple secrecy; and we write our laws to protect (if not always guarantee) their ability to make a profit even when they screw up. Shall we talk about voting devices? Or perhaps the design and quality problems of certain operating systems used by hundreds of millions of persons daily?
I nearly fell over in my chair when I read Linda Gorman's comment in RISKS 25.66. I've been reading RISKS for almost 20 years now, and no other submission comes close to being as politically biased and content-free. Consider just the last sentence: "To date the myth or [sic] electronic systems to the rescue continues to grab people even though almost all of the real world tests of the effects of expanded government control suggest that the most likely result it [sic] higher costs and degraded care." What myth? As we all know, sometimes electronic systems fail horribly and sometimes they work really well. Is Ms. Gorman seriously suggesting that they be eliminated? Real world tests of expanded government control? Actually, the real world examples that come to mind--the health care systems of countries like Canada, Sweden, and Denmark--suggest that expanded government control leads to outcomes superior to those reached by private entities. I smell an axe grinding...
Dear Mr. Coleman: I merely suggest that the involuntary imposition of information systems on people who need or provide health care can lead to excess costs, massive problems with securing private information, and risks to life and limb. Those costs may exceed the benefits. Unfortunately, involuntary imposition is rapidly becoming federal policy in the United States. Obviously electronic systems work very well in some health care related uses--people in the US would not have CAT scans or MRIs or nationwide Walgreens prescriptions without them. The question is who should decide who must use them, and who chooses the systems to be used, and whether we are safe in assuming that everyone has the same risk reward tradeoff. As for the comment about grinding political axes, as I am sure you are aware, there is a large literature on comparative health care systems. Recent work does not necessarily support your claim that government run systems provide better results. A few examples of why this is true, and why such comparisons are difficult, are outlined below. Leaving aside the problems of purchasing power parity and currency translation for non-traded goods, cost comparison is a problem because national accounting systems vary. For example, certain expenditures counted as health expenditures in the US national accounts are not included as health expenditures in Japan's national accounts. The OECD has a decade old program that has been discussing these differences and seeking to harmonize accounting systems. Progress is slow. Cost comparisons are also hampered by the fact that many national governments impose price controls on health inputs. As a result, recorded payments to providers understate true costs. We can do cost comparisons between private and public systems in the United States, but even those are difficult because Medicare operates under a system of controlled prices, and people can and do switch between the private system, Medicare, and the Veterans Administration, and private systems and Medicaid, in order to optimize their care. Another problem is that simple definitions differ across countries. Infant mortality rates are an easily understood example of this. For years, the US had been excoriated for having high infant mortality rates. In the 1990s, epidemiologists realized that there were major differences in infant deaths in the first 24 hours across countries. Further research led to the discovery that the mortality differences were created by differences in birth registration--in the US and Canada any birth in which a child showed any signs of life was counted as live. Some European countries would classify the same very low birth weight babies as dead. Since very low birth weight babies also have the highest mortality risk, excluding them at birth made the European results look better than the US and Canadian rates. OECD comparative health statistics now include a note saying that cross country infant mortality rates are not comparable. Finally, in order to accept your assertion that "the real world examples that come to mind--the health care systems of countries like Canada, Sweden, and Denmark--suggest that expanded government control leads to outcomes superior to those reached by private entities" one must believe that waiting lists, which exist in virtually all known government run health care systems, do not matter. Swedish researchers, among others, have done a lot of work showing that they do matter. Waiting lists increase costs by causing enormous productivity losses, and they cause excess mortality as people die waiting for care. This may be part of the reason why the Swedes are now trying to move towards more private provision of health care. In passing, I should note that productivity losses, and losses due to excess mortality, are not included in most health care spending estimates. I am sorry to have made a statement that you found so upsetting. I hope that these examples show that my comments simply reflect a conclusion that I believe is supported by recent health care research. I suppose that you are correct in saying that my comments are ideological in that in the best case one's ideas are formed by the facts as currently known, and by theory as currently accepted. Linda Gorman, PhD, Director, Health Care Policy Center Independence Institute, Golden, Colorado 80401 USA
BKGGLSEC.RVW 20091020 "Googling Security", Greg Conti, 2009, 978-0-321-51866-8, U$49.99/C$54.99 %A Greg Conti conti@acm.org www.GregConti.com www.rumint.org %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2009 %G 978-0-321-51866-8 0-321-51866-7 %I Addison-Wesley Publishing Co. %O U$49.99/C$54.99 416-447-5101 800-822-6339 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321518667/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321518667/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321518667/robsladesin03-20 %O Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 332 p. %T "Googling Security: How Much Does Google Know About You?" The title is ever so slightly misleading: the subtitle is much clearer. This is not about doing Web searches to find security tools or information, but, rather, the information that Google collects from (and relating to) Internet users in the course of providing its services and tools. The preface states that the intent is to raise awareness of the privacy risks involved in using Google, its utilities and services, and of similar systems and agencies. Conti does not, for the most part, present solutions: some activities admit of no resolution. Google is not being singled out because the author doesn't like the company, but because it is the largest and most pervasive search and information system, with the greatest implications, and because the policies and decisions resulting from discussions of these issues can be applied more generally. Chapter one is an overview of the online world, and online activity, and the scope and capabilities of Google. There are extensive endnotes supporting the stories and studies cited in the text. The normal information flows involved with computer operations are outlined in chapter two, and Conti points out the potential areas of leakage. Although not named as such, he provides an excellent explanation of the trusted computing base (TCB), as well as reviewing covert channels such as TEMPEST and acoustic surveillance, and Internet entities. Turning more specifically to the structure of requests from browsers, chapter three notes the information that is captured by server logs. The author also notes data provided by users themselves, and that which can be obtained from statistical analysis of a large amount of activity. Chapter four notes the various search sites and functions, as well as the intelligence that can be inferred about someone, simply by examining the search requests submitted. Communications, mostly Gmail, is the subject of chapter five. Chapter six examines the mapping and related imagery functions, discussing the information disclosed by requests for directions, as well as the occasional invasion of privacy involved in the collection of satellite photographs. (Personally, while I don't use Google Earth, I use Google Maps quite a bit. I was interested to see that my non-standard interaction with the system inadvertently protected against some of the dangers Conti points out. I don't "express interest" by clicking on the "Print" or "Link ..." buttons, but tend to copy the link location URL and use that. Of course, if Google buys up TinyURL I may be in trouble ... :-) Tracing functions related to the provision of advertising, as well as malicious enterprises associated with commercial proclamations, are noted in chapter seven. Webbot, spider, or crawler operations are detailed in chapter eight. Although Conti did not promise a solution, chapter nine does provide recommendations and resources to raise awareness of the issues, and assist with protecting the reader's privacy. Chapter ten finishes off with a look to the future, and the forces which ensure that whether or not Google survives, the privacy situation online is unlikely to change. The book is certainly interesting and illuminating. Internet users, for the most part, may have encountered security awareness material that speaks of the dangers of certain types of activities, but not necessarily of how much information they disclose in the course of normal pursuits. While Google is used as a specific example in many parts of this work, the internal operations of many of the services and utilities are not examined to the internal depth they might have been. A more accurate title might be "Privacy While Surfing." Which is an important enough topic to read about in any case. copyright Robert M. Slade, 2009 BKGGLSEC.RVW 20091020 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm http://blog.isc2.org/isc2_blog/slade/index.html http://twitter.com/rslade http://blogs.securiteam.com/index.php/archives/author/p1/
Please report problems with the web pages to the maintainer