Subject: Re: Internet cybergambling
[This message was received by RISKS@csl.sri.com at 04:00:00 PST Friday, in answer to an earlier request for clarification. It may be freely redistributed. BTW, I just returned from a really lively Computers, Freedom and Privacy 1995; I hope some RISKS readers will provide write-ups of their most interesting sessions. P.G. Neumann]In response to your query, we wish to inform you that Bill Gates will announce later today that Microsoft has entered into an arrangement with Native American Virtual Activities to develop a computerized casino that will be accessible on the Internet as well as by dial-ups, with a toll-free 800 number for U.S. patrons. User-supportive software will be bundled at no extra cost within Windows 95. During April, further software will be added compatibly to Bob, Microsoft's new user-friendly empowerment package — which was officially released yesterday. Bob will even be able to analyze your gambling habits and prompt you if you do something stupid.
Microsoft has struck a deal with the National Security Agency under which good crypto (80-bit SKIPJACK, implemented in software) can be used internationally. The deal involves export controls being waived in return for NSA getting a 1.5% share of the profits, the crypto keys being escrowed by yet-to-be-named agencies of the U.S. Government (insiders suggest Treasury and the FBI), and Microsoft promising to keep the crypto from falling into the hands of undesirable elements such as organized crime. PGP will be used to envelope the electronic communications, and its creator Philip Zimmermann will be on the governing board of NAVA, along with Bill Gates, Richard Stallman of the Free Software Foundation, and Steven Spielberg on behalf of DreamWorks SKG.
Conservative projections indicate that this will be enormously profitable for all concerned, including the U.S. Government — which will instantaneously receive withheld taxes on all winnings via Internet electronic funds transfer, based on the use of a valid Social Security Number. Special extended social-security numbers will be allocated for foreign individuals who wish to participate from abroad, although they will generally be subject to a nonrefundable U.S. tax. Cooperation with tax agencies of foreign governments is anticipated. The newly reconstituted Bureau of Wish and Game will oversee the operation.
The virtual casino will be operated onshore from specially dedicated Indian lands that are not under state or Federal jurisdiction. However, the operation is expected to be so lucrative that it will voluntarily contribute taxes to the two states that will house the geographically dispersed interoperating computer systems designed to ensure very high system availability. For those states in which gambling is illegal, remote services will be provided so that the activities can legally be conducted remotely from another state, such as Nevada or New Jersey. It is likely that states currently banning gambling will be incentivized to change their laws by the standing offer of tax revenues collected from bettors in their home states. Several banking institutions have already expressed interest in extending their automatic teller-machine functionality, trying to preempt competition from the Internet-compatible First Bank of Internet Visa (TM) ATM cards. Overall, this operation has the potential to completely eliminate national and state deficits.
Despite the security and integrity risks raised in a recent article by John Markoff of The New York Times, and some concerns about the socially regressive and antidisestablishmentarian consequences of gambling, there seems to be little opposition to
this remarkable confluence of usually disparate interests — other than from its would-be competitors, Virtual Vegas, the already existing free Internet casino operated from Santa Monica, Calif., and the Online Offshore Casino and Sports Book — which is
expected to open for business next month in the Bahamas.
Risks of being the Cool Site of the Day: (http://www.infi.net/cool.html)
Have you read Alfred Bester's "The Stars My Destination".
I just read the Cool Site of the Day FAQ (http://www.infi.net/CSotDFAQ.html) and I found that the sections on
"How much traffic can my site expect..." (lots),parallel the problems described as "jack jaunting".
"What should I do if I'm selected and I find that my site cannot handle the lads involved?" (replace your cool page with a text only page), and
"Why would I want my site to be a CSotD" (it's the exposure)
In the Stars My Destination, people found they could teleport (jaunte) at will with proper mental focus (What's your URL?). They lived in a world with almost infinitely quick dissemination of information about current events (Netnews, Websites, and CNN).
One result was that when a "cool site" became known, it would become flooded with vast numbers of jaunters from around the world. Many of these jaunters were malicious and used the cover of the millions of other people to perpetrate crimes. For instance, if a fire were televised (today I heard that the Fulton Seafood Market is burning down) thousands of people would jaunte in to be tourists. Some of the people would use the opportunity to pillage.
The parallels between the CSotD and Jack Jaunting break down here, because there is no overtly malicious motive, but there is the likelihood of a Denial of Service Attack.
It's interesting. You want to be a Cool Site. I want to know of the Cool Sites. Being a Known Cool Site may lead to your demise as a Cool Site.
There's nothing new here, this is exactly the same problem as that known as the "Restaurant Review Effect", but it is interesting to see how real life is being recreated in cyberspace.Jerry
So, here's a "real" article, just one little rumor at the end. Some folks objected to me posting rumors, but there are some folks who will talk only on the condition of anonymity, wanting to keep their jobs...
From Computerwoche 12, 24.March1995, page 27
(in German, translation mine, all translation errors mine)
CW-report by Walter Mehl (Hamburg)
"Siemens computer stops switching system (Stellwerk) in Hamburg" From Monday to Wednesday last week all signals at the train station in Hamburg-Altona were on stop. [Must be more, I travelled from Hamburg on Friday and waited an hour because of "computer problems"] Just like it was when track was first invented, the switches could be set only by using a crowbar-sized key to shove them into position. The fault was with a computer from the company Siemens, that had gone on-line the day before.
The train station in Altona is home to pigeons and seagulls. They had 3 days of peace and quiet while scavenging for food between the tracks and sleeping on the catenaries. Since the morning of 13 March, nothing works anymore in the digital switching station: the main computer from Siemens quit after an error in the main memory occurred.
[couple of paragraphs about all the bother people had to go to to get where they wanted to go]
... as we go to print it is not clear if the Deutsche Bahn will demand money back from Siemens.
The Bahn was extremely proud of its new digital helper - in their own publication "Der Zug" they had a long article about it. The new technology cost 62.6 million DM (about 45 million $), Siemens pocketed about 2/3 of that sum. The Siemens computer replaced 8 conventional switching systems, which were installed between 1911 and 1952. They controlled all the switches and signals in the station area. In fail-safe mode all signals are red and the switches can be set only by hand.
In Altona Siemens first [!!!] used the Simis-3216-computer which uses an Intel 486 chip. Siemens makes these system extremely robust: they can take temperatures between -40 and +85 degrees Celsius and can withstand up to 5 times the earths acceleration in force. Not even a signal with 2000 Volt can influence the running of the system. For security reasons they are run in a 2-out-of-three mode, there are 3 identical computers on site, each could work alone. 2 are constantly running in parallel, so that if something goes wrong the replacement one can be switched on immediately, the normal working of the system is given in just a few minutes. When the system is working normally, each of the two computers control each other, and when both determine the same result, then the switch or signal are thrown.
It was determined that the cause was not a hardware problem. The system software was working properly. The shutdown was traced to a design problem: the main memory was too small, it was not sufficient when there were too many events (=trains) and switches. [the rumor mill says it was a stack overflow - would you believe dynamic data structures in a safety-critical system?! The "fix" was to be another half a meg of memory to be on the safe side...]. This critical point was reached in normal ruch hour traffic. The computer [sic, there must be more than one, however!] couldn't work any more and shut itself down.
It took 2 days for the Siemens technicians in the Test Center in Braunschweig to reconstruct and analyse the situation. The computers were running again at 5am on Wednesday morning, and from 2pm everything was running smoothly again. [like I say, Friday it was broken again]Debora Weber-Wulff, Technische Fachhochschule Berlin, Luxemburger Str. 10, 13353 Berlin, Germany <http://www.tfh-berlin.de/usr1/name/weberwu/public_html/>
[You'd think the pigeons would have to watch out for the catenary hot tin roof. PGN]
Two computer crackers have been sentenced to federal prison for their roles in defrauding long-distance carriers of more than $28 million. The two were part of a ring that stole credit card numbers from MCI, where one was an employee. Ivey James Lay, who worked at MCI, was sentenced to three years and two months, and his accomplice, Frank Stanton, received a one-year prison term. (St. Petersburg Times 3/28/95 E6)
When the movie industry was faced with government censorship and regulation, they joined forces and adopted a voluntary rating system that classified the maturity level needed to understand a movie. Such a system could work well for the net because it could, like netiquette, spread beyond national borders. Plus it might forestall strong arm laws like the Exon bill which just passed the Senate.
Here's how it could work. Every person or company that places a WWW page on the network could "rate" the contents of the page by placing it an appropriate directory. A page from my collection of pages might have a URL like:
http://access.digex.net:/~pcw/over13/deepkiss.htmlThe directory with the name "over13" indicates that the material in the page "deepkiss.html" might not be appropriate for someone under 13 years old. I imagine four major ratings like "over0" which is open to all, "over13" and "over17" which contain greater indication that two people can do more than talk to each other with their clothes on, and "over21" which is open to everything.
How would this stop anyone? Kids can still type. Yes, but each WWW browser could be programmed to avoid pages with certain ratings. Parents with young children could place one of these controlled browsers on their computer and be sure that their kids couldn't read rated pages. These browsers for children could also exclude all pages without explicit ratings. This would allow parents to keep their children away from any material that was not explicitly cleared for all ages.
Imagine the cost of prosecuting a nudist camp's web page for simply being on the Net. The Nudists who might be from a liberal region like California could decide to fight on principle. The trial would be a battle of experts trying to pin down "community standards" on a place like the Net. The Nudists would be broken financially. The local district would lose out because the court would be too jammed to prosecute normal criminals.
The NetRate system saves costs and accomplishes more! Legal systems let the grey zone live. Social systems can restrict the grey zone without stopping it.
The following happened to me a while ago when doing one of my computer assignments in Turbo Pascal for DOS. Just so you know I'm running a "Green"/Energy Star/VESA Power Management (call it what you will) 486DX2-66 that is set up to power down the hard disk after 15 minutes of inactivity. On top of that I run your standard vanilla software disk cache software. My story as is follows:
I was editing my assignment and since I hadn't read or wrote to the hard disk in the last 15 minutes the CMOS instructed the hard disk to power itself down (to save power) but I could still edit my program. Anyway when I was finished my current editing session I saved my program, exited the Turbo Pascal IDE and shut off my computer.
Later that day when I went to edit the same program I noticed the program I had saved earlier was not the same one I had loaded up (I had lost half an hours work). What I had found out (with a little experimentation) is this: the file that I had saved was saved in memory in the disk cache. When I exited to DOS, COMMAND.COM was in the cache's memory so the hard drive did not have power-up. When I killed the power with the hard drive off the cache never had a chance to save the file to disk.
The RISK here is obvious:
My recommendations based on my own experiences are:
- Using a PC with DOS, power saving features and a disk cache may result in data loss! This can be particularly RISKy if you like to do your assignments the night before they are due. :)
Perhaps somebody with a little more understanding of disk caches might be better able to explain my experience. As well I've wondered if continually shutting down the hard drive decreases its life.
- If your hard drive powers itself down before you hit the power switch then do a "dir" or some other command that will force the hard drive to power-up. This way when the hard drive comes back on the cache will be able to write itself to disk.
- Switch to Linux. I haven't had this problem since I switched over. :)
In conclusion, this whole incident reminds me of a Kermit the Frog quote "It ain't easy being green." :)University of Guelph, Computer Science Major firstname.lastname@example.org
Dr. Richard I. Cook's phrase is wonderful! What proportion of the RISKS discussed in this list have been due to people depending on the computer candy shell, or being unable to diagnose a problem when the computer candy cracks? Probably at least half... and this problem isn't going to get better, especially with new operating systems that *never* drop the user down to a file or program interface and teach people to think that the pretty graphic user interface *is* the system.
Larry Niven wrote a story, "The Ethics of Madness", where a busy executive went slowly insane because his desktop autodoc had failed. The warning light had burned out... how much more likely when the warning light isn't a light at all, but an icon in
the corner of his PADD?
Huh? — Dates as measured by computers are inherently integers?
Generally computer systems do assume a certain resolution such as seconds and can identify the range of dates (or time spans) representable as integers but whey does that mean they are inherently integers more than any other measure? Naive assumptions lead to judgment rather than evaluation. In fact, Basic typically places the decimal point at the day and then the time within the day is a fraction of the day.
Yes, integers are nice because one has (the illusion of) control over them but they are not inherently safer than floating point since one can easily exceed their representation on either end and very few computers systems ( especially in C) will annoy
you with reporting loss of significance or overflows.
Reading PGN's book, I remembered another problem on our VAX cluster related to date/time. The BT PDN X.25 network (then PSS and now called GNS) had an address which you could call and get the date/time returned accurate to about 2 seconds. The inaccuracy was due to the call setup/cleardown times and the network response. We coded an application to get this data and adjust the VAX system date/time every eight hours at 0210, 1010, 1810, which takes care of GMT/BST changes as they happen at 0205 in theory.
VAXen DECNET networks have features that if times are changed packets can expire suddenly and screwup comms. Also if you run any files with expiry date/times set, you may run into trouble if the clock suddenly advances. (wait for it ...)
BT's online clock (X.121 address 23421920100605) returns a string like this:
TUE 28/03/95 11:32:59 HRS BST
If for any reason the link to the atomic clock at Rugby is not working, the system free runs with a "high" degree of accuracy. Certain fields are changed so you can detect this (I can't remember which, because I cant find original document).
One day on successive calls made one after the other, the results returned could be 30 seconds apart. This was outside the specification, but there was no sing of any loss of the radio link to the master clock displayed in the data. Suddenly all communications on the cluster "hung" and general panic occurred with all concerned with the cluster as it was in production and it was about 10am and users reading their mail. Investigations were complicated by the fact that someone did undo a connector on the ethernet, causing all sorts of addition trouble at the same time.
When the dust settled, we found the whole cluster had a date/time 15 months in the future, and calling the online clock, it was discovered that this was indeed the time being returned! Mail date/time stamps were out, deferred mail got sent, file expired and were removed and batch jobs all started. It took some time to recover from this.
The only explanation given by BT was that there was a problem with the service. We never discovered why we went forward 15 months in May 1988.
The moral - well 1) never assume what is written down actually is what happens. 2) if you use such a system, ensure that the clock can't be set forward or backwards say more than one day in date terms and maybe 12 hours in time terms. 3) remember the first two points and act on them. Sorting out the various collisions of batch jobs, which all started at once over the cluster took some time. The summertime/wintertime change is benign in comparison. It is about time computer manufactures fitted good quality clock chips like in ones watch to keep machine clock in synchronisation and thus save all this trouble. A system that checked the clock time every hour could keep the system clock at least in step and if for any reason the change was more than say 5 seconds, flag the problem with the clock, and just use the system clock until the clock was fixed. No system clock should drift more than 5 seconds in an hour ...
This is a truly amazing claim. If it is true, I would think the business case for purchasing standard equipment in a hospital would be quite strong, even if it was built only on liability reduction. Never mind the fact that 2 patients can be treated in the same window on time that one could before, or that your ROI for each unit of equipment would be higher due to the higher use.It is, indeed, a truly amazing claim. On first blush, it seems to say that hospital personnel spend an average of 40 minutes, for each patient, figuring out how to use the equipment. This is so amazing that I find it hard to believe.
A more careful reading, however, reveals that what is being reduced is not the time to treat each patient, but a number called "post-admittance treatment lag". This sounds analogous to the time you spend waiting in line at the bank. It is very strongly affected by exactly how much extra capacity the system has: as the (average) load increases, sneaking up toward the capacity, the lines get very long. In this situation, minor variations in load or capacity can cause large changes in customer wait times.
In the real world, systems and customers make various adjustments when faced with long lines: customers come back later, evening out the load; the system speeds up by adding resources, or reducing time-per-customer. Also in the real world, since slack is expensive, servers try to minimize it. In the long term, extra slack will cause allocated resources to drift down.
The resulting wait time is a compromise between cost and customer tolerance. In the case at hand, the customers are apparently willing to tolerate an extra 40 minutes in the waiting room. Suppose the hospital managed to improve efficiency by a few percent (by switching to standard equipment, or perhaps by training the personnel better), and the waiting time fell from 70 to 30 minutes. There would be more slack periods, with idle people and idle machines; the system response would be to reduce resources until the expected balance between slack and customer tolerance was restored, probably at an average 70 minute wait.
The notion that the time-per-patient can be reduced 50% ("2 patients can be treated in the same window on time that one could before") seems mistaken — it might apply to defibrillators (largely idle anyway?), but is unlikely to apply to the patient's bed, IV equipment, or staff time. A customer in the waiting room is using only a chair, undoubtedly the cheapest piece of equipment the hospital has.Rich Schroeppel email@example.com
Please report problems with the web pages to the maintainer