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…
One of the more troubling RISKS cases has been going on for the past four months in Emeryville, Ontario. Debbie and Dwayne Tamai have been stalked by someone with clandestine electronic access to their house who has been eavesdropping on their conversations, accessing their voicemail, changing their TV channels, and turning electricity on and off. The electronic intruder (``Sommy'') has interrupted phone calls, taunted the Tamais, flaunted police efforts, and eluded electronics and surveillance experts trying to determine how all this is happening. After each time that Bell Canada rewired the house, Sommy was quickly back in business — once within 20 minutes. Also, an attempt was made to put 600 volts on the phone line while Sommy was connected. Debbie said that Sommy just laughed, and said ``What are you trying to do, zap me? I've got a backup system, stupid.'' He also bragged to the Tamais that his house was one that been visited during a door-to-door police search of the neighborhood. That should narrow it down a little! [Source: An Associated Press item, seen in the *San Francisco Chronicle*, 15 Apr 1997, A8] There is speculation that perhaps not-so-good-neighbor Sommy did some creative wiring of his own while the Tamais' new house was being built, and that he is hacking in via a nearby BC wiring station and/or underground cables.
[The following was reported in _Netsurfer Digest_ (April 13, 1997 - V03 N12), a source normally known for passing on only reliable information. http://www.netsurf.com/nsd/index.html] FAKE "PGP CRACKED" MESSAGE LURES USERS INTO TRAP A particularly elegant bit of trickery is winding its way through a favorite newsgroup near you. It appears in the form of a provocative HTML message excitedly proclaiming that "PGP Has Been Cracked!" and gives you a link to click for more information. In reality, the link leads to the Telnet (25) or NNTP (119) ports of a certain ISP, where the really elegant part comes in. It appears that this provider regards your attempt to access these ports as an attempted hack. Furthermore, it is quite anal about complaining to your own ISP that you tried to break into their machines. A clueless netsurfer (that would be you) could lose his account if his own ISP is of the "kick off first, ask questions later" school of customer service. How this great mind hack plays on the paranoia of all involved is what so enthralls us. Read about it in the <news.admin.censorship> group. [There was also an apparent April Fools' item, ``RUMOR about large-number factoring in polynomial time'', citing a result attributed to Sergie Ripov. It was submitted by "Mike Giroux" <mike.giroux@thinkinc.com>, but does not break any new ground, even in April Fools' Spoofs. PGN]
(Courtesy of http://www.software.com passed to me by NCSA's IS/Recon analysts.) Microsoft Office 97's PIM is called Outlook 97. It can be used to send e-mail. The message software has the apparent ability to send Blind Copies, but when actually used, the addressees are visible to all recipients. MS promises a patch next month. (DMK: Is there an echo around here?) > "This offers potential for major embarrassment," said Steven Bang, > Webmaster at Software.com Inc., who found the bug this morning. > [Software.com can be reached at www.software.com] Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc. [The e-mail copies are not blind, but the software is visibly impaired. PGN]
I decided to perform a 'random act of kindness'. I went to a Hallmark card store to create a personalized greeting card for a friend to remember a romantic 'non-event' in our past. To create a personalized card, you choose a blank sample and enter the text you want on a PC screen, then take the blank to the counter to be finished on a laser printer. One of the questions asked during the customizing script is "your initials" to identify your card among others at the counter. I chose two random letters. (I wonder now whether it would have accepted numbers?) After the card was done, I chatted with the clerk for a while to be friendly, then asked how long the text of the personal message was kept on the computer. She said it used to be kept until they ran out of space and began recycling, but now it is only kept for 5 days because of "the false arrest". Huh ?? This is all unsubstantiated, but it is her story ... She explained that some (unspecified) time ago, a customer had made a threatening card, after which an assault had been committed. When the police investigated the evidence of the threat, there was some confusion of which customer had paid for the threat card. It seems that, like me, the threatening customer chose initials that did not belong to him. But the initials he chose happened to match the name of either the previous or next customer who paid for his/her? card with a credit card. That person was identified and 'arrested' as the assaulter. When the mistake was realized, the falsely accused threatened suit against the store ... and now the store wipes computer records (on average) before the police can get to them. Risk? Since the computer never makes a mistake, you did it unless you can prove otherwise (standard data entry *verification* problem). And no, the clerk never noticed that the initials I chose did not match the name on my credit card. Privacy? If you get _really_ personal in a customized card, the store staff can and probably does enjoy your message vicariously. She did mention that 'you ought to see how bad some of these people write!'. Sam Lepore, San Francisco [She must be a great-gramma(r). PGN]
(Courtesy of BugNet passed to me by NCSA's IS/Recon analysts.) BugNet Alert -- Credit Card Scam Hits Microsoft Network > MANY USERS of the Microsoft Network (MSN) report they have recently > received fraudulent e-mail from the "MSN Billing Department" which is > designed to steal their credit card numbers. The e-mail claims a virus wiped out MSN's billing records. Virus was allegedly introduced by an ex-employee. The e-mail states that, due to a virus unleashed by a "malicious ex-employee," all the billing records of MSN have been destroyed. It asks for the usual information, allegedly so that MSN can report it all to the FBI. > To try to give the request the air of legality, the message continues: > "*NOTE* If you reply with credit card information other then your own, > your account will be canceled, and we will submit all information on you > available to us to the Credit Card fraud department of the F.B.I." MSN has denied the story and is trying to identify those responsible. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
A discussion on another list (Pednet, on issues of concern to pedestrians; contact me for subscription info) recently turned to the subject of IVHS (Intelligent Vehicle Highway Systems) — intelligent road-vehicle combinations which control the flow of traffic with no or limited operator involvement. In that forum, one poster (whose words I am quoting without permission, so I'll accept and forward messages on his/her behalf) noted one conceivable advantage of such systems that no one had thought of: <>2. The even newer technology that would allow the car to "read" the road <>ahead to prevent it hitting anything could be used by pedestrians to get <>across the road. After a healthy wait fails to produce a break in the flow <>of vehicles, the pedestrian could simply start off, knowing that the cars <>would apply their own brakes and come to a safe stop in time. Reading this, I was intrigued by what seems to be a fascinating idea, and at the same time the RISKS alarm bell went off in my head. This seems to me to be just another version of the aircraft or railroad automation problem, only in reverse: rather than (A) the automation causing the operator of the vehicle to lose his or her alertness, thus contributing to more serious problems at the occasional times when the system fails (another problem which, incidentally, also applies in this case), the Pednet poster has identified a case in which (B) the automation causes _other parties_ (not the operator) to make assumptions about the behavior of the vehicle, which could conceivably turn out to be incorrect and hurt someone (in this case, the person doing the assuming). In fact, we make assumptions about the behavior of external objects all the time. We do it whenever we move to get out of the way of a falling object, taking for granted that the laws of physics will continue to apply until it hits the ground (and that it won't, say, suddenly speed up or turn the other way). We do it when we wade in the lapping waves at the seashore, taking for granted that the sea won't suddenly rise up 12 feet in the air and swallow us; we do it when we swim in the river, making an assumption that the current won't suddenly quadruple in force and drown us. And so on. We even do it in the road; I cross the street in the face of oncoming traffic, as long as it's sufficiently far away for me to know that if the operator doesn't apply his brakes in time, I have time to run fast and get out of the way. I trust the laws of physics and the limits of automobiles enough to know that even if an errant driver floors the accelerator, his/her potential acceleration is limited (he/she won't do zero-to-60 in 0.25 seconds, for example) and I can still get out of the way. But once software systems take over, some (not all) of these bets are off. The Pednet poster is postulating a world in which people have become so trusting of safety systems, and so trusting, that they're willing to step off the curb into oncoming traffic, too fast or too close to get out of the way of, _and assume the traffic will stop_ — in which they come to depend on the system to save them from themselves. They're no longer saying "the laws of physics protect me, because I can safely assume that a body in motion will continue on the same path"; they're saying "the laws of physics are irrelevant, because I assume that an outside entity will intervene and _stop_ that body in motion before it hits me." (I'm not "accusing" the Pednet poster of that type of "trusting," merely of bringing up the subject. :-) I see that type of "trusting" as qualitatively different from the sort I go through every day: for instance, getting in an elevator, even though I don't know how an elevator works, and assuming that the cables won't snap and drop me to my death. In the case of the elevator, the laws of physics act to calm me (I know that cables have a certain tensile strength, and gravity exerts a certain pull, and anecdotally understand [or think I do, anyway -- yikes! Tonight I'm taking the stairs] the sorts of fail-safe systems built in, in which gravity acts as a last resort to stop a falling car by exerting some sort of pressure on some sort of widget and causing the car to brake against the side of the shaft; and assume the inventors of the elevator took all these things into account in proper proportion). Perhaps it's only a matter of time before dashing in front of an oncoming car and expecting it to stop becomes as much "second nature" as stepping into an elevator. (Once upon a time, stepping into an elevator was unthinkable.) Rich Mintz - mintz@netresponse.com - Arlington, Virginia USA
Michael O'Donnell's posting to RISKS-19.07 about the management of his car garage believes its computer rather than its customers was revealing. "She did let us all leave eventually, but never seemed truly convinced that we had not gotten away with some cunning trickery," O'Donnell writes. I'd like to suggest to O'Donnell --- and to all other readers of RISKS --- that when things like this happen, the appropriate response would be to call the local newspaper. These sort of stories make great copy for the local press. Rather than giving lectures about computer RISKS to low-level managers, who frankly don't care, give them to reporters, who will be happy to share them with their readers. The only way to solve these problems is by public education. This is a great way to do it. http://www.packet.com/garfinkel
RISKS-19.07 contained two "computer is always right" stories that at first glance seemed to reflect the same old problem: people trusting a computer when a more obvious answer is at hand. Closer examination of the two articles reveals a fundamental difference between the two that RISKS readers and the general public should learn to recognize. Michael O'Donnell's problem with a parking lot computer encounter is the typical "computer is always right" story. An unusual computer alert (the suggestion of park-card "passing") is paired with a system crash. An innocent person is accused and the stubborn computer user fails to consider that the computer might be wrong, or see the connection between the crash and the alert. The key here is an =unusual= alert, which should cause any computer-wise person to immediately question the computer before they cast accusations about. This contrasts sharply with Joe Carlet's child's library fine story. In this instance the librarian was faced with a very common computer alert (an overdue book) Here, it would be very counter-productive to question the computer every time (indeed, if that were the case, then one should get rid of the computer). Mr. Carlet was in an unusual situation in that he could prove his child's innocence, and is to be commended for hanging in there against a stupidly designed system. The librarian however is not due scorn for being at least initially unreceptive to his pleas of innocence. How often do you think he or she has heard this before, only to discover that the computer was right? Almost any computer system user can tell you of vehement pleas of innocence to be followed later with sheepish admission of guilt. The key element here is recognition of what is unusual: the flag or the falseness of the flag. When the flag is unusual, it is incumbent on the system operator to check things out. When it is the falseness of the flag that is unusual, it is the responsibility of the accused to check things out carefully (in my experience as an indignant accused, I usually turned out to be wrong) and to be patient with system operators that may have several levels of denial to go through before they take seriously the possibility of error. This is both human nature and efficient time management. It is why we have FAQ phone trees (despite the fact that your problem is "unique"). The RISK here is that without this distinction, computers, like an untrustworthy person, will not be worth using at all. Bob Morrell bmorrell@bgsm.edu http://pandoras-box.bgsm.edu/micro/tech.html
While this and other forums have been focusing on the technical details of the year 2000 problem. I think that it would be good to take a step back and assess exactly what the problem will look like, say in the year 2005. That is, what kind of historical event is this really going to be? RISKS, which has as its audience people who deal with computer problems and their resulting headaches seems an ideal place to have an extended thread on this issue, identifying scenarios and casting informed votes on their likelyhood. Here is my list of scenarios and my vote NON-EVENT: In this scenario, all the fretting and reprogramming pays off, or alternatively, computers turn out to be less important than we thought. Problems are solved with a little foresight, or with common sense after the fact. IS workers pull a little overtime the first week watching for trouble, but nothing unmanageable turns occurs. It is even conceivable that a positive boost could occur as businesses and governments get a more detailed understanding of the limitations of their computer systems and replace long neglected programs with software that adds utility to their systems. SPEED BUMP: This is the scenario that most news organizations seem to be expecting. Problems occur, but because everyone is expecting it, we slow down and go over the bump without real damage. Snafus appear, and businesses apologize for the error. The event becomes the national equivalent of April 15th (tax filing day), with many headaches, much griping, but in the end, the work is done, and we return to normal speed quickly. SLOW DRAG: Just as problems with the year 2000 appeared years before, in this scenario, problems will appear over time after 2000. As daily, weekly, monthly, quarterly, yearly programs encounter the problem, there is a constant but only slowly realized drag on all activities. In this scenario, everything done for the first time after 2000 will be problematic, and delays, errors and decreased productivity will diffuse through the economy, not always attributable to the year 2000 problem. The drag could be as significant as an increase in tax rates or energy prices. The year 2K could result in a recession, but the connection might not be obvious. BLIZZARD: In this scenario we come into work on Monday after the revelries to find 4 feet of computer snow on our desks. Computer and physical systems associated with them crash, there are traffic snarls, power outages and other significant problems. "Revert to manual methods" becomes the byword. The most significant aspect of this scenario is that all the problems (like the snow) is on the ground, and we all know what it is we have to work through. Power is restored, backup files found and used, and everyone shakes their heads in amazement at how reliant on computers we have become. HURRICANE: In this disaster scenario physical and technical problems abound, and new ones are continually being found. The problems threaten physical harm to the public. Before events can cascade governments intervene. Bank holidays are declared, food shipments and other essential activities are taken over government mobilized noncomputerized troops or bureaucrats. All normal commerce ceases till hastily constructed emergency systems can provide society with basic needs. Emergency councils are convened, and while it is a physical disaster like a hurricane or flood, everyone understands what is needed to reconstruct and begin anew. APOCOLYPSE NOW: This scenario has all the disaster components mentioned previously, but has added to it a substantial public panic. Problems cascade beyond informational, beyond physical, to the psychological and sociological. Stock markets collapse, rioting in the streets occurs, governments fall, and societal constraints break down. My vote is for the "slow drag" scenario.
I work with IBM RS6000 systems which run AIX, the IBM Flavour of UNIX. In spite of the fact that it is possible to set the time-zone to: (GMT0BST) United Kingdom (CUT) The dates the time changes from GMT to BST and vice-versa are wrong. The US programmers always assume that our dates for time change are the same as yours, so rather than an automated hassle-free changeover, we have to correct the time 4 times a year to ensure the time-stamps in applications run correctly. The RISK is one of not bothering to research the facts all the way through. In spite of IBM having been formally notifying twice a year for the last 2 years, they have done nothing about it. What was that old adage about a stopped clock being right twice a day ? David Alexander, Caplin Cybernetics Corporation, Windmill Business Village Brooklands Close, Sunbury-on-Thames, Middlesex TW16 7DY, England 01932 778172
GMT certainly does not mean 'the current civil time in the UK', for which there is, as you correctly note, no term. I think that persuading people that it would be a neat idea to have a different name to call the time we use in winter which is actually, but not conceptually, GMT, could be a bit of an up-hill struggle. John Styles john@gurk.demon.co.uk [BST = British Summer Time]
It should be pointed out that the United States Naval Observatory <http://tycho.usno.navy.mil/> distinguishes between UTC and GMT (which is currently one hour ahead of UTC). It would seem, then, that Windows 95 is correctly advancing GMT when the user selects "adjust for daylight savings changes." That said, I've been trying to figure out the "right" solution to a Java timezone problem. According to the published documentation for the Java Date function, the getTimezoneOffset method returns "the number of minutes that must be added to GMT to give the local timezone." If I'm not completely confused, this means that Pacific Standard Time should have a timezone offset of -480 (-8 hours). However, every browser I've tried returns +480. Documentation bug? Programming bug? What is the right solution? Martin Minow minow@apple.com
> And don't forget that the differences between UK local time and North > American east-coast local time change FOUR times a year because the > changes happen on different weekends. PGN] No, the summer->winter change now happens on the same week-end in both the European Union (including the UK) and North America. The winter->summer change is still off by a week. I suspect that the EU, having moved the end of summer time from the end of September to the end of October to match US practice, now expects the US to do a reciprocal gesture and move from the first week of April to the last week of March. Anyway, the difference changes only twice a year now: on the last Sunday in March at 0100 GMT, and on the first Sunday in April (at 0700 GMT, I believe. GMT==UTC at all times, as even casual listening to BBC World Service will confirm.) Unless you take into account the fact that the summer->winter changes occur a few hours apart (in which case you are right about the "FOUR times" but not about the "different weekends" explanation for it). [Yes, indeed. Incidentally, I do not recall a RISKS case of screwups resulting from the hour differences in the 24-hour period of cutover. PGN]
I like Volvos for longevity and safety. (After getting broadsided in the passenger side front door and fender by an 18-wheeler Mack truck, I drove my '78 wagon 200 miles home. So I have great affection for these rolling boxes.) However, I don't believe in car payments, especially when a new one would set me back a larger amount than my mortgage balance. So our youngest car is an '88 with >150K miles. When the little "SRS" light suddenly lit up on the dash, I looked it up in the owner's guide. Turns out it's about the driver's airbag. "See your Volvo dealer" it says. So I did. I figured it'd be a switch, or a loose wire somewhere, as happens with old cars. Wrong. It's "the chip", don'tcha know? The one that senses a crash and inflates the crash balloon. The diagnostic shows it has an error code. Doesn't matter which code, it needs a new one. The price? Nine Hundred Dollars. (Plus labor.) It's gold plated, don'tcha know? After I verified in triplicate that it will not fail by inflating the thing when there is *no* crash, I decided not to replace it. I always wear the seatbelt and shoulder harness, and because I'm just under 5'3" the airbag is probably a danger to me anyhow. The Risk — what price safety, indeed? Sara Thigpen
>In fact, one of these amendments was passed, [...] This has been negated by the section of this bill that was dropped, effectively deleting the amendment from the bill. One of the interesting aspects to this is that for votes, the Legislature normally gets locked, nobody in or out, and the MPPs stand to indicate their vote yay or nay. The speculation was that it would be come an endurance contest to see how many MPPs could deal with standing up and sitting down 12,000 times during the voting period. The rules about nobody in, nobody out were also relaxed to allow breaks every 4 hours for food, visits of necessity, and the like. The risks here are somewhat clear: 1) When a governmental system run by 19th century practices runs into an automated opposition, it's the people who'll suffer - in particular the government employees who work behind the scenes. 2) Future MPPs may need to spend more time in the gym so they can handle these marathon voting sessions. 3) This tactic will almost certainly be addressed by the government to keep it from happening again - possibly with damaging effects for the democratic process when issues might be raised in a similar manner but for non-stalling purposes. >Presumably, the next time this sort of thing happens, the computers will be >programmed to produce a more varied set of amendments, to defeat the "only >read the changing part" technique used this time. Or the rules of the house would be changed to allow for an automated governmental vote on automatically generated amendments, thus reducing the sitting of the house to two Soundblaster-equipped PC's - one to read the amendment, the other to say "No", while the rest of the MPPs do whatever they do. Tim Kuehn TDK Consulting Kitchener, Ontario
Please report problems with the web pages to the maintainer