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 27 November issue of New Scientist has an article (page 20) about a heroin smuggling ring convicted with the help of evidence obtained from a pocket computer. The smugglers used the computer, a Psion Organizer, to store information about deals; after the deal was done, the information was erased. However, the Organizer uses EPROM storage, so information wasn't erased, but flagged as being unavailable. After seizing the computer, customs officials took it to Psion where in-house software recovered the information.
I thought RISK readers might be interested in some of the lighter risks
associated with the use of high technology in twelve metre yachting.
Not only must keels be covered!
CUP INFO RANSOMED (From Computing Australia, 1 December 1981)
A stolen package of floppy disks holding sensitive telemetry data from one
of the America's Cup syndicates has been recovered after being held to
ransom through a hacker's bulletin board.
The theft of the 17 disks came to light on a bulletin board called Inter-State
Connect, where a note was posted originally asking $10,000 for them.
It is not known which syndicate had the disks stolen as no name appeared
on them and none of the yachting teams have admitted ownership.
The disks were stolen in Fremantle and turned up in Melbourne where computer
security analyst, Stuart Gill, negotiated the retrieval of the disks through
a shadowy organisation of hackers known as TechHack.
TechHack became involved in the negotiations after being accused of mounting
the ransom operation. In order to clear its name, TechHack acted as the
intermediary between Gill and the hacker responsible for the ransom notice.
Computing Australia has obtained a printout of the negotiations which took
place on the bulletin board.
It reads:
As at 21/10 we require the sum of $2,500 for the exchange of the disks
Confirm there are 17 and you are aware from our Perth contact that they
are Kosher. We cannot continue talking for much longer as we don't
think you are serious.
In the end, the stolen property was retrieved with no exchange of money.
It is believed a number of syndicates approached Gill for copies on the disks
on the pretext of establishing where they came from.
<end-of-article>
Peter, your recent note on the frequent but rarely discussed topic of "where to place the blame" concerns me. It seems that we in computers and computer science have some what ill-defined concepts of CAUSALITY (where DO we put the blame?), (non)determinism, and our poor use of reductionism. Other similar postings on modeling and empirical data as final proof also concern me. Consider, the mistake we make when we confuse WORK and EFFORT: we get Brooks' mythical man-month. (Brooks' classic example was 1 woman => 1 baby in 9 months, therefore 9 women => 1 baby in 1 month.) And there are many people who don't see that this generalizes in high-performance computing in terms of mythical MFLOPS: some programs are not decomposible into parallel parts. And I suspect this is also manifest in the way we use redundancy in fault-tolerant computing (multiple CPUs in hot-start configuration which could be used for parallel computation but are used for reliability instead). I think we misunderstand causality for two reasons: 1) Our empirical foundations tend to be a bit weak. (We put theory quite high in esteem.) In part, mathematical theory is our solution, but it also a source of bias. I know many will disagree with this latter conclusion including PJD. We try to envision problems outside of the complexities of the `real' world (modeling and simulation). Where as theoretical physics had experimental physics to fall back on, computer science does not have a good equivalent. 2) Some of our ideas do not tend to generalize across computers as mathematical concepts generalize across the mathematical sciences. We are not really JUST a mathematical science. The recent econometric postings enforce some of this. I heard an interesting thing about the way computing is done in third-world countries (I heard the USSR was/is in this category) where computing is expensive and thinking is cheap: Theoretical CS is held is high esteem because when a mistake is made in hardware or in a project it becomes glaringly visible to all. When mistakes are made in theoretical CS (and probably math to a lesser degree), there are so few people who understand these ideas, and some ideas are so specific, that only a few people can criticise them (fewer/less negative reinforcement and punishment). Consider the discussion on testing: computer people talk about testing with respect to the correctness of a specification, but we don't talk about testing with respect to the `real' world. Testing of accounting programs is one thing, but testing of models of the physical world like fluid dynamics or population quality of life are different things. Perhaps I should use the word measurement here. There are numerous cute computer models with graphics like the LLNL crushed cone shown at the 1984 SIGGRAPH or similar fluid dynamics works here. (References provided on request.) I fear that we computer types have a greater chance of losing touch with reality. This would also make us among the poorest judges in our own discipline for things such as the Turing Test because the Test is ultimately an empirical endeavour. Anyway, these are some initial thoughts I have composed over the past few days about computing's poor basis in empiricism. --eugene miya
There's been a lot of discussion about the Audi problems and I remembered a similar incident. The Sept. 1984 issue of Consumer Reports included a review of the Mitsubishi Starion. Under the heading "Defect of the Month" they described uncontrollable acceleration that was only stoppable by turning off the ignition. The problem was eventually solved by replacing the engine microprocessor and the problem was reported to the National Highway Traffic Safety Administration. It seems to me that NHTSA should be getting the Audi complaints and telling Audi that they should look at the source of the problem. Precedents are a good way of convincing people that there's a problem. Miriam Nadel
I know of a similar case that never made it to court. The computer security
administrator at Roche, the drug company had been plagued by a hacker who
auto-dialed the entire Roche phone system in sequence. It took a lot of
phone calls from company management to convince the phone company that this
was not just someone with fast fingers and a touch-tone phone. They laid a
hacker trap on one of the PC`s and traced the call. Once the suspect was
found, it was even harder to get him arrested since he was in New York and
Roche is in New Jersey, which somehow got the FBI involved.
The perpetrator was brought into the police station and had the riot act and
the fear of God scared into him. He was not charged — because there wasn't a
no trespassing sign on the hacker trap identifying the system as private
property of Roche.
[A tough Roche to phone? (All Roche leads to phone?)
Yes, this has been a common problem in the past... PGN]
I'm afraid to say that most of the programs all use very similar algorithms with almost identical buy/sell setpoints. That's where the problem probably lies. The solution is to predict the changes in the market that would result from these (very predictable) programs operating at the same time, and I am sure that some smart fellow will be making a lot of money that way...
[...] I'm told that the John Hancock Building in Boston is built like this.
The Defense Technical Information Center (DTIC) acts as the central repository of scientific and technical information for the Department of Defense (DoD). One of the four online databases which DTIC maintains is the Technical Reports Database. It has recently come to our attention that the 29 September 1986 issue of the RISKS Digest [RISKS-3.70] was informed of a "new policy" by DTIC that stated that technical report titles be designed with keywords positioned in the first five words of the title. THIS IS NOT AND NEVER HAS BEEN A POLICY OF THE DEFENSE TECHNICAL INFORMATION CENTER. Apparently, this erroneous information was forwarded to this forum as an example of the risk to accurate dissemination of information caused by faulty programming (or programmers?). The policy of this organization regarding technical report titles is that they should reflect the author's effort to describe the content of the report. In trying to determine from where such an inaccurate statement might have developed, our conclusion is that the individual (outside this organization) who proposed the "policy statement" misapplied a long standing DTIC search retrieval capability. Our automated retrieval system has a search algorithm which is constructed from the first five words of the title. It allows a searcher to identify a report title and bibliographic citation from our online collection of 1.5 million titles. The search retrieval algorithm works for any word of the first five words of the title whether they be prepositions, articles, or keywords in identifying the bibliographic citation associated with a title. For further information please contact: R Paul Ryan, Director, Office of User Services, Defense Technical Information Center, Cameron Station, Alexandria, VA 22304 Phone (202) 274-6434 AV 284-6434
Please report problems with the web pages to the maintainer