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…
On 5 Jun 2008, both engines of an Eclipse 500 (a light jet popular as an air taxi of small corporate plane) became stuck at full throttle on approach to landing. The pilots aborted the landing, flew around while looking through the manual, and discovered procedures for failure of one engine control or the other, but not both. ``They shut down one engine and then lost control of the other, because of a possible software flaw.'' They were able to land safely, although blowing out the tires. ``A week later, the Federal Aviation Administration issued an emergency order Thursday grounding the planes of that model until the throttle controls can be inspected.'' [Source: Matthew L. Wald, *The New York Times*, 13 Jun 2008; PGN-ed]
By Ed Foster, Section The Gripelog, Mon Jun 16, 2008 The holy grail for the software industry's political muscle has long been what in UCITA was called "electronic self help" - the right of software publishers to remotely disable their software on the mere suspicion that it hasn't been paid for. UCITA was ultimately stopped, but last Wednesday the Senate Commerce Committee held a hearing on a bill that nominally is supposed to fight spyware but seems intended to make remote disabling legal. http://www.gripe2ed.com/scoop/story/2008/6/16/1219/71034
I caught this in *The Boston Globe*, 25 Jun 2008, under "Wireless systems are called disruptive", but found a better reference here: "Wireless systems used by many hospitals to keep track of medical equipment can cause potentially deadly breakdowns in lifesaving devices such as breathing and dialysis machines, researchers reported Tuesday in a study that warned hospitals to conduct safety tests." http://www.chicagotribune.com/news/local/chi-ap-med-microchipdangers,0,6525457,print.story The research was published in JAMA under the title "Electromagnetic Interference From Radio Frequency Identification Inducing Potentially Hazardous Incidents in Critical Care Medical Equipment". A quote: "Results In 123 EMI tests (3 per medical device), RFID induced 34 EMI incidents: 22 were classified as hazardous, 2 as significant, and 10 as light." http://jama.ama-assn.org/cgi/content/short/299/24/2884
Yet another story on the vulnerability of voting systems: Rogue code could seriously skew US presidential election results http://www.itbusiness.ca/it/client/en/home/News.asp?id=48929
I don't know what Martin Gardner said, but if "voting insincerely" means voting something other than your true preference in order to get a desired result, then there certainly can be a reason for voting insincerely under approval voting. Suppose 60% of the voters prefer A but also are happy with B, 20% like only B, and 20% like only C. Then if the 60% vote sincerely they would list A and B, and B (with 80% approval) would be the elected candidate. But if the 60% only vote for A, then A gets elected. Thus voting insincerely (saying that you do not approve B when in fact you do approve B) leads to a better result. Instant runoff can also lead to unfortunate results. Suppose that there are 11 candidates. A1 through A10 are each preferred by 10% of the voters and hated by the other 90%. B is everybody's strong second choice, liked almost as much as their first choice. In instant runoff B is eliminated in the first round, and the election will eventually elect a candidate that 90% of the voters hate, instead of a candidate that everybody is happy with. Here approval voting works much better, because B will appear on every ballot and will be elected (if voters vote sincerely).
[From Dave Farber's IP] Thought you (and the list) might be interested in this. Chrysler's announcement to deploy Wi-Fi in vehicles to me spells opportunity for malicious script kiddies and a "rolling" increase in the 2.4 noise floor. http://www.itwire.com/content/view/18956/53/ [See IP archives for further discussion. PGN] IP Archives: http://www.listbox.com/member/archive/247/=now
John Timmer, Arstechnica, 20 Jun 2008 Yesterday, the 9th Circuit Court released a ruling with huge implications for privacy rights. In a case involving personal use of a work-provided messaging service by a police officer, the court held that the employee had a right to expect that the privacy of his messages would be honored, and that any police access to those messages had to meet the standards of a reasonable search. The ruling provides an extensive space for workspace privacy, at least as long as the NSA isn't involved. The decision arises from Quon vs. Arch Wireless (PDF), which has a rather complicated background. Jeff Quon was a member of the city of Ontario, CA SWAT team. The city provides its officers with access to a wireless text messaging pager provided by Arch Wireless, which came with a monthly character limit. Formally, the announced departmental policy was that the content of the messages sent could be audited at any time. In practice, however, the pagers were handled quite differently. The department never viewed their content, and simply asked users to pay any charges for running over the character limit. Things proceeded uneventfully until the day when, as the decision phrases it, "Lieutenant Duke grew weary of his role as bill collector." The department decided to determine if the character limit was too low for departmental business, so they requested a copy of all messages on their account from Arch Wireless with the intent of determining whether business or personal use was driving the overage charges. With the contents in hand, they discovered many of Quon's messages were both personal and X-rated. An internal investigation ensued, and Quon and the people he exchanged messages with sued the city, its police department, and Arch Wireless. ... http://arstechnica.com/news.ars/post/20080620-x-rated-sms-case-gives-employees-some-privacy-guarantees.html
A jail telephone system would record all calls, except those to numbers listed in an attorney database. The database was incomplete - most obviously in not containing attorney's direct lines or cellphones. California law prohibits recording calls from jail between inmates and attorneys (just as doctors and patients, and ministers and penitents). It may be a felony with up to a $5,000 penalty per call. One attorney found out when the prosecutors gave him a cd with his recorded calls on it. The San Diego County Sheriff's Department says it was a glitch in the telephone system. The extent of the problem is unknowable. Prosecutors had access to the recordings from their PC's. "We thought we had a better database" said Sheriff's Department Legal Advisor Sanford Toyen. The system has been turned off; investigations and court paper filings are underway. The system is being changed to give a number for attorneys to call to be added to the database. One risk would be assuming a poorly designed technology driven system will be adequate to protect legally-required privacy. Poor design decisions include assuming perfect data in the database, assuming Sheriff's Department users would be able to assess such risk, and assuming telephone users would both hear and properly understand an aural message that the call is being recorded. Another risk may be added by the change: an opt-out system isn't fast enough unless done properly (read: expensive). Lawyer involvement is left as an exercise for the cynical. http://www.signonsandiego.com/uniontrib/20080621/news_1n21calls.html http://www.garry.to
We all know of the supposedly invisible parts of PDF documents, but how about HTML comments? Beside the typical <!-- headline Comes Here --> <!-- Quick Links Section --> <!-- Main Content Section --> here's one from my million dollar retirement account: <!-- ~~~~~~~concreate row that makes ns47 beahve~~~~~~~--> So we see behind the steely corporate facade that if they don't "concreate" that row, then "ns47" won't "beahve", probably bringing the entire house of cards down.
The lead article/editorial in Bruce Schneier's latest CryptoGram (http://www.schneier.com/crypto-gram.html) points out the foolishness in warning people to beware of terrorists taking pictures. Millions of people take billions of pictures every year for legitimate or innocent reasons, and the major terrorist attacks have not involved terrorists walking around taking photographs of the targets. It doesn't make sense to try and protect yourself by raising an alarm about an activity that is probably (*extremely* probably) not a threat. Rather ironically, the second piece talks about the fact that your laptop may be searched when you fly to another country, and the advisability of laptop encryption. Leaving aside privacy and legality concerns, Schneier is for encryption. Now, I don't fly as much as some, but more than many. Since I'm a security researcher, I've got all kinds of materials on my laptop that would probably raise all kinds of flags. I've got files with "virus," "malware," "botnet," and all kinds of other scary terms in the filenames. (I've got a rather extensive virus zoo in one directory.) Nobody at immigration has ever turned a hair at these filenames, since nobody at immigration has ever asked to look at my laptop. (Even the security screeners don't ask me to turn it on as much as they used to, although they do swab it more.) I'm not arguing that people shouldn't encrypt materials on their laptops: it's probably a good idea for all kinds of reasons. However, unless I'm very fortunate in my travels (and, from my perspective, I tend to have a lot more than my fair share of travel horror stories), the risk of having immigration scan your laptop is not one of them. firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
This one is nasty. Mr. Fiola was abruptly fired for having child pornography on his employee-issued laptop, but now, it seems that there was insufficient evidence to show that he downloaded it. His life has been hellish for the last 18 months though: http://www.itbusiness.ca/it/client/en/home/News.asp?id=48856
BKCHTDFE.RVW 20080318 "Challenges to Digital Forensic Evidence", Fred Cohen, 2008, 1-878109-41-3, U$39.00 %A Fred Cohen %C 572 Leona Dr, Livermore, CA 94550 %D 2008 %G 1-878109-41-3 %I Fred Cohen and Associates %O U$39.00 925-454-0171 all.net %O http://www.amazon.com/exec/obidos/ASIN/1878109413/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1878109413/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1878109413/robsladesin03-20 %O Audience s+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 122 p. %T "Challenges to Digital Forensic Evidence" Fred Cohen knows his stuff when it comes to digital forensics, despite the fun he has with legalities in the frontmatter of this book. Cohen states, in chapter one, he wrote the book because of the mistakes he had seen people make when bringing technical materials into a legal setting. The work is a sold background for a forensic examiner, and covers a number of areas that are missed in most of the current literature on this topic. Forensics is more than simply getting bits out of a given operating filesystem. Chapter two concentrates on the errors or problems that arise in the process of collecting evidence. Many computer forensics books list the sections that should be included in a written report, but this author provides, in chapter three, practical advice on both wording and approaches, including such aspects as the reporting of errors in previously submitted reports. Chapter four demonstrates difficult situations, some covered in prior chapters and some new, based on actual cases. Chapter five reiterates and emphasizes a point that Cohen raises frequently throughout the book: as an expert, you are working within, and subject to, an adversarial system and all its attendant limitations, but your primary responsibility is to the truth. Being honest in your work and statements is the basis for all of your testimony. As chapter six points out, it is also the best way to avoid being challenged. There are many books that talk about forensic tools: this isn't one of them. There are a number of works that address specifics of file systems and storage devices: this isn't one of them. A few texts even address some aspects of the investigative process and management: Cohen addresses some of those issues. However, I have not seen any other guides that will tell you, clearly and plainly, how to avoid the most common failings of technical experts trying to provide evidence in a decidedly non-technical legal system. copyright Robert M. Slade, 2008 BKCHTDFE.RVW 20080318 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer