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…
Early on Sunday morning (19 Jul 1997), a "technical error" caused the contents of a channel on a satellite operated by France Telecom, to be transmitted on another channel, for about twenty minutes. Normally this would have been merely annoying for the viewers of the affected channel. However, the viewers were in (among other places) Saudi Arabia, the channel they expected to be watching was the French government-run, general interest and news station, Canal France International (CFI), and the programme which replaced it was... a hard-core pornographic movie which should have been shown on the subscription-only, encrypted French domestic station, Canal Plus. I presume that the incident involved two channels on different satellites, since CFI is carried on Arabsat and Canal Plus on the European-oriented Telecom satellite system. My bet would be that the channel numbers are the same and the operator was pointing at the wrong satellite while hitting "Go". Results: Arabsat has cancelled its contract with France Telecom, claiming (it would appear with some justification) that France Telecom had not "honoured its commitment to respect Arabic and Islamic values". The French Foreign Ministry and the French Ambassador in Riyadh are trying to calm what has become a diplomatic incident. Nick Brown, Strasbourg, France [Also noted by Paul Johnson <Paul@treetop.demon.co.uk> and and Pete Bentley <pete@sorted.org>. PGN]
While working as a civilian military pay supervisor in the Army finance and accounting office at Fort Myer from 1994 to 1997, Teasa Hutchins Jr. caused regular military paychecks to be deposited to a bank account in the name of a bogus officer, and accumulated $169,000 for himself. He has pleaded guilty and faces up to 10 years in prison and a $250,000 fine. [Source: An item in *The Washington Post*, during one of my trips there this summer — I forgot to record the date]
I work for a large U.S. corporation which has a 401(k) plan. For non-US readers, a 401(k) is a self-funded retirement plan: you (voluntarily) put aside part of your salary (pre-tax) and your employer (usually) matches it in part. The employee selects how to invest their portion of the money (and at some companies, how the company's matching funds are invested). As required by law, we receive quarterly reports on how much money we have in the 401(k) plan, mailed to our home addresses. This quarter, about 2/3 of employees received incorrect statements. It seems that there was an off-by-one error in matching employees to addresses. That is, if employee E1 has address A1, and employee E2 has address A2, etc., the report for E1 was sent to A2, the report for E2 was sent to A3, etc. The interesting thing was that the envelope delivered to A2 would have E1's name on the outside and E1's data on the inside. So those people who looked at the envelope before opening would realize that something was amiss. The hypothesis is that this occurred because an employee record had been incompletely deleted from the database (and no, I have no idea how that could happen). When our payroll department uploaded data to the 401(k) management company, the data was incorrectly interpreted by the receiving program. Nothing in the management company's computer system noticed that 2/3 of the addresses were mismatches with the addresses already on file. Interestingly, the last address on the list received two reports: one for the employee who lived at that address, and one for the employee who lived at the next-to-last address. The reason this affected "only" 2/3 of the employees is that those employees whose records were uploaded before the "bad" database record was encountered were unaffected. Some employees are quite upset, since other (unauthorized) people saw the balance in their 401(k) accounts and the amount being contributed. From that data, one can infer salary information ... which many people don't want publicized! We can see several RISKS here: * It was possible to modify the database records such that an employee was "partially" deleted, thus leading to the situation. * The management company's computer system did not cross-check the addresses being used for reports against the addresses of record. * Most people don't look at the address on the mail before they open it!
America OnLine recently announced its intention to provide telemarketer clients with the phone numbers of all AOL customers who have not explicitly requested that their phone numbers be excluded. It was reported less widely that AOL intended to provide some sort of user transactional information as well. The AOL customer contract fine print claims that they will not release such personal information, but even finer print seems to reserve the right to do so to their business partners. (But opting out is apparently not easy.) Nevertheless, presumably due to customer complaints, AOL has backed down somewhat, and will now use that information only for its own [nefarious?] activities. Telemarketing and spamming are already out of control, and some of those activities are questionable, if not truly unethical, immoral, and in some cases illegal. But in any event, they are generally annoying and unwanted by most people. The argument that using the transaction information will permit hustlers to be selective about whom to harass seems specious and disingenuous, at best. Please stay alert.
My 5 year-old grandson opened up a box of Chex Quest and eagerly placed the "free" CD-ROM he found inside the box onto my Mac Performa, without any adult supervision. This is not unusual because he often plays educational CD-ROMs. The box makes it sound like you get the "free" game on the CD-ROM *plus* 50 free hours of AOL. The "install" item on the CD-ROM menu installs not the game but rather, AOL. The CD only contains a preview of how the game works on, guess what? --AOL. It took me 3 days to un-install AOL and to re-install my regular service with the help of support people at The Well. General Mills and AOL neatly "cover" themselves with the following: "By purchasing this product [the cereal], you agree that, with respect to the CD-ROM game described on this package, (1) any and all disputes, claims and causes of action shall be resolved individually, without resort to any form of class action...(2) any and all claims, judgments and awards shall be limited to actual out-of-pocket costs incurred, and in no event shall attorneys' fees be recoverable...(4) you agree that your remedy for any claim, if any, shall be limited to either replacement of the CD-ROM game or refund of the purchase price of the product, such choice to be at the sole discretion of General Mills" Just what I wanted — another copy of the same CD-ROM :-( The risk? It looks as if they knew very well what *their* risks were! How many other "free" CD-ROMs will be included with other types of products? Bruce N. Baker
The old risk of relying on text search instead of carefully reviewing a
document apparently bit the Texas legislature last session, according to an
article ("Inadvertent repeal of law puts city, developers in limbo," p.1) in
the July 24 Austin American-Statesman. The article focuses on the local
regulatory-political implications and isn't completely clear about how the
mistake actually happened, but apparently SB 932, a 68-page bill intended to
abolish the Department of Commerce and create a new Economic Development
Department, contained a lone unwanted sentence abolishing "Subchapter I in
Chapter 481 of the Government Code." The effect of the repeal is to make
the law governing land development uncertain. The paper speculated that "a
liberal mole hacked into the legislative network" although the bill's author
believes he and his staff accidentally repealed the development law.
A government relations spokesman for the builders' association was quoted as
saying that lobbyists check bills by searching for key words, and "In this
case, you'd have to do a word search for 'I.'"
The risk? A case of relying:
- on text search instead of document review
- on lobbyists to tell the legislators what laws they're making (!)
- on "the computer" as scapegoat
-- Derek Beatty beatty@{netcom,ibmoto}.com Austin, TX
Using either Netscape 4 or Microsoft Internet Explorer 4 type "msnbc" in the address box and hit return, the URL completion will first look for msnbc in the local domain then try the common domains net, com, edu etc. Unfortunately msnbc.net exists and looks nothing like msnbc.com ... in this case the difference is not harmful. However it opens the interesting possibility of .net domain mirrors of say schwab.com or some other financial site with the associated security implications.
*The New York Times* Cybertimes story "Minor Error Throws Internet Into Disarray", on 18 July 1997, by the usually savvy John Markoff, contains one howler: > Computer experts said the global glitch demonstrated that even a > single point of vulnerability in the Internet's addressing system > could hamper the workings of the far-flung computer network. RISKS cognoscenti understand the term "single point of failure" to refer to the critical dependency of an entire system on one component, certainly a cause of last week's fiasco. The opposite notion is of a system that can survive failures in any specific piece. But the text gives a quite different impression with that "even", suggesting that the opposite notion would be a system with many points of "vulnerability". You "computer experts" out there: explain your buzzwords thoroughly, or RISK having your pronouncements turned inside out! Mark Durst San Leandro CA <mjdurst@aimnet.com> [Long-time RISKS readers will also recollect many cases in which MULTIPLE points of failures were involved. (For example, see Chapter 4 of my Computer-Related Risks.) Of course, most systems seem to have MANY SINGLE-point failure modes, and if those don't get you there are lots of MULTIPLE-point failure modes. PGN]
As a follow on to the other comments on the security of Web browsers, I noticed recently that several Microsoft products now use their Explorer browser as their online Help interface. However, to use this feature it is necessary to enable some, if not all, of the "riskier" capabilities such as ActiveX and Java support - otherwise the Help information is inaccessible. What chances of the user remembering to re-disable these features before venturing back out onto the big bad Internet ? Incidentally, I first hit this problem with a Sales CD issued by DEC - again, the only way to access the data on the CD was via Explorer with ActiveX and Java applet loading enabled. Roger Barnett
While searching the Microsoft web site for Win95 updates, I came across an interesting KB article. This deals with a problem with Win95's handling of Microsoft TCP/IP, according to the article when Win'95 receives an Out of Bound packet ". . . deliberately sent to the server" a Fatal Exception error will result(The blue screen of death). " An update available on the web site will fix the problem. The RISKS, if someone generates an out of bound packet, whether by accident or design " . . . the computer may not receive further network data until Windows is restarted." The full text of the article can be found at:http://www.microsoft.com/kb/articles/q168/7/47.htm A link to the patch is also on this page. vtcpupd.exe is the file name Alex Klaus <am676@freenet.carleton.ca>
> This then becomes a matter of determining an _efficient_ way to set the > value of the MD5 (or any) hash function to a desired value. Although collisions must exist in cryptographic hash functions, this (hopefully) isn't going to be easy. In general, finding even a single example of a collision is generally considered proof that the hash function is broken. Finding a feasible way to construct messages with a desired hash would be a much more dramatic result. Cryptanalysis of hash functions is an interesting and important area which hasn't been given nearly as much attention as it deserves (though there has been some excellent work in the area, such as what what Hans Dobbertin has done attacking MD5 and MD5 — see http://www.cryptography.com/papers/hash/dobbertin.txt, for example). The consequences of a major hash function break could be quite devastating -- virtually all certificates, digital signatures, and modern cryptographic protocols rely heavily on the collision resistance of MD5 and/or SHA... Paul Kocher, President, Cryptography Research, 870 Market St., Suite 1088 San Francisco, CA 94102 415-397-0111 (FAX: -0127) paul@cryptography.com
My cousin tried that on a Mac running 7.6. It was rather accurate, but tended to do a shutdown reboot when inspired by certain background noises [exactly what it is, we have no idea]. However, he took the machine home, to Hong Kong. Being rather tight on landspace, HK offices are very "friendly" and has a rather high ambient noise level when compared with US. As a result of that, that Mac tried to reboot every few minutes. Turned it off finally. So, I guess, risks would be trying to go overseas/unusual accents :P -Tai
> "It'll make people give up the mouse," says Lernout & Hauspie's
> chief technology officer.
Don't bet on it. The risks of spoken interfaces are the same as those
of mechanical ones. I recently saw a program on television (around two
months ago; unfortunately I have forgotten the program name) wherein a
company purchased voice interface systems to help stem the rise of
repetitive stress injuries (RSI) that their employees were
experiencing.
The catch? The workers soon began experiencing voice-related RSIs. It seems
that long periods of enunciating short, carefully articulated phrases ("cut
cell"... "down cell"... "over row"... "paste cell") had led to damage to the
employees' vocal cords and supporting anatomy.
I can't wait for the brain cramps that come with neural interfaces...
Christopher Kline <ckline@media.mit.edu>
[Various other comments also received. PGN]
Possibly, it was not a PC at all, but a mainframe or timesharing system terminal, and the nightly backup runs at midnight. In my experience, some several years ago, of one such system, the nightly backup ran at the highest priority. This meant that all terminals effectively "died" at 00:01, only to spontaneously come back to life again 5 to 10 minutes later — the first couple of times with a sudden rush of all of the queued keystrokes that I had entered over those 5 to 10 minutes in my puzzlement. (-: The risk if this is the case? Almost certainly of using the same system administration techniques that work well for a daytime-only system (scheduling the backup to run at night because that's when no-one will be using the system) on a 24-hour system. On the other hand, one could argue that a delay in one admissions data entry is less critical than a delay in the backup of the whole day's transactions, and so it is proper that the backup run at a high priority at the expense of those interactive users unlucky enough to be active at the time. Please remove the '$' in the from line before reply via e-mail. Anti-UCE filter in operation.
One of the most difficult tasks in dealing with the Y2K problem is finding the parts of the source code or libraries that are used that are not Y2K complaint. However, what if you look at the problem from a different angle. Assuming that most of the software systems can be simplified to say there is a user or batch system layer that communicates with a database layer, what if: 1. You transfer all "live" records in the database that involve dates between 1900-1909 to a new software system. There should be few enough of these types of records that the work should be reasonable. [A live record is one that is still used. All dead records would be removed from the database and stored with a big note.] 2. You set all of the dates of data in the database back 10 years 3. You introduce a new layer in the software model. Add a program that intercepts calls that normally go directly to the database that would increase the date of data that is leaving the database (on requests or queries) and decrease the date of data that is entering the database. This would allow the user interface layer to only require an aesthetic change (displaying 20xx instead of 19xx), allow for more time to develop a more complete, revised system (allowing for better amortization on the development of such software that is most likely already in progress), reduce the cost and difficulty leave of a Y2K "solution" and be easier to track problems with as it will retain the integrity of the database and user interface layers. This could be seen as being a perpetual solution as the number of people, particularly in insurance databases, however that would require two separate systems to be running, which would not be cost effective in the long run. Driss
> Should there be a standard (no that will never work :-) set of tests that > all chips must go through during start up? Perhaps, but at startup is not often enough unless your machine reboots frequently. Long, long ago, a Vax-11/780 at Rice University had its floating point accelerator (an entire board) go a little funny in the head without telling anyone. After that (after wondering how much of a week's worth of x-ray crystallography and reservoir simulations were junk) we decided to run user-mode floating point diagnostics late every night. Of course, I imagine most people are like me — I use a Pentium- based machine, and haven't a clue how to run floating point diagnostics, nor do the Norton Utilities advertise that they check the FP (come on, guys, it wouldn't take long compared to checking my disk), and if I use the past to predict the future, the chip vendor won't tell me if a problem is discovered. David Chase, chase@world.std.com
There were some serious errors in the article about the psychic spammers
(800-number asks caller to dial 809 number, rip-off). And, though this
instance might be simple misconception, there is a RISK of an oft-quoted
forum like RISKS carrying egregious errors without a correction.
>However, several foreign countries have been assigned "North American"
>area codes recently. Among them, area code 809 for the Caribbean.
These numbers are not a "recent assignment". In fact they are a holdover
from the _past_. Some Caribbean nations were given area-codes under the
North American Numbering Plan (NANP, 1947) many years before there was such
a thing as country codes or even Trans-Atlantic Telephone cable (TAT-1,
1956),
Exploiting these area-code-look-alikes for scams is a recent phenomenon,
though.
>Since these people are not bound by US law, they do not need to
>disclose the full cost of making the phone call.
Too many misconceptions here ..
First: These calls are very much bound by US law, being billed by a US long
distance company. But remember that US law is based on a "free market", so
a rip-off can still be "legal". (The RISKS of govt regulated tariffs are
left as an exercise to the reader.)
Second: They do have to disclose the rate (fair business, fraud etc.), but
you've got to ask! (e.g., the operator).
What can one do ? Be alert. There are innumerable ways one may be given the
number to call. From a 800-number call, Or an advt. Your beeper. You
return an urgent call. You fax them. Someone "borrowed" your phone. That
BBS number with "free" goodies. Almost anyhow! (Your dreams are probably
safe, though, despite the 'psychics').
Look at the first few digits of the number being called.
1. 1-809- ...
2. 011- ...
3. 10-XXX-... (May be written as 1-0XX-X ... !!)
If in doubt, ask your local friendly '0' operator for advice.
There is another similar scam that involves the victim getting a collect
call (possibly about something worrisome), but one that just "happens" to be
carried by a rip-off long distance company. Ask. REFUSE A COLLECT CALL
UNLESS you know (1) what telephone company it is, and (2) what the charges
would be.
>http://www.fraud.org/809alert.htm
>http://www.oag.state.tx.us/WEBSITE/NEWS/LEGALMAT/9701cpd.htm
>http://www.ece.orst.edu/~alper/Info/scam.html
These web sites suggested do make an excellent read. Here are a
few more authoritative sources of information.
Linkname: BELLCORE: National Solutions - North American Numbering Plan (NANP)
URL: http://www.bellcore.com/NANP/
Linkname: CONSUMER ALERT: International Dial-a-Porn
URL: http://www.fcc.gov/ib/td/dialporn.txt
Shrikumar, shri@cs.umass.edu
Re: The "809" problem, it might be worth noting that the so-called "809
problem" has expanded? My telephone book lists the following area codes:
242 Bahamas
246 Barbados
441 Bermuda
787 Puerto Rico
I believe an area code has been assigned to Monserrat as well, and I would
expect more to be assigned to this set of countries. (And this reminds me
of a recent scam where "011-24" was claimed to be the country code for
Canada. It turned out that there is no country code 24, but the phone
number started with 8, and 011-248 is the country code for Seychelles
Island.)
RISK? Naming a problem by a characteristic that turns out to be non-unique?
..hymie!
Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems. RISKS will continue to carry general discussions in which
risks to privacy are a concern.
* The PRIVACY Forum is run by Lauren Weinstein. It includes a digest (which
he moderates quite selectively), archive, and other features, such as
PRIVACY Forum Radio interviews. It is somewhat akin to RISKS; it spans
the full range of both technological and nontechnological privacy-related
issues (with an emphasis on the former). For information regarding the
PRIVACY Forum, please send the exact line:
information privacy
as the BODY of a message to "privacy-request@vortex.com"; you will receive
a response from an automated listserv system. To submit contributions,
send to "privacy@vortex.com".
PRIVACY Forum materials, including archive access/searching, additional
information, and all other facets, are available on the Web via:
http://www.vortex.com
* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Leonard P. Levine. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
comp-privacy@uwm.edu and administrative requests to
comp-privacy-request@uwm.edu.
There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places. If you are very
short of time and can scan only one, you might want to try the former. If
you are interested in ongoing discussions, try the latter. Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available. PGN
[For privacy devotees, there was an interesting panel at the Commonwealth
Club of California on Thursday night, 24 Jul 1997, entitled PRIVACY ON
THE INTERNET: Who Holds the Keys? Gina Smith of ACM News moderated, with
David Carlick (PowerAgent), Marc Rotenberg (EPIC), Phil Dunkelberger
(PGP), Christine Varney (FTC), and me. The audio might appear somewhen on
NPR, and CCC audio is rumored to be archived somewhere on cnet.com.]
Please report problems with the web pages to the maintainer