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…
Blackmail risk from GP thefts (The _Times_ (of London), 2 Dec 1992) A sharp rise in the theft of computers from doctors' surgeries has led to increasing numbers of patients' medical records falling into the hands of burglars and potential blackmailers. In the past six months, the number of general practitioners seeking advice from the office of the data protection registrar after the theft of a surgery computer has risen by nearly 700 per cent. Officials fear that files could include information about public figures that buyers of stolen computers might use maliciously. The office, based in Wilmslow, Cheshire, has heard of 20 thefts during the past six months but believes there are many more as holders of personal, electronically held information are not legally required to report a theft. Previously there had been about six thefts a year. The Data Protection Act's eighth principle does, however, require GPs to have tight security to protect patient records held on computers. Eric Howe, the data protection registrar, yesterday warned GPs to review their security. PCL's comments: There are a number of interesting observations to be made on this report. First is the classic scare-statistic fallacy. A 700% increase sounds dramatic, and is doubtless significant. However, an increase from three to twenty is much less startling. More important, is the lack of any requirement to notify the authorities of the theft of equipment containing personal information. If this is really the case, it would appear to be a serious loophole in the Data Protection Act. As I understand it, the implication is that you are only responsible for the security of your data until your security measures are broken! Finally, one must seriously ask: why was the data not encrypted? I strongly suspect that the thefts are for the equipment, not the data. If all data were DES-encrypted (for example), at the very least it would be protected from the prying eyes of amateur thieves. Let me re-phrase that: (possibly) professional thieves, but amateur cryptanalysts. I'm prepared to bet a small sum, at moderate odds, that the database systems that are in common use do not have easily used encryption, designed for reasonable security but for use by non-experts in cryptology. Perhaps a requirement for databases to be used by GPs and the like is the automatic encryption of all records held on disk. Only government action could force such a requirement.
During the entire 5 years of undergraduate work at San Jose State, I was a member of the marching band. Each year the Band-Aides, a group of 8 or so young ladies who danced with the band, sponsored one of their members for homecoming queen. Each year, that young lady won the election. I found that quite interesting since there were only 120 men in the band and a few additional hanger ons in a 20,000+ person student body. I also ran the college computer center for the last 3 years and had the "honor"of opening up the computer center for the committee that counted the votes for the homecoming queen election. Each ballot consisted of one mark-sense card from which one nominee was selected. The cards were run through an IBM 519 to convert the pencil mark to one punched hole on the card. A special program was written, author unknown, to count the votes and determine the winner. The entire counting process started about 1800 hours and ran until about 2200 hours. The first year I watched this process, one of our journalism students managed to get one of the San Francisco TV stations to run a live special about this unusual use of computers. So the main part of the computer room was filled with the TV crew and their equipment. Not wanting to be part of the show, I retreated to a separate room to the side of the computer that had window access to see the computer console. Near the end of the count, while the journalism student was describing the process live on TV, the computer "crashed". I was not able to determine why, but the program was used for other similar counting tasks without problems. However, not all was lost. The operator stated that he had just looked at the counts and knew what they were. He would restart the program, restore from memory the counts, and the counting could continue as if nothing had happened. A big deal was made about how a human had saved the day. About that time I recognized the operator as a fellow band member. Sure enough, our candidate won with a resounding margin.
Several weeks ago, I completed a 2000+ mile offshore trip to relocate my home, a 36 foot Pearson sloop, the Shearwater, from Houston, Texas to Washington DC. Just prior to the trip, I purchased a Magellen Global Positioning System (GPS) receiver as an aid to navigation. The Shearwater is already equipped with a Micrologic Loran, so, in a sense the GPS was a backup - and the Loran was already a backup to Dead Reckoning - and a sextant. Somewhere off Port Eads in the Gulf, the GPS began reporting high speeds (70+ knots) and a position far from my current location. I contacted the Coast Guard to request a GPS report - and they had no indication of errors. After some discussion to assure them that I was in no danger - and knew where I was, I logged the incident and was about to go back to sleep. [others were on watch] Five other boats contacted me to report that they, also, were seeing GPS position and velocity errors. I recontacted the Coast Guard to tell them it was probably not my receiver - although I neglected to ask the others if they were on different receivers. They were unable to accept a report and forward it to GPS control for conformation. What is the risk? For a boat using GPS for navigation (that is long-range position confirmation), the risks are small, especially with sufficient backup devices). Since the outage only lasted about 3 hours and I only went about 18 miles during that time, the inconvenience was very minor. Suppose, however, I had been piloting - rather than navigating - that is entering a harbor or avoiding an obstruction with only a small margin of error. And suppose, also, I had only one means of navigation and had not maintained an accurate dead reconing plot - the normal case for most recreational sailors - and apparently major oil tankers. Well, this could have been a more serious incident. Now, suppose I was an aircraft depending on GPS for navigation. Even if you don't use it as the sole means of navigation, GPS (or Loran) is so friendly, so precise, and correct so often that is very easy to fall into the trap of believing it when it is incorrect. The risk, I believe, is twofold. First, the Coast Guard was not aware of the outage and once informed had no means of informing others or the GPS control station. Loran outage reports are accepted, coordinated, rebroadcast and followed up by the Coast Guard first getting the report. Second, unlike Loran, my GPS (and the others operated by the folks I spoke with), reported correct operation, high accuracy, and acceptable performance - that is good geometric separation. Thus, if you were flying and were reported in a place different than you believed, you might believe the report - especially since it was, in one of the cases, close enough to be believable under flying speeds/conditions. I see a problem in the making and don't know who to tell. /Stu Bell Stuart Bell, MITRE Corporation, Z646, 7525 Coleshire Drive, McLean, VA 22102 stu@MITRE.ORG 1-703-883-1276 Fax: (703) 883-5519
... It does behoove us, from a safety standpoint, to correct what are known as "insidious hazards" around the home and office. Doug mentions the eject roller on his laser printer. My own suggestion is to take a plastic car windshield scraper that has the nylon bristles for removing snow, cut the handle with the bristles to length, and glue it to the top of the printer ejection area. The paper easily pushes under the bristles, but little to nothing penetrates them when trying to enter that area. I've done this on my Imagewriter II when I discovered a curious ferret had lost whiskers when inspecting the printing head as it whipped back and forth. Cost? $1.95 or so at Kwik Shop. If you have long hair, such as I, a piece of nylon cut from some ladies hosiery and taped over the fan exhaust will do little to impede air flow and does work well to keep hair from being chewed up. If it is placed on the input side, it also makes a dandy dust filter. For those with metal desks or work benches, did you run a ground strap off the desk before playing with that flakey monitor? As my Occupational Safety instructor would pound into us, "It's the little things that'll get you!" Luckily, most of these are very inexpensive and quite simple to fix. In some companies, such fix suggestions are worth their weight in gold as they lower insurance premiums and prevent injury downtime. To best see just how sly and innocuous these hazards can be, I suggest reading a book for new parents that goes into detail on how to child-proof the home. Many of these things apply to offices as well. Your friendly OSHA representative, next time he stops by, will also be happy to point out hazards that might not be covered under OSHA regs. Dan Sorenson, DoD #1066 z1dan@exnet.iastate.edu viking@iastate.edu
The November 30th issue of _AutoWeek_ details the risks of using radar to prevent bus accidents. Greyhound has developed a system called VORAD to warn a bus driver if there is a car hidden off his right or if he's following too closely. The problem is the system sends a radar signal 10 times a second. An _AutoWeek_ reader and bus driver reports that more than once he's been passed by a car moving at speeds in excess of the speed limit and watched their radar detector light go off. Unfortunately the speeder usually pulls in front of the nearest large target (you can guess what) and *slams on the brakes* to fool the non-existent Smokey. And, of course, busses go a lot better than they stop... I find it funny that a system designed to prevent accidents could potentially cause accidents by encouraging other drivers to make unsafe maneuvers. Alan Dahl, Cellular Technical Services 2401 4th Ave., Suite 808, Seattle, WA 98121 PH: (206) 443-6400 alan@ctsx.celtech.com ouunet!ctsx!alan
[This is from the latest issue of Airliners (Winter 1992); I'm amazed I haven't seen anything about the incident elsewhere. I'm posting the article to sci.aeronautics.airliners as well and will pass along any RISKS-related discussion that comes up there. KS] A310 Aerobatics Following an autopilot-coupled go-around, the pilot attempted to counteract the autopilot's programmed pitch-up by pushing forward on the control column. (In most circumstances pushing on the control column disengages the autopilot but automatic disconnect is inhibited in go-around mode. The autopilot should be disconnected or a mode other than go-around should be engaged through the FCU - Flight Control Unit.) As a result of the control inputs, the autopilot trimmed the stabilizer to -12 degrees (nose up) to maintain the go-around profile, but the elevator was deflected 14 degrees (nose down). After climbing about 600 feet (to around 2,100 feet) the autopilot captured its preselected missed approach altitude and disconnected as the go-around mode was no longer engaged. In the next 30 seconds, the grossly mistrimmed A310 pitched up to 88 degrees and airspeed dropped to less than 30 kt. (The stall warning activated then canceled itself as the airspeed fell below usable computed values and the autothrottle system dropped off.) At 4,300 feet, the A310 stalled, pitching down to -42 degrees while the pilot-applied control inputs showed full up elevator. Airspeed increased to 245 kt then the aircraft bottomed out at 1,500 feet, pulled +1.7 g, then climed rapidly. The second pitch-up reached 70 degrees followed by a stall 50 seconds after the first. The nose dropped to -32 degrees and airspeed rose to 290 kt and the aircraft bottomed out at 1,800 feet. On the third pitch-up (to 74 degrees), the A310 climed to 7,000 ft then stalled again, about 60 seconds after the second stall. This time airspeed reached 300 kt in a -32 degree nose down attitude before the aircraft leveled off at 3,600 feet. The fourth pitch-up reached 9,000 feet but this time the crew's use of thrust and elevator control (and very likely retrimming the stabilizer) prevented a stall and the A310 leveled off at 130 kt. Speed then increased accompanied by another milder pitch-up to 11,500 feet where control was eventually regained. All aircraft systems operated in accordance with design specifications. The reaction of ATC (the incident happened at Moscow) or the passengers is not recorded. Karl Swartz, 2144 Sand Hill Rd., Menlo Park CA 94025, USA 1-415/854-3409 kls@ditka.chicago.com uunet!decwrl!ditka!kls Send sci.aeronautics.airliners submissions to airliners@chicago.com
DISTRIBUTED SYSTEMS ENGINEERING JOURNAL --- Call for papers
A new journal on all aspects of the architecture, realisation and management
of distributed computing systems, for practising engineers and researchers in
the field.
First issue July 1993
Co-published by The British Computer Society, The Institution of
Electrical Engineers and Institute of Physics Publishing
Honorary Editors
Professor David Hutchison, Lancaster University, Department of Computing,
Bailrigg, Lancaster LA1 4YR, UK. Tel: + 44 524 593798 Fax: + 44 524 381 707
Email:dh@comp.lancs.ac.uk
Dr. Rafael Alonso, Matsushita Information Technology Laboratory
182 Nassau Street, Princeton, New Jersey, 08544 USA
Phone: + 1 609 497 4600 Fax: + 1 609 497 4013 Email: alonso@mitl.com
Dr Morris Sloman, Imperial College of Science, Technology and Medicine,
Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK. Tel:
+ 44 71 589 5111 ext 5040 Fax: + 44 71 581 8024 Email: mss@doc.ic.ac.uk
Editorial Board includes:
Dr Gordon Blair, Lancaster University, UK
Dr Brian Carpenter, CERN, Switzerland
Dr. Chris Cooper, Rutherford Appleton Laboratory, UK
Professor Flaviu Cristian, University of California at San Diego, USA
Mr Michel Gien, Chorus Systems, France
Professor Fred Halsall, University College Swansea, UK
Dr Peter Harrison, Imperial College, UK
Dr Ian Leslie, University of Cambridge, UK
Professor Peter Linington, University of Kent, UK
Professor Andrew Lister, University of Queensland, Australia
Professor Krithi Ramamritham, University of Massachusetts, USA
Professor Santosh Shrivastava, University of Newcastle, UK
Dr James Stamos, IBM Research Division, USA
Dr Ralf Steinmetz, IBM European Networking Centre, Germany
Dr Joseph Sventek, Hewlett-Packard Company, California, USA
Professor Mario Tokoro, Keio University/Sony CSL, Japan
Dr Ian Wilson, Olivetti Research Laboratory, UK
Scope
The area of interest of this journal centres on the integration of
processing, storage and communication subsystems within a distributed or
networked system. The emphasis will be on distributed rather than parallel
processing and on practical engineering papers rather than theoretical
approaches. We particularly welcome papers from industry and those which
are based on implementation experience.
Distributed Processing
Distributed processing architecture
Distributed operating systems and environments
Standards and open distributed processing (ODP)
Configuration and management of distributed systems
Computer architecture support for distributed processing
Language support for distributed processing
Algorithms and protocols to support distributed processing
Computer Networks
Local, metropolitan and wide area networks
Network architectures and protocols
Network management
Communications and network standards
Open networking and open systems interconnection (OSI)
Multiservice networks
Storage and Databases
Data modelling
Distributed data bases
Distributed transaction processing
Information retrieval and transformation
Object stores
Information and file servers
Hypermedia systems
Information Systems & Applications
Distributed multimedia systems
Advanced home, business and industrial systems
Computer support for cooperative work
Distributed programming support environments
User Interface design
These four main areas would be linked by consideration of system
dependability, fault tolerance, security, performance engineering,
timeliness or other architectural issues.
Submission Address
Submit five copies of papers for consideration to:
The Executive Editor, Distributed Systems Engineering Journal
The Institution of Electrical Engineers, Michael Faraday House
Six Hills Way, Stevenage, Herts. SG1 2AY UK
Phone: + 44 438 313311 Fax: + 44 438 742 840
Email: ieeproc@dm.rs.ch
If you need further details on the scope of the journal and other editorial
matters, contact the Honorary Editors.
Brief guide for authors
Contributions will be considered for publication in Distributed Systems
Engineering Journal if they have not been published previously and are not
under consideration for publication elsewhere. They must be in English and
should typically be 5000-6000 words in length.
The title page must include:
i) title of article,
ii) name(s) of author(s)
iii) address(es) of establishment(s) where work was carried out;
iv) short title of not more than 50 characters.
v) abstract of not more than 200 words.
Details of format for final submission will be provided for accepted
papers. Authors who require more detail on presentation and style should
consult the booklet Notes for Authors, obtainable free of charge from IOP
Publishing at the address below or from the IEE.
Acceptance of papers for publication is subject to a peer review procedure
and may be conditional on revisions being made in the light of comments
from referees. However authors are solely responsible for the accuracy of
statements in a paper.
There are no page charges, and 50 offprints of each article published will
be supplied free of charge to the principal author.
Colour reproduction of illustrations is available but authors or their
institutions are asked to pay the additional costs incurred over and above
normal black on white reproduction. Authors requiring further advice are
invited to contact: the Production Manager, IOP Publishing Ltd, at the address
below.
Articles Submitted in Electronic Format
Articles can be submitted in Electronic format on IBM PC compatible or
Macintosh Discs. The publishers can accept TEX source code. Authors who
intend to submit final version in electronic format should still provide
hard-copy versions for refereeing as normal.
For more details and specific guidelines on the preparation of articles in
electronic format, please contact:
The Electronic Production Manager,
IOP Publishing Ltd, Techno House,
Redcliffe Way, Bristol BS1 6NX, UK.
Tel 0272 297481; Fax: 0272 294218. Email: ioppl@gec-b.rl.ac.uk
Please report problems with the web pages to the maintainer