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…
[This is in response to a query from me to DWW on this subject. Thanks to Debora for sharing with us what she knows. PGN] The Deutsche Bahn AG, the German train company, has been working round the clock for a long time to a) electrify the state of Schleswig-Holstein, which is just north of the city-state Hamburg, and b) to install a full computerized train regulation system. The big traintable change is scheduled for next Sunday (March 26), when the daylight time change takes effect, I believe. They went on-line with the regulation system last week and all h*** broke loose. It was okay for the first few hours, and then suddenly went berserk. I don't have all the details, as I have only listened to radio news the past few days, but they ended up having to route all traffic around this major switching point. The train station in Hamburg Altona, where the diesel locomotives are removed and electric ones put on for continuing trains, or where most people just have to change trains, was put out of service. People had to take the S-Bahn or a bus to the main train station, and ended up missing connections. (And then we have the problem with the local trains being fuller than Indian trains because of a special super-cheap deal on weekends, but that's another and computer-unrelated story.) I do not know for certain if Siemens is the main manufacturer, but I suspect that it is them together with AEG. They just founded a company together with ABB in Sweden to combine all their rail knowledge. Yes, they subcontract out a lot, some to a little company in Kiel, a bunch to Third-World company (but this is just rumor). How could this pass the testing phase? Well, this is not the first time Siemens has boo-booed (remember the microphone system in the Bundestag? There have been many others). My personal opinion is that Siemens/Sietec does not have control of their Quality Assurance and there are too many programmers there that believe that they can do no wrong, and bosses who believe them, because it costs too much to actually do massive testing. German programmers tend to take it as a personal insult when a fault is detected in code that they have written. Companies like Siemens/Sietec exacerbate the situation. I repeat, this is my personal opinion based on unscientific surveys conducted during drinking and card playing sessions.... so nothing eminently quotable. There should be an article in Computerwoche (German language) soon about it when the CeBit smoke clears, they enjoy reporting about Siemens/Sietec disasters. I'll keep an eye out for more details. Debora Weber-Wulff weberwu@tfh-berlin.de
The Canadian government's first attempt at electronic distribution of its budget last month could have created havoc — but not because of the measures it contains. A virus was discovered about an hour before more than 5,000 disks containing budget information were to be sent to the country's major financial institutions. One expert is quoted as saying the situation could have been catastrophic for banks etc. The RCMP are investigating how the unnamed virus (said to be boot-sector or FAT destructive) had found its way onto the master disk being used to make copies. The master had passed two Revenue Canada virus scans but a last minute check by the company hired to do the copying and distribution turned up the critter. Given the super secrecy and security surrounding the budget, there are serious questions as to how this could have happened. The RISKS involved in the federal government spreading viruses are obvious!
I just heard on the radio an announcement of a new safety project for farmers. Farming is one of the most hazardous occupations, by usual measures, with a significant number of injuries and fatalities happening when farmers get off of a tractor or similar piece of equipment to do a brief task like untangling something, but leave the equipment running. The proposed fix? Use the GPS satellite location system, which will be used by a piece of equipment worn by the farmer and another on the tractor: When they move apart, the tractor gets turned off. I suspect "the risks are obvious", as well as the availability of MUCH simpler technologies to do the distance sensing if in fact that is a good thing to do.... Bob Wilson wilson@math.wisc.edu [This sounds almost as far-fetched as the completely computerized SUNDIAL I conjured up for an editorial in the ACM Software Engineering Notes many years ago, as an example of technological overkill. Ultimately, the sundial would have used GPS to provide automatic dynamic seasonal corrections dependent on longitude and latitude, would track its own movement (no pun intended), and would work at night by simulated sunlight. PGN]
Subject: Reevaluating Our Trust in Computers Computers have, in most cases, improved the overall quality of life for us. When a computer process goes smoothly we are amazed at the speed and accuracy of the machine. But when something goes wrong, it is human nature to want to place the blame upon someone or something. When the problem is minor we can usually laugh it off or write it off as a "computer error", whether or not this is actually true. But, when the problem has caused severe (life-threatening) consequences we need in depth explanations of accountability. Also, the number of people affected by computer errors can range from one person who is directly involved in the use of the computer - to many people who are innocent bystanders. If the operator is the only one inconvenienced by a computer error assuming it created a minor problem, blame can be shrugged off. While at the other extreme, if large numbers of people are affected by the error, blame is sought. Therefore, there are two determining factors which cause us to want to place blame for the occurrence of computer errors. One factor is the severity of the problem and the other one is the number of people affected. With the increasing involvement of computers in our daily lives the number of errors occurring is also increasing. Errors seen many times in the past are still occurring while new errors are cropping up with the use of new technology. The dependent relationships between the software, hardware, data input (whether it is by a person or computer generated), procedures, and the communication links [risks-9.61], create a very complex environment. The blind trust we have in computers and the people who operate or program them may need to be reevaluated. In other words, can and should we always trust a computer operator or a computer with the ever increasing processing of data which affect our lives and then look to blame when failure occurs? Or should we decrease or adjust the trust we place on data input and computers? While I was doing a search for articles at the library on the periodical database and happen to be short of time one night, the computer froze suddenly for no apparent reason. I had already spent 30 of my precious 90 minutes reading abstracts and marking (to print) the ones I thought were relevant. I had not yet printed the abstracts when the computer stopped responding to keystrokes. I asked the reference librarian if there was anything that could be done. He said "Not usually, but try [Ctrl] Z or [Ctrl] [Enter]." I did - but nothing happened. He shrugged. I shrugged and laughed, then moved over to another machine to start my work all over again...how fitting. I would not have enough time to make copies of the articles I searched for and would have to return another day. I probably should not have trusted the computer to get me smoothly through my work that night; I left no time for computer error expecting the computer to be 100% reliable. Cynthia P. Klumpp cklumpp1@vaxc.hofstra.edu
In a recent comp.risks post, Dick Mills speculates that the stability of civilization up to now may have depended on the ineffectiveness of one-to-many communication, and that the Internet condemns us to drown in memetic garbage generated by kooks, fanatics, and evangelists. I suggest Mr. Mills think of it as evolution in action. The people — and civilizations — that survive will be those who learn and teach critical reading and thinking skills. This is strictly analogous to the selection effect of biological plagues. Eric S. Raymond
The risks of cost-benefit analysis that I see are more direct. First, in order to do a cost-benefit analysis, you have to make assumptions about relative values. It is totally impossible to do this in a politically-neutral way. Consider, say, a C-B analysis of a wetland development done by a real-estate developer and and the same analysis done by Greenpeace. No way are they going to be similar. Second, C-B analyses are trotted out as some kind of Gospel. Somebody comes up with the numbers, lawmakers or bureaucrats make decisions, and the public is stuck with the results. What if the analysis is wildly off? Where is the responsibility? I would like to see the organizations who do these analyses post a bond. Won't happen, but it's interesting to think about. Steve Smith Agincourt Computing sgs@access.digex.net (301) 681 7395
[...] Or more generally, cost-benefit analysis skews in favor of what can be "measured" (medical costs, property values, paycheck) at the expense of the "intangible" (freedom, nice-smelling air, peace of mind, a good day fishing, national security, employee loyalty). Where social benefit is easily measured, it skews towards social benefit. Where social benefit is not easily measured, it skews away. I can well imagine a statistical arms race between the two sides of any costly policy, attempting to assign value to the otherwise intangible costs and benefits of the policy. It's also an entertaining game to see what intangibles are considered so important that they should not have a price tag attached (and by whom). David Chase CenterLine Software
In a recent posting, Simson Garfinkel used a reference to Prodigy's former method of handling swap space to point out that certain types of online access systems leave you vulnerable. In today's issue, Frank Ferguson tries to indicate, using details of the MS-DOS FAT and delete function, that such a concern is invalid. They are, or course, both right, but Garfinkel is righter. While Prodigy never did have any specific function in their software to browse and return information from the user's computer to the company, the software did have provisions to automatically update software. This could (although it wasn't) be used to run other types of software without the user being aware of it. But we don't have to pick on Prodigy. Other commercial systems "take over" your machine when you run the front end software. This is, of course, done to ease the burden of use for the subscriber, but it does mean that the online service can basically do anything they want with your computer. (The same, of course, is true for any software, but commercial online systems have the advantage of being in communication with their own software while it is running on your machine.) We need not limit the discussion to commercial services. GUI (graphical user interface) systems tend to have a lot of security loopholes and hiding places anyway. The X system has provisions for a remote system to control your workstation. The various World Wide Web browsers, particularly the graphical ones like Mosaic, have the ability to both transfer files and invoke execution of programs. That's all you need for a really nifty virus/worm ... DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
I content that this behavior *is* a bug. The proof is in the public's reaction to finding bits of "their" files in the Prodigy cache area. To give a human metaphor, imagine a coworker who casually leafs through the papers on your desk while waiting for you to get off the phone. This might be nothing more than a nervous mannerism and he may be totally unaware of what he's doing, but very few people won't be seriously annoyed at him. To avoid even the appearance of impropiety, most people carefully stare into space (or read a magazine) in this situation. Prodigy didn't observe this behavior (which in the computer world would have been allocating the space and immediately wiping the current data); it grabbed some disk space and saved a few seconds by not wiping the existing data... ... and found itself tremendously embarrassed because it violated one of the prime rules of our society (regarding privacy). The fact that we're still discussing this years later proves how sensitive of a nerve it hit! In an era when computers were scarce resources and few people had frequent interactions with one, such behavior could be justified as a valid engineering tradeoff. But computers are now routinely used by a large part of the population, and it is incumbent on the programmer to observe the social conventions even if it proves to be moderately "expensive." Bear Giles bear@fsl.noaa.gov
This "announcement" is so full of holes as to be ludicrous.
1) According to the NC Banking Commission, use of the term "bank", with a
very few limited exceptions, is illegal for anyone but an organization
that is a federally (FDIC) or state chartered, regulated entity. The NC
Banking Commission has taken an interest in this announcement, and is
forwarding the info to the FDIC...
2) "The alternative to personal credit cards for electronic commerce is
based on an FBOI procured Visa (tm) Automated Teller Machine (ATM) card.
The card is prepaid, PIN protected, replaceable, disposable, and good
at over 200,000 Visa/PLUS (tm) ATMs in 83 countries. "
Translation: 'you send us $x.xx to keep on account (with no interest accrued
to you). We deduct purchases from this balance'. What happens if we disagree
on the balance and/or dispute transactions? Because this an ATM card as
opposed to a credit card, normal fraud liability limitations ($50.00 US)
and disputed charge reversals are not in effect. If someone fraudulently
charges against your ATM account, you potentially bear the full loss.
Also, the "vendor" info, sent in response to the specified E-mail request,
indicates that the ATM cards are not "rechargeable". When you run your
balance down, you must buy a new one. FBOI charges a 5% commission to
establish a new card for you (ie - the "setup" fee is 5% of the balance you
wish to put on account; when that runs out, you pay another 5% for a new
card). Since they charge vendors a 5% commission per transaction, FBOI is
keeping 10% of all funds that move through their system.
3) "The safety of FBOI is ensured because access to ATM funds without
possession of both the ATM card and the Personal Identification Number
(PIN) is not possible. ATM cards are also better than credit cards because
their purchase does not require the personal, financial, and employment
background of the consumer."
Here is how a transaction is instigated (from FBOI info):
"*FBOI procedures for creating a vendor E-mail invoice*
FBOI E-mail invoices are a two line message created by a FBOI vendor.
Line one of the message contains the customer Internet E-mail address.
Line two contains the transaction amount in US dollars. This message
must then be encrypted, signed, in ASCII, and in Text using the PGP
command "PGP -seat invoice fboi". The "invoice.asc" is then ready to
be E-mailed to fboi@netcom.com with subject "invoice". FBOI will issue
an E-mail transaction receipt."
"*FBOI procedures for creating a customer E-mail check*
FBOI E-mail checks are a two line message created by a FBOI customer.
Line one of the message contains the vendor Internet E-mail address.
Line two contains the transaction amount in US dollars. This message
must then be encrypted, signed, in ASCII, and in Text using the PGP
command "PGP -seat check fboi". The "check.asc" is then ready to be
E-mailed to fboi@netcom.com with subject "check". FBOI will issue an
E-mail transaction receipt."
FBOI then reconciles the above transactions and sends payment to the vendor
(or credits the vendor's ATM card). Note that FBOI recommends product pricing
at around ONE US DOLLAR for items! (Almost-Freeware, anyone?)
4) "...In addition, consumers can reclaim their funds at any time using
an ATM."
At what service charge per transaction? What limitations on withdrawal
amounts (how many transactions will it take to empty my account)? Any
yearly fees for this privilege? FBOI info is rather vague in this regard.
The only pertinent comment I saw was (pertaining to vendor payment):
"... While the Visa ATM card as a payment method has many
advantages (portable, anonymous, and cash in any country of the world),
your ATM may not dispense the entire payment due to the exchange rate
and possible ATM fees."
5) "...Those services will collect the consumers credit card information in
advance because of Internet security problems."
Since those are still credit card transactions, the consumer has much better
dispute resolution abilities.
6) "FBOI transmits no sensitive information over the Internet and prevents
forgery and impersonation by using Pretty Good Privacy, PGP (tm),
software for all transactions. This freeware provides excellent
authentication and anti-alteration security."
The description of transactions as in (3) above may or may not be subject
to spoofing. I'm not up enough on crypto to comment.
7) "In addition to the unsecured nature of the Internet, consumers should be
hesitant giving out their credit card information to vendors of unknown
credibility."
You mean like FBOI?? Based out of a Netcom account (instead of a .com domain)?
8) "...since U.S. Postal Service and Federal Trade Commission mail order laws
do not apply to the Internet."
The laws may not apply to the Internet per se, but credit card transactions
are still subject to all of the controls of typical "mail order" as is
normally practiced via telephone.
9) "The First Bank of Internet (tm) is not a lending institution, and is not
chartered."
This says volumes.... (see (1), above).
And finally:
"When FBOI procures a Visa ATM card for vendor customers the card
becomes their money. FBOI will be granted access to their funds
through the FBOI customer agreement allowing FBOI to possess a
duplicate card."
^^^^^^^^^^^^^^^^^^
The FBOI card does seem to address some of the security concerns for commerce over the net. The replacement of one number by another does not provide any particular safety, but the limit on the card does restrict the damage. However, inquiring minds want to know: How easy is it, aside from emptying the account, to cancel/change/get a new card? Is there a fee? Is there any recourse if someone empties the account before you do? Does the encryption apply only to the card number, or to the whole transaction, including time and date stamp? Does the encryption software come with the card? Is it a smart card? Do you need a card reader of some type? What platforms is the software available on? Is the user responsible for getting/setting up the software? By using PGP is the FBOI restricting its operations to the US? Is the version of PGP that they are using operating with the RSA algorithm, or another? Is the key size restricted? If this really does work over E-mail, why do you keep talking about ATM? (Does it only work over asynchronous transfer mode networks? :-) DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
In Risks 16.93, fboi@netcom.com (Vinn Beigh) writes:
>The card is prepaid [...]
>The safety of FBOI [the non-chartered, non-bank company] is ensured
...by the fact that it's prepaid, and even if FBOI loses all the money
in the account due to fraudulent transactions, it's _your_ money
that's gone, not their 5[!!] percent!
>The worldwide producers on the Internet can use FBOI services without the
>expense of owning or renting a dedicated Internet server or a World-Wide
>Web site.
Yeah, just get an account on netcom and you're a business! C00L!
>In addition to the unsecured nature of the Internet, consumers should be
>hesitant giving out their credit card information to vendors of unknown
>credibility.
Giving cash to some guy with a Netcom account is OK? Maybe I missed
the smiley, or the original submission was tongue in cheek...
>since U.S. Postal Service and Federal Trade Commission mail order laws
>do not apply to the Internet.
Another safety net for FBOI. What a gig! Tell you what, I now announce the
First International Bank Of The Information Supercollider, you send me money
and I promise not to lose it.
[The money, that is, not the Supercollider. PGN]
Willie Smith wpns@pictel.com N1JBJ@amsat.org
INFORMATION SECURITY INSTITUTE
Sponsored by:
Center for Professional Development
George Mason University
Fairfax, VA 22030-4444
Intensive, Short Courses:
o Information Security Principles and Practice March 27-31, 1995
Instructors: Marshall Abrams, Daniel Gambel, Sushil Jajodia,
Harold Podell, Ravi Sandhu
o Recent Developments in Information Security March 27-31, 1995
Instructors: Marshall Abrams, Daniel Gambel, Sushil Jajodia,
Harold Podell, Ravi Sandhu
o Practical Security in a Networked Environment April 3-7, 1995
Instructors: Marshall Abrams, Ravi Ganesan, Sushil Jajodia,
Brian McKenny, Harold Podell, Ravi Sandhu
o UNIX Security April 3-7, 1995
Instructors: Marshall Abrams, Ravi Ganesan, Harold Podell, Ravi Sandhu
For further information, visit the Information Security Institute home
page through mosaic at http://www.isse.gmu.edu/~gmuisi.
The Preliminary Programme of the AMAST'95 Conference (4th International
Conference on Algebraic Methodology And Software Technology, Montreal,
Canada, July 3-7, 1995) is available on the WWW at the following URL:
http://www.cs.utwente.nl/data/amast/amast95/PreliminaryProgramme.txt
The file includes abstracts of the invited talks, conference schedule,
registration information and registration forms, and accommodation and
travel information. The deadline for reduced registration fees is:
Monday June 5, 1995
The file is also available by anonymous ftp:
host: ftp.cs.utwente.nl
username: anonymous
password: your E-mail address
directory: pub/doc/amast/amast95/
get file: PreliminaryProgramme.txt
More information about AMAST'95 is available from the following sources:
1. For bulletins on current status of the conference:
amast95-info@cs.concordia.ca
Tools and Demos: grogono@cs.concordia.ca
Registration: krishnan@cs.concordia.ca
Local Arrangements: missaoui.rokia@uqam.ca
2. For subscribing to AMAST'95 mailing list:
amast95-request@cs.concordia.ca
Please report problems with the web pages to the maintainer