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…
You should know about this massive violation of the privacy of every American who takes medication. This opinion piece is about the fact that there is no such thing as a private prescription in the nation. Identifiable prescription data is sold to insurers for medical underwriting and to large employers to use as they see fit (discrimination?). Electronic prescribing is no panacea By Dr. Deborah Peel, Saturday, February 17, 2007 http://www.governmenthealthit.com/article97686-02-19-07-Print When a coalition of technology companies, insurers and health care providers launched a $100 million project last month to provide free electronic prescribing software to every physician in the United States, it was greeted with cheers. The presence of brand name vendors was supposed to ensure that sensitive prescription records would be private and secure. But those who believe there is anything private about e-prescribing under the National ePrescribing Patient Safety Initiative (NEPSI) - or any other e-prescription system - are simply incorrect. Security makes little difference because every identifiable prescription in the country is data mined and sold daily. Nobody needs to break into pharmacies to steal our prescriptions; they are for sale. For example, market intelligence firm IMS Health reported revenues of $1.75 billion in 2005 solely from the sale of prescription records, primarily to drug companies. Privacy is the right to control who sees your sensitive health records and the right to decide if those records are even entered into electronic systems. But it is impossible for anyone to have a private prescription - meaning that it is never disclosed without a patient's consent - because data mining has eliminated that right. Furthermore, many people refuse to take psychiatric medication or other medications in an attempt to prevent the pharmacy benefits management industry from reporting to employers that they are on antidepressants or other medications. Knowing that prescriptions are not private also keeps people with other sensitive illnesses from taking medications. And that exerts pressure on doctors to avoid prescribing pain medications - out of concern that the Drug Enforcement Administration is tracking their prescribing patterns. The lack of prescription privacy is a problem that endangers people's lives and quality of life. That brings us to more misinformation about e-prescribing: that it is a panacea for preventing prescription errors. Pharmacies have been converting handwritten prescriptions into electronic prescriptions for more than a decade, so software that catches errors and drug interactions could have been used before with electronic prescription data. Doctors don't need to issue e-prescriptions to reap the benefits of software that checks for correct doses and a drug's conflicts with other medications. In the rush to extol the benefits of e-prescribing, NEPSI also neglects to mention that e-prescribing will introduce new sources of error. It could produce about the same rate of errors as written prescriptions. With written prescriptions, two licensed professionals - the physician and the pharmacist - look at the prescription. Two experienced humans are paying attention. If there are any questions, the pharmacist calls the doctor. With e-prescribing, only one human will look at the e-prescription, the doctor. Indeed, e-prescribing may make errors more common than when doctors write prescriptions. Most people do not know that they cannot keep prescription records private - it's a huge area of ignorance. Now that we are moving rapidly into an e-health system, we need to build it right. Congress should follow the lead of New Hampshire, which passed a law in 2006 to stop illegal and unethical prescription data mining. We need all the benefits that health information technology can bring, but we also need privacy. Technology can provide both - we should never have to choose between our privacy and our health. Peel is a physician and chairwoman of the Patient Privacy Rights Foundation based in Austin, Texas.
Hackers briefly overwhelmed at least three of the 13 computers that help manage global computer traffic Tuesday in one of the most significant attacks against the Internet since 2002. Experts said the unusually powerful attacks lasted for hours but passed largely unnoticed by most computer users, a testament to the resiliency of the Internet. Much rogue data was traced to South Korea. UltraDNS was a particular target. Attacks passed largely unnoticed by most computer users. [Source: AP item, 6 Feb 2007, PGN-ed; Thanks to Lauren Weinstein.] http://www.cnn.com/2007/TECH/internet/02/06/internet.attacks.ap/index.html [See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in Oct 2002. Perhaps the Internet is somewhat more robust now? PGN]
This week brings further developments in the gradual meltdown of AACS (the encryption scheme used for HD-DVD and Blu-Ray discs). Last Sunday, a member of the Doom9 forum, writing under the pseudonym Arnezami, managed to extract a "processing key" from an HD-DVD player application. Arnezami says that this processing key can be used to decrypt all existing HD-DVD and Blu-Ray discs. Though currently this attack is more powerful than previous breaks, which focused on a different kind of key, its usefulness will probably diminish as AACS implementers adapt. To explain what's at stake, we need to describe a few more details about the way AACS manages keys. Recall that AACS player applications and devices are assigned secret device keys. Devices can use these keys to calculate a much larger set of keys called processing keys. Each AACS movie is encrypted with a unique title key, and several copies of the title key, encrypted with different processing keys, are stored on the disc. To play a disc, a device figures out which of the encrypted title keys it has the ability to decrypt. Then it uses its device keys to compute the necessary processing key, uses the processing key to decrypt the title key, and uses the title key to extract the content. ... http://www.freedom-to-tinker.com/?p=1121
The following hard-to-believe text speaks for itself. Fairfax County (VA) prides itself on being techno-savvy, on the cutting edge of the new economy, and other similar blather. Looks like the "cutting edge" is severing Fairfax from the Internet. Being offline would be bad enough, but bouncing e-mail? For three or four days? Amazing. I wonder how many people won't know in advance and will be baffled/frustrated/angered/outraged? *** Fairfax County information technology services will be unavailable beginning February 17 and resume on February 20. My account will be inaccessible during this timeframe and any incoming e-mail will be bounced to the sender. In effect, Fairfax County will temporarily cease to exist online for this period. We apologize for the inconvenience.***
Hugh Thompson reports that he was able to get an airplane's in-flight entertainment system into a significantly unexpected state, by (a) using a numeric keypad, rather than the normal up/down buttons, to enter a value one higher than a Tetris game's preference was intended to allow, then (b) using the normal "up" button to increment the value still further — evidently the programmer had implemented "if(value == 4) {don't increment}" rather than the more robust "if(value >= 4)". When he incremented the value past 127, not only his screen, but every seat-back screen on the whole plane went black, until a flight attendant reset the system. Further details at http://blogs.csoonline.com/node/151 [with some subsequent discussion].
A tree-trimming contractor clearing power lines cut a phone line which serviced a pump-station alarm. The alarm is supposed to be checked twice daily, but the pump was out of commission for four days, leading to a massive sewage spill. http://www.charlotte.com/mld/charlotte/news/16593620.htm?source=rss&channel=charlotte_news The risks are clear; multiple single points of failure (the alarm, the phone line, the pump station, the human verification), no method to check for a failure of the alarm, and a possible flaw in the human logging / reporting side of things.
RISKS-16.3, 5 May 1994, contained an account of the shock of being locked out automatically after closing the door on a stopped car with the engine running. (Not unlikely if you get out to check the roof rack, fetch the mail, etc.) The problem was reported for a Chevvy; I met it years later in a 2001 Ford Focus. Poking around the web, I find reports of the same trouble in car models as recent as 2006 from various makers. Disheartening that such a trivially fixable misfeature should be imitated so widely and persist so long.
One of my favorite case studies is getting a bit long in the tooth, but it has never to my knowledge been cited or discussed in RISKS, so from the better-late-than-never department I give you: http://ase.arc.nasa.gov/publications/pdf/2000-0176.pdf This is the story of the NASA Deep Space 1 Remote Agent Experiment (RAX), and a bug that appeared in the RAX executive despite a then- state-of-the-art effort to develop fault-free software. The approach was very much like the "software-IC" approach that has been advocated off and on for decades (I remember first hearing about it when I was a grad student, and a 5MB hard drive was considered a lot of storage). To summarize and radically oversimplify, a "substrate" layer was developed and exhaustively analyzed using formal methods to insure that it maintained certain invariants (like being deadlock- free). Application code was then developed on top of this exhaustively analyzed substrate, in effect "wiring together" the supposedly reliable components. To make a very long story much too short, one of the applications programmers inadvertently undermined the invariants that were supposed to be guaranteed by the substrate when he needed a feature that the substrate didn't provide. Instead of requesting that the feature be added to the substrate, he just "rolled his own" (it was only two lines of code), and thereby undermined the guarantees that the substrate provided. The resulting bug was never detected during extensive ground testing, but nonetheless failed in flight. It was quite a humbling experience, and it makes a worthwhile read even today. As long as I'm telling war stories, I'll offer up a second one which was never published. This happened in 1989. We were developing code for autonomous mobile robots (what was to eventually become the Mars Pathfinder mission) using a dialect of Lisp called T. We had ported the T compiler from a Sun3 to a Heurikon 680x0 board running vxWorks. We found that when the robot moved its arm the Lisp process would crash intermittently. Forensic analysis after the crash revealed a completely and nondeterministically corrupted heap. This was the probably the most challenging bug I've ever encountered in my career because it was impossible to reliably reproduce, and when it happened it obliterated everything that might provide a clue as to why it happened. Another long story short (it took us over a year to figure it out) the problem turned out to be a bug in the T compiler: in the code emitted to return from a function, the stack pointer was adjusted while they were still live vales on the stack. On the Sun this was not a problem because user processes ran in a different address space from the kernel. But under vxWorks interrupt handlers used the same stack as the process being interrupted. So when an interrupt happened right in between those two instructions the unprotected value on the stack was obliterated by the interrupt handler code, resulting in a gradual corruption of the heap. The moral of the story is that even code that tests perfectly under formal analysis and/or extensive use may yet contain latent bugs.
(From AOL's NY Times news section, pertinent to "RISKS" for several reasons. Complete article: http://www.nytimes.com/2007/02/04/washington/04contract.html Contractors still build ships and satellites, but they also collect income taxes and work up agency budgets, fly pilotless spy aircraft and take the minutes at policy meetings on the war. They sit next to federal employees at nearly every agency; far more people work under contracts than are directly employed by the government. Even the government;s online database for tracking contracts, the Federal Procurement Data System, has been outsourced (and is famously difficult to use).
Internet security experts have long known that simple passwords do not fully defend online bank accounts from determined fraud artists. Now a study suggests that a popular secondary security measure provides little additional protection. [Source: Brad Stone, *The New York Times*, 5 Feb 2007] http://www.nytimes.com/2007/02/05/technology/05secure.html?th&emc=th http://topics.nytimes.com/top/reference/timestopics/people/s/brad_stone/index.html?inline=nyt-per
I recently visited a Web site, <http://www.istockphoto.com>, which provides low-cost downloads of photographic images submitted by registered users. It's actually quite nice, and rather professional-looking, and I was interested in uploading some of my photos and perhaps making a few dollars on them. I discovered while registering that, in order to upload images, one has to establish an upload account, a requirement for which is the submission, over the Internet, of a scanned JPEG image of a government-issued identity document, such as a driver's licence or — even better — a passport. Further comment doesn't really seem necessary.
Dick Karpinski suggests in RISKS-24.46 that Paul Robinson's worries about the hardware math functions in the 586 class of processors are not as well founded as his worries about software math functions. I concur. Dick could have told more of the history. William Kahan at U.C. Berkeley has been worrying about floating point calculations in computers for the last four decades and won the Turing Award, the highest award for technical contributions to computing science, in 1989 for these efforts. Intel was interested in defining portable accurate floating point computations, in advance of their introduction of the math coprocessor for the i8086/8 series (i.e., what was to become the 8087). Impressed by Kahan's understanding of the problems as well as his efforts on behalf of Hewlett Packard, Intel engaged him to help further this cause. Kahan worked with a PhD student of his, Jerry Coonen, and Harold Stone, to define a proposal for the IEEE p754 committee which became in large part the IEEE 754 standard. One can read more about it in some notes, for an IEEE Computing article in 1998, on Kahan's WWW site at http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html I was the Teaching Assistant for the graduate numerics course in the Math Department at UCB at the time that Jerry took it. Assessing the assignments was a breeze. One first looked at Jerry's solutions and those of Jamie Sethian (now himself a math professor at U.C. Berkeley) to see how to do it right. (Those are the advantages of graduate teaching-assisting at a place such as U.C. Berkeley. You can always assume that there is at least one student who is better than yourself, and sometimes more.) Jerry finished his PhD, on the FP work, waaay before I finished mine. I remember him telling me that the way to be certain of a good job was to become acquainted with every line of the BSD source code. Those were the days. But even in those days it was expanding faster than one could read it (besides, that was not the right way to get a PhD in Logic and the Methodology of Science, for probably more than one reason :-). To my mind, IEEE 754 is one of the success stories in our efforts to reduce mistakes in computing. It is a pity certain spreadsheet programmers didn't emulate its example. Peter B. Ladkin, Causalis Limited and University of Bielefeld www.causalis.com www.rvs.uni-bielefeld.de
> The most obvious solution would be to decrement the day numbers before 1 > Mar 1900, effectively setting the epoch one day later... That's what Open Office does. Dates in 1-2-3 and most spreadsheets are internally represented as integers with 1-Jan-1900 as day 1. In Open Office, day 1 is 31-Dec-1899, so dates before 1-Mar-1900 are off by one day. This does not necessarily improve the situation. In spreadsheets I've seen, it's quite common to enter dates simply as dates, to mark when something happened, less common to do date arithmetic, and I've never seen anyone doing date arithmetic as far back as 1900. So this change fixes the date arithmetic, at the cost of making dates before March 1900 display wrong. I am not a big fan of Microsoft, but in this case I have to agree with them that there's no change to this bug that will make the situation better than it is now. They clearly did think about this change, and rejected it for sensible reasons. John Levine, johnl@iecc.com, http://www.johnlevine.com
Impact of North American Daylight Saving Time changes in 2007 on BlackBerry device users: http://www.blackberry.com/select/dst2007/
Everyone is right: At $13.99 this "Digital" camera looks suspiciously like CVC's ye olde chemical-type cameras of about the same price. I strongly suspect that what CVC calls "Digital" on the box (note they say "Simple Digital Processing") is what we mortals would call non-digital. 'The question is,' said Alice, 'whether you can make words mean so many different things.' Alice in Wonderland, CL Dodgson Leonard X. Finegold, Physics, Drexel University, Philadelphia PA 19104 USA L@drexel.edu Phone 215.895.2740
There was a followup story in which the Defense Department reversed themselves. There were no transmitters. http://edition.cnn.com/2007/TECH/01/19/canada.spy.coins.ap/ I think some American contractors just thought the Canadian coins (probably the thick two-dollar coin which has a gold inner part and a silver outer part) looked funny and a wild idea became a rumour, which became a "reported fact". With field intelligence like that, the "war on terror" will be won any day now, I'm sure... Adam Abrams adamabrams@shaw.ca (604) 685-7634 www.adamabrams.com
Greetings. I've been getting lots of continuing interest and queries in the wake of my blog item from late last year: "How To Tell If Your Cell Phone Is Bugged" ( http://lauren.vortex.com/archive/000202.html ). In an effort to explain this issue in a more demonstrative and somewhat less technical manner, I'm pleased to announce a short free video (under six minutes): "Is Your Cell Phone Bugged?" While I'll admit that the production values are much closer to those of Ed Wood than of Cecil B. DeMille, I hope you'll still find this video to be interesting, or at least amusing. "Is Your Cell Phone Bugged?" Video Access Pages: YouTube (Streaming): http://www.vortex.com/cellbug-vid-youtube Google Video (Streaming & Download): http://www.vortex.com/cellbug-vid-google Lauren Weinstein +1-818-225-2800 http://www.pfir.org http://www.vortex.com http://daythink.vortex.com lauren@vortex.com or lauren@pfir.org
BKCQTOSP.RVW 20061229 "Code Quality: The Open Source Perspective", Diomidis Spinellis, 2006, 0-321-16607-8, U$54.99/C$73.99 %A Diomidis Spinellis www.spinellis.gr/codequality dds@aueb.gr %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2006 %G 0-321-16607-8 %I Addison-Wesley Publishing Co. %O U$54.99/C$73.99 416-447-5101 800-822-6339 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321166078/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321166078/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321166078/robsladesin03-20 %O Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 569 p. %T "Code Quality: The Open Source Perspective" The preface points out that it is easy to test for the functional requirements of an application: either the program performs the function or it doesn't. Nonfunctional requirements (including such characteristics as reliability, portability, usability, interoperability, adaptability, dependability, and maintainability) are much harder to assess, and yet may be more important. (In an automated train system, for example, the lack of a function to change the schedule from within a given train still allows you to use the train within a given schedule. Unreliability of the braking system means the system is worse than useless.) In addition, "Code Reading" (the title of Spinellis' previous book) is pointed out as the most common activity for developers, and yet is a skill seldom taught in the programming curriculum. The author has avoided using fictional code for the examples in this (and the prior) work by providing sample code from open source software projects, thus using working (but available) source code for illustrations. Chapter one introduces the structure of the text by mapping characteristics from the ISO 9126 quality standard to the chapters and sections of the book. Inherent conflicts between different aspects of quality are also noted. (For example, large numbers of discrete operations enhance the functionality of a system, but at some cost in terms of usability.) Reliability is examined, in chapter two, in terms of common flaws. Examples of such flaws are given, followed by an explanation of the specifics of the problem. This is followed by samples of code that address the problem stated. Each point and section is accompanied by questions and discussion points that could be used in a course teaching the issues of code quality. (Unlike all too many sets of questions these are rigorous and challenging. Sometimes they may be a little bit too demanding: occasionally the discussion would require intimate knowledge of the internals of a specific programming language.) The chapter ends with a summary of the points and factors covered. Various security vulnerabilities and coding points are illustrated in chapter three, but, in comparison to the rest of the work, this material is weak and disappointing. Performance issues in relation to time are reviewed in chapter four, and to space in five. The different factors of latency and bandwidth, and the trade-offs between memory and speed are noted. It is rather odd that Spinellis is at pains to point out that time efficiencies negatively affect simplicity and portability, while he goes to great lengths to provide suggestions for space optimizations for a variety of specific architectures (which wouldn't help portability either). Chapter six looks at a number of factors relating to portability, between both hardware and operating system platforms. Maintainability is the longest chapter (seven) in the book, and bears the closest relation to Spinellis' previous work on "Code Reading." There is a special section on the characteristics of object-oriented code. Chapter eight, on floating point arithmetic, notes the sometimes surprising sources of inaccuracy. In the information technology and development fields we are constantly obsessed with production of code and the speedy release of the next version. We need to stop and take a good look at the quality of what we produce: as it frequently stated, the greatest source of computer problems is computer solutions. In regard to security, it is demonstrably true that the exploits and difficulties that we find are those that would never have been created if only programmers had paid a little more attention to the fundamental concepts they were first taught. I believe Spinellis' text should be required reading for all programming courses and programs. In addition, those involved with analysis, maintenance, and change control should consider it a bible to be read and re-read until the lessons are firmly implanted. copyright Robert M. Slade, 2007 BKCQTOSP.RVW 20061229 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer