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…
Coopers & Lybrand did my rough French taxes on Friday (courtesy of Digital) by computer. When the agent went to pull a screen of information that he had entered on me, he pressed the wrong key and up came personal tax information that was for another employee of Digital in my subsidiary. All the important confidential information was there including salary, real estate owned, etc. The risk here is that information that you give to a tax person on a confidential basis might not be that confidential after all ...
I recently came across an interesting idea presented by a hacker while doing
research for a paper. The hacker said that he could not consider
information property because it cannot be taxed.
But, what if it could. How would you put a property tax on information? How
can you say what the value of that information is? It may be invaluable to
you but it's still just a bunch of bits unless it is used? Maybe if they
were to keep track of each time you used a piece of information and then based
the amount of tax on that?
Would this make people stop collecting HUGE amounts of information that they
keep around just for the sake of "I'll need that someday" or "Why bother
erasing it, it may still be valid."
I just thought that this was an interesting thought...
GOOG ?? (a.k.a. Steve Koinm)
Computing and Information Sciences Internet: goog@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4,
Stillwater, OK 74075 rutgers}!okstate!garnett
I've not heard actual instances of latent viruses being used for copy protection, although one of your correspondents asserted that had been done. Anybody contemplating such a gimmick, however, had better think twice. If you booby trap your house and injure a burglar, or if you string a wire across a hikers-only trail and decapitate an illegal biker, you are criminally liable. Doug McIlroy
RE: Mr. William E. Brown III, it's a good thing his name isn't
William W. Brown III or his card would read W W III !!
RE: systems that don't deal with trailers on names like Jr., Sr. or
III, MCI Mail specifically parses for these.
Vint
[Because Vint does not have one of these trailers,
he cannot be accused of being Self-Cerfing. PGN]
The letters that I find most amusing are the ones that I get every couple
of months that start out long the lines of:
A personal message for JOHN A PERSHING JR:
Dear Mr. Jr:
...
Also, back when I was in college, our fraternity was listed in the phone
book as "Kappa Sigma Frat". One day, we got a bulk mailing declaring
"Good News for the Frat Family" addressed to Mr. K.S. Frat, claiming that
an arduous genealogical search had turned up the Frat Family coat of
arms, which they wanted to send to us (for a price, of course).
John A. Pershing Jr., IBM, Yorktown Heights
[Live off the Frat of the Land and operate under a strict Coat of Alms. PGN]
The Israeli state collection agency issued a warrant for the arrest of a
debtor; since they had only his name (a rather common one) and the town he
lived in, a clerk completed the missing information - full address, ID number
and father's name - from the first entry for a person of the same name he found
in the citizen's registry. That person had a very hard time (including an
overnight arrest) explaining to the authorities that it's not him ("but it is
*your* ID on the arrest form, isn't it?!").
Amos Shapir
National Semiconductor 7C/266 1135 Kern st. Sunnyvale (408) 721-8161
amos@nsc.com till March 1, 88; Then back to amos%taux01@nsc.com
[This one is computer-related in the sense that input data should
acquire an appropriate measure of trustworthiness and then be
handled accordingly. That measure should stay with the data, as
is the case with a security label. PGN]
In RISKS-5.16 (25 July 1987) and again in RISKS-6.16 (27 January 1988), I related news accounts of Bank of America's failed attempt at an ambitious new trust accounting and reporting system. The Los Angeles Times for Sunday, February 7, 1988, carried a lengthy front-page review of the entire debacle, "B OF A'S PLANS FOR COMPUTER DON'T ADD UP" by Douglas Frantz. The article includes lots of background history and economics. Here are a few edited excerpts giving more details than the previous accounts: Last month, Bank of America acknowledged that it was abandoning the $20 million computer system after wasting another $60 million trying to make it work. The bank will no longer handle processing for its trust division, and the biggest accounts were given to a Boston bank. Top executives have lost their jobs already and an undisclosed number of layoffs are in the works. ...The total abandonment of a computer system after five years of develop- ment and nearly a year of false starts raises questions about the bank's ability to overcome its technological inadequacy in an era when money is often nothing more than a blip on a computer screen.... In 1981, the bank had fallen far behind in the computer race. Then-new chairman Armacost launched a $4-billion spending program to push B of A back to the technological forefront. The phrase he liked was "leap- frogging into the 1990s," and one area that he chose to emphasize was the trust deparment.... The bank was mired in a 1960s-vintage accounting and reporting system. An effort to update the system ended in a $6-million failure in 1981 after the company's computer engineers worked for more than a year with- out developing a usable system..... In the fall of 1982, bank officers met Steven M. Katz, a pioneer in creat- ing software for bank trust departments.... In 1980, he had left SEI Corp. in a dispute and founded rival Premier Systems. Katz insisted on using Prime instead of B of A's IBM computers. He boasted that he could put together a system by 1983. Within six months, a B of A - led consortium of banks agreed to advance Premier money to develop a new, cutting-edge system for trust reporting and accounting. Nearly a year was spent on additional research.... The go-ahead to fund to project came in March, 1984. While it was not a deadline, the goal was to have the new system in operation by Dec. 31, 1984. What followed was a textbook structure for designing a computer system. A committee was formed of representatives from each B of A department that would use the system and they met monthly to discuss their requirements. DP staff gathered for a week each month to review progress and discuss their needs with the Premier designers. Some of the DP experts found Katz difficult to deal with occasionally, especially when they offered views on technical aspects of the project. "Don't give us the solutions. Just tell us the problems," Katz often said. When the ambitious Dec. 31, 1984, goal was passed without a system, no one was concerned. There was progress, and those involved were excited about the unfolding system and undaunted by the size of the task. B of A devoted 20 man-years to testing the software system and its 3.5 million lines of code; 13,000 hours of training, including rigorous testing, were provided to the staff that would run the system.... In spring 1986, the system was about ready. Some smaller parts were already working smoothly. Test runs had not been perfect, but the technicians thought most bugs could be worked out soon. A demonstration run had been successful.... Many employees were operating both systems, working double shifts and weekends. Late in 1986, an anonymous letter warned against a "rush to convert" to the new system and told the manager, not a computer expert, that people had "pulled the wool" over his eyes. The executive assured the staff that there would be no conversion before it was time. By then, lines of authority had also changed, making cooperation difficult. By early 1987, tests had been running with only a few bugs. "There were still bugs, but the users felt they could run with it and work out the bugs as we went along," one former executive said. A conversion date was set: March 2, 1987. Just then, half the DP staff was pulled off the assignment. The conversion lasted one week. On March 7, the first of the 24 disk drive units on the Prime computers blew up, causing the loss of a portion of the database. It was past midnight each night before workers retrieving data from a backup unit left the offices. Over the next month, at least 14 more of the disk drives blew up. None had malfunctioned in the previous months of test. It turned out that the units were part of a faulty batch manufactured by Control Data Corp. But by the time the cause was discovered, delays had mounted and other difficulties had arisen. Taken individually, none would have caused the ensuing disaster. Together, they doomed the system. At the same time, the bank decided to move the main staff 30 miles away. Key people quit and morale sank. Another section of staff was told they would be moving from Los Angeles to San Francisco, with many losing their jobs. [Conflicts, turf battles, consulting firms, temporary employees] The bank's first public acknowledgement of the problems came in July 1987. [See RISKS-5.16] An in-house investigation was viewed by many staff mem- bers as a witch hunt. The bank announced further costs and then the trans- fer of the accounts in January 1988. [See RISKS-6.16] The bank's one-time head of the program, since resigned, says, "A lot of people lay down on the floor and spilled blood over this system, and why they abandoned it now I cannot understand. A guy called me this morning out of the blue and said that 95% of it was working very well."
On Saturday 20th February, the B.B.C. Radio 4 programme "Money Box" broadcast
an item about a service provided by a bank in Britain. (I didn't catch the
name of the bank --- a pity.) The service is provided by telephone. No
mention was made about any kind of secret personal code to confirm the identity
of a customer --- security is afforded by the bank's computer's memory of one's
"voice-print", i.e. it can tell who you are just by listening to your voice.
I believe "funds transfer" is one of the services provided.
The representative of the bank was asked about the possibility of someone
impersonating a customer. He replied that the bank had engaged Rory Bremner,
a well-known mimic, to try to mimic other people and deceive the computer.
Rory couldn't.
Suppose someone recorded someone else's voice and played that down the
telephone line? (I think the recording would have to be made while the victim
was using the service, though --- after speaking each digit to the computer one
has to wait for a confirmatory beep. Ordinary fluent speech would not do.)
What do readers think of the idea of dispensing with the secret
personal code?
(Respondents should bear in mind that few people in Britain have telephones
with multi-tone dialing.)
J. M. Hicks (a.k.a. Hilary),
Computing Services, Warwick University, Coventry, England. CV4 7AL
On JANET: cudat@UK.AC.WARWICK.CU (in the U.K.)
On uucp: ...!ihnp4!mcvax!ukc!warwick!cudat
[Distressing to see the old argument, "Our best forger couldn't break
it, so it must be pretty good." Voice-prints are difficult to mimic by
voice, but easy to spoof by playback attacks. On the other hand,
personal codes (PIN numbers) are also not wholly dependable. RISKS
readers know by now that just about every attempt to gain user
convenience has some intrinsic vulnerabilities. PGN]
Following are excerpts from a Usenet discussion going on in the newsgroups
sci.electronic, rec.autos, and (!) rec.ham-radio. The excerpts were selected,
sequenced, and forwarded to RISKS by Mark Brader.
John Moore (john@tower.UUCP):
Here in Paradise Valley, Arizona, we have the dubious distinction of
being the only place in the US where speeding tickets are given by
mail after an automatic device snaps your picture and speed!
Norm Strong (strong@tc.fluke.COM):
Most countries in the world hold the owner responsible for
speeding, regardless of who's driving. This isn't possible
in the US because we have a constitution that prohibits it.
Richard Welty (welty@sunbarney.UUCP):
This* proves to be alterable via local statute. Communities that are
trying out the robocop have altered their laws so that they may charge
the owner if said owner refuses to identify the driver at the time of
the infraction. I wonder if the owner gets any points from this ...
[* No, he didn't mean the US constitution — msb]
Ron Natalie (ron@topaz.rutgers.edu):
I was wondering when someone was going to bring up the question of
"it's not me driving." I have no idea how Arizona deals with it, but
a friend who was stationed in Germany told he how it is dealt with there.
If the driver in the picture is not positively identifiable as you, they
will let you off on the provision that you log whereever you drive. Hence,
if you get your picture taken again, you will have a before the fact
record of if you were there. Not keeping your log truthfully is a
serious offense.
Mad Matt Schaefer (matt@cs.wisc.edu):
I've heard of this system in Europe (Germany?) and somebody told me that it
became unpopular with government officials and other important people because
the ticket and picture came in the mail while the guy was at work and his
wife opened it and saw the picture of the car, plate, speed, husband, and
*the other woman* in the car with him. I thought, "this guy is not gonna get
the welcome he is expecting when he gets home."
> ... 7 packages of microfilm classified "Confidential" were left
> unsecured for 8 months. Each package of microfilm contained 181 sheets,
> listing 4,205 confidential radio frequencies ...
> What does this do to a risk analysis of shuttle safety? ...
Probably nothing much. There is NO SUCH THING as a "confidential radio
frequency" if it is in active use. It's just not that hard to eavesdrop
enough to find out which frequencies are being used, and make good guesses
about what they are being used for. (For example, triangulation will tell
you which transmissions are coming from the range-safety transmitters.)
The real security of the system rests on the secret codes used to trigger
action, and on the difficulty of outshouting the range-safety transmitters
(which send continuously at high power to make it hard for a false signal
to be heard). Refusing to publish the frequency is just an extra obstacle,
and not a very important one.
This whole thing sounds like a tempest in a teapot, actually. "Confidential"
is not a very high classification. Long odds that nothing of real importance
was in those microfilms.
Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Please report problems with the web pages to the maintainer