by jurvetson
Molecular biologist on the dangers of pornoscanners
[Via Boing Boing]
Jason Bell, “a molecular biologist and biophysicist… a Ph.D. candidate in Steve Kowalczykowski’s lab at UC Davis,” has posted a detailed critique of the research on the safety of airport backscatter radiation scanners. His specialty is the “molecular mechanism of how mutations in the breast cancer susceptibility gene, BRCA2, result in cancer,” and he’s posted a detailed, lay-friendly explanation of the scientific concerns expressed by the UCSF team that believes that they are unsafe for use.
Which brings me to how the scanner works. Essentially, it appears that an X-ray beam is rastered across the body, which highlights the importance of one of the specific concerns raised by the UCSF scientists… what happens if the machine fails, or gets stuck, during a raster. How much radiation would a person’s eye, hand, testicle, stomach, etc be exposed to during such a failure. What is the failure rate of these machines? What is the failure rate in an operational environment? Who services the machine? What is the decay rate of the filter? What is the decay rate of the shielding material? What is the variability in the power of the X-ray source during the manufacturing process? This last question may seem trivial; however, the Johns Hopkins Applied Physics Laboratory noted significant differences in their test models, which were supposed to be precisely up to spec. Its also interesting to note that the Johns Hopkins Applied Physics Laboratory criticized other reports from NIST (the National Institute of Standards and Technology) and a group called Medical and Health Physics Consulting for testing the machine while one of the two X-ray sources was disabled (citations at the bottom of the page).
[More]
The first is that the machines might be fine in a lab setting but what about in the real world, when hundred of these are in place around the US? This letter from Jason highlights some of my concerns also. Without a much better idea of how they actually work in the real world, I’d be cautious.
The second one is the Therac 25, a machine designed for radiation therapy. Due to poor software engineering, the machine gave lethal doses of radiation to several patients. Reading about their deaths makes one very concerned about any software driven machine and the possibility of very rare but very lethal combinations of systemic operations.
The machines had worked fine for hundred of patients but then, often due to an unfortunate set of circumstances involving software and human errors, would deliver much higher doses than expected.
There were also several elements of human error that contributed. These machines are under a lot of software control to provide the right dose. What happens when a bug occurs? With the Therac 25, an unusual combination of key strokes resulted in lethal doses.
And all the time, the company told people that it was not possible for the machine to overdose people.It also appears likely that they told operators this even after the company was aware of overdosing accidents.
Has the software been independently reviewed and sustained rigorous beta-testing to make sure lethal bugs are gone? Every piece of complex software has bugs. If these machines malfunctioned, what would the largest possible dosage a person could receive?
And what about training? The Therac 25 would display a malfunction warning when it was improperly used and the operators would just override the warning. And these were medical technicians with a lot of training. What sort of training does the TSA have?
The final thing is to remember that the TSA scanners use Windows XP for their operating system. Are there bugs associated with that OS that could cause a problem? These machines may be networked. Can someone hack into the system and disrupt the exposure control?
I’d like to know more about the development of the software being used. In my opinion, this software should be opened up for all to examine. The safety of American travelers should not be in the hands of proprietary software.
Let me end with a quote from an article about the Therac-25 accidents (my bold):
With information for this article taken from publicly available documents, we present a detailed accident investigation of the factors involved in the overdoses and the attempts by the users, manufacturers, and the US and Canadian governments to deal with them. Our goal is to help others learn from this experience, not to criticize the equipment’s manufacturer or anyone else. The mistakes that were made are not unique to this manufacturer but are, unfortunately, fairly common in other safety-critical systems. As Frank Houston of the US Food and Drug Administration (FDA) said, “A significant amount of software for life-critical systems comes from small firms, especially in the medical device industry; firms that fit the profile of those resistant to or uninformed of the principles of either system safety or software engineering.”[2]
Furthermore, these problems are not limited to the medical industry. It is still a common belief that any good engineer can build software, regardless of whether he or she is trained in state-of-the-art software-engineering procedures. Many companies building safety-critical software are not using proper procedures from a software-engineering and safety-engineering perspective.
Most accidents are system accidents; that is, they stem from complex interactions between various components and activities. To attribute a single cause to an accident is usually a serious mistake. In this article, we hope to demonstrate the complex nature of accidents and the need to investigate all aspects of system development and operation to understand what has happened and to prevent future accidents.
The TSA scanners are part of a complex system comprising commercial entities and government bureaucracies overseeing underpaid workers operating potentially dangerous machines. I’d want a lot more information regarding many elements of this complex system than I have gotten so far.