[Thanks to Chris Hoofnagle for compiling.] Protect Your Privacy in The New Year: Privacy Tips from the Electronic Privacy Information Center (EPIC) Top Ten Consumer Privacy Resolutions 1. Engage in "privacy self defense." Don't share any personal information with businesses unless it is absolutely necessary (for delivery of an item, etc.). Don't give your phone number, address, or name to retail stores. If you do, they can sell that information or use it for telemarketing and junk mail. If they ask for your information, say "it's none of your business," or give "John Doe, 555-1212, 123 Main St." Don't return product warranty cards. Don't complete consumer surveys even if they appear to be anonymous. Profilers can build in barely-perceptible codes that link you to the survey, and this data goes straight to direct marketers. 2. Pay with cash where possible. Electronic transactions leave a detailed dossier of your activities that can be accessed by the government or sold to telemarketers. Paying with cash is one of the best ways to protect privacy and stay out of debt. 3. Install anti-spyware, anti-virus, and firewall software on your computer. If your computer is connected to the Internet, it is a target of malicious viruses and spyware. There are free spyware-scanning utilities available online, and anti-virus software is probably a necessary investment if you own a Windows-based PC. Firewalls keep unwanted people out of your computer and detect when malicious software on your own machine tries to communicate with others. 4. Use a temporary rather than a permanent change of address. If you move in 2005, be sure to forward your mail by using a temporary change of address order rather than a permanent one. The junk mailers have access to the permanent change of address database; they use it to update their lists. By using the temporary change of address, you'll avoid unwanted junk mail. 5. Opt out of prescreened offers of credit. By calling 1-888-567-8688, you can stop receiving those annoying letters for credit and insurance offers. This is an important step for protecting your privacy, because those offers can be intercepted by identity thieves. 6. Choose Supermarkets that Don't Use Loyalty Cards. Be loyal to supermarkets that offer discounts without requiring enrollment in a loyalty club. If you have to use a supermarket shopping card, be sure to exchange it with your friends or with strangers. 7. Opt out of financial, insurance, and brokerage information sharing. Be sure to call all of your banks, insurance companies, and brokerage companies and ask to opt out of having your financial information shared. This will cut down on the telemarketing and junk mail that you receive. 8. Request a free copy of your credit report by visiting http://www.annualcreditreport.com. All Americans are now entitled to a free credit report from each of the three nationwide credit reporting agencies, Experian, Equifax, and Trans Union. You can engage in a free form of credit monitoring by requesting one of your three reports every four months. By staggering your request, you can check for errors regularly and identify potential problems in your credit report before you lose out on a loan or home purchase. Currently, these reports are available to residents of most western states. By September 2005, all Americans will have free access to their credit report. 9. Enroll all of your phone numbers in the Federal Trade Commission's Do-Not-Call Registry. The Do-Not-Call Registry (http://www.donotcall.gov or 1-888-382-1222) offers a quick and effective shield against unwanted telemarketing. Be sure to enroll the numbers for your wireless phones, too. 10. File a complaint. If you believe a company has violated your privacy, contact the Federal Trade Commission, your state Attorney General, and the Better Business Bureau. Successful investigations improve privacy protections for all consumers. Available online at http://www.epic.org/privacy/2004tips.html For more information about privacy, visit the Electronic Privacy Information Center at http://www.epic.org/
[There are huge lessons for disaster recovery in the aftermath of the Sumatra earthquake/tsunami. PGN] [Following item by Dan Vergano, *USA TODAY*, PGN-ed] Suppose you know a disaster is imminent, but don't know whom to tell? Or how to tell them? Is e-mail the answer? Suppose those to be effected have no plans to deal with impending disaster? Minutes after a massive earthquake rocked the Indian Ocean on Sunday, international ocean monitors knew that a tsunami would likely follow. But they didn't know whom to tell. "We put out a bulletin within 20 minutes, technically as fast as we could do it," says Jeff LaDouce of the National Oceanic and Atmospheric Administration. LaDouce says e-mails were dispatched to Indonesian officials, but he doesn't know what happened to the information. The problem is that Sunday's earthquake struck the unmonitored Indian Ocean. An international system of buoys and monitoring stations - the Pacific Tsunami Warning Center based in Hawaii - spans the Pacific, alerting nations there to any oncoming disasters. But no such system guards the Indian Ocean. [where there are many earthquakes, although detector buoys used elsewhere are not deployed there; also risks of false alarms, as the evacuation in Hawaii in 1986, which reportedly cost more than $30 million...; also the critical needs for evacuation plans and training] [Source: Scientists in USA saw tsunami coming, by Dan Vergano, *USA TODAY*] http://www.usatoday.com/news/world/2004-12-28-tsunami_warning_usat_x.htm
Alek Komarnitsky, a computer specialist, two years ago created a Web site that supposedly allowed browsing users to turn his outdoor Christmas lights on and off, blinking on command. However, it turns out it was a hoax, intended "to spread holiday cheer", as he recently confessed to *The Wall Street Journal*. At first, he used a series of still photographs with lights on or off, and varying amounts of snow. This year, his wife manually controlled the lights while a TV helicopter even hovered overhead. [Source: `Web-controlled' Christmas lights just a holiday hoax, *Chicago Tribune*, 28 Dec 2004; PGN-ed]
I'd like to add one more case to the series of computer glitches causing failures in reporting patients' laboratory results to the proper people (see RISKS-23.63 and 23.19, at least). A hospital recently changed its method for testing for a sexually transmitted disease (GC); the new instrument reported its results into the hospital information system in a free text field, where it could be viewed by clinicians looking up an individual patient's result. The system for ensuring no results were missed was based on a custom report written locally (because the vendor's report packaged with the system was too difficult to manage). This report covered all bacteriology cultures, not just those for the GC, and looked at a binary field for a positive or negative value for GC, reporting only the positives. Under the new system, that field was empty, and so no cases positive for GC were listed by the report. Because the other cultures were still being reported normally, the report superficially looked normal (ie, it was not entirely empty). The person who normally reviewed the report to follow up on all positive, untreated cases was away on vacation during this change. Some time after returning, she began to think it odd that no positive GC cases were showing up, and discovered the foregoing. A corrected report showed that several hundred cases positive for GC had been missed and had also not been treated with antibiotics; a non-negligible proportion were in children (where a positive result might be an indication of abuse). There are organizational level, management level, and programming level risks here. At the organizational level there is the risk of increasing dependency on computer systems in an industry whose experience with these systems is immature (compared to other settings) and whose investment in informational infrastructure is low. At the management level, one failure is not tracking dependencies among system modifications. And at the programming level, the classic mistake of assuming a missing value means negative, instead of unknown. (I'm reminding of the aphorism that database programming would be much easier if missing values did not exist). The case also indicates the value of experienced workers, who know what the normal pattern of laboratory abnormalities looks like and have some insight into the potential seriousness of anomalies. Although it did take them some time to become aware that something was persistently odd, I'm not sure how or when it would have been detected otherwise. Bob Wears, Robert L Wears, MD, MS, University of Florida email@example.com and Imperial College London +44-(0)791-015-2219 firstname.lastname@example.org
/Pun intended on the subject line!/ Okay, so, we have all known cell phones are "dangerous". Stepping out of the cellular protocols security and vendor-side systems, and forgetting for a second about interception of transmissions through the air, Trojan horses/worms that may install themselves on the cell phone and even bluetooth risks, there is the long talked of risk of "operating" a regular un-tampered cell phone from a far and the risk of modified devices. Sorry for stating the obvious, but cell phones are transmitters. For years now paranoid people and organizations claim that eavesdropping through a cell phone is a very valid risk. Much like somebody pressing "send" by mistake during a sensitive meeting is a very valid yet different risk. Some of the stricter organizations ask you to do anything from (top to bottom) storing the cell phone in a safe, through shutting it off or removing the battery, and all the way to *only* "don't have that around here while we are in a meeting". Then again.. *most* haven't even heard of this risk. Forgetting even this risk, many of us even ignore the obvious. I usually ask people who talk to me while I'm on the phone "even if the NSA (for example) is not interested in what I have to say or not capable of intercepting it and even that I don't care if they heard my conversations... Should the person I talk to hear our conversation?" Lately there seems to be some more awareness about the "dangers" of cell phones. Knowing which risk is more of a threat than the other is another issue. It seems to me that other than in the protocols, where there has been a serious learning curve (and GPRS seems very promising), cellular companies keep doing the same mistakes, and we can see the security problems of the PC world reappearing in cell phones, much like those of the main frames re-appeared in PC's (to a level). History repeated. Heck, I can't even disable Java or the web browser in most cellular computers (we really should refer to them as computers now). Here are some URL's on the subject: Here is one about modified cell phones, which also mentions the risk of eavesdropping through a cell phone as mentioned above: http://www.interesting-people.org/archives/interesting-people/200206/msg00031.html Here is a product for sale, a cellular phone BUILT for eavesdropping: http://wirelessimports.com/ProductDetail.asp?ProductID=347 Also, check out the IEEE Pervasive article that mentions this problem area, although discusses more the issue of malware: http://csdl.computer.org/comp/mags/pc/2004/04/b4011abs.htm Or Google for "symbian +virus", for example. Thanks go to David Dagon for the links.
T-Mobile Cripples the Blackberry Jason D. O'Grady, powerpage.org, 23 Dec 2004 In his article "T-Mobile Tells BlackBerry Users: GetLess!" PowerPage editor Emory Lundberg reports about how T-Mobile effectively crippled the Blackberry smartphone on its network by disallowing outbound requests on TCP port 80. A real sin considering that T-Mo Blackberry users pay US$40 per month for "BlackBerry Unlimited w/Enterprise E-mail" that includes "Unlimited Web Browsing." ... http://www.powerpage.org/cgi-bin/WebObjects/powerpage.woa/wa/story?newsID=13375
Date: Mon, 27 Dec 2004 02:53:06 +0000 (UTC) >From: Dan Foster <use...@evilphb.org> Newsgroups: comp.os.vms Subject: Re: OT: anybody know the details on the COMAIR debacle? Message-ID: <email@example.com> In article <41CF6AC4.8030...@prodigy.net>, CJT <abujl...@prodigy.netwrote: >JF Mezei wrote: >>So I wouldn't blame this on a computer breakdown. Just a scale of a >>problem that had not been planned for. > >They said the computer crashed. That's different from saying the >software couldn't find a feasible solution in an acceptable time. Yeah, well. I wouldn't necessarily take a news report as gospel for a technical event when lacking details and not reported through a technical source. This is unverified, and could be a wild rumor, but sounds credible (especially since it has better details and someone else with firsthand knowledge of Comair IT operations whom vouched for the report), and was seen on a Slashdot thread: Re:Fire away! (Score:5, Informative) by [Xorian] (112258) on Sunday December 26, @12:56PM (#11185556) Someone from Comair (who shall remain anonymous) provided me with some details which people here would be interested in: The computer system in question runs AIX. The box itself is still up and running just fine; this is purely an application error. This application was not written in-house at Comair, but by another large aerospace company -- SBS (http://www.sbsint.com/ [sbsint.com], owned by Boeing.) This bit of software does not use an external database, it tracks everything itself. It is a dedicated system responsible only for flight crew assignments. (The blather in the original submission about passenger reservations is way off-base. Those functions are handled by a completely different system.) The great majority of Comair's traffic flows through the midwest, and the central base of operations is in Cincinnati. The midwest was hit by a major snowstorm this week, causing many, many crew reassignments. It appears right now that the application in question has a hard limit of 32,000 changes per month (ouch). Consider that Comair runs 1,100 flights a day and there are usually 3 crew members on each aircraft. A big storm like this can cause problems for days after the snow stops falling. That's a whole lot of crew changes. In Comair's defense, this has never happened before and is unlikely to happen again. The crew system was already on the chopping block long before this incident, with its replacement scheduled to go live in January. If this freak storm had happened a month later, this likely never would have occurred. [The 2**15 exhaustion has been confirmed. For example, see: http://www.cincypost.com/2004/12/28/comp12-28-2004.html PGN]
And how much longer will it take before broken libraries finally stop having getYear() return such unintuitive results? It is not a precision problem. The only "zero" year should be 0 BC/AD, and nothing else. [Quite correct, even though there WAS NO ZERO YEAR. Whoever decided on the BC to AD shift was certainly not a mathematician. PGN]
Re: Satellite TV Broadcast Pirated There was a similar occurrence in the USA about 10 or 15 years ago. Someone seized the uplink of a C-band satellite service (Playboy channel, IIRC) and inserted their own programming. Technical details of the attack were quite similar to those described in the item in RD. Upshot, the miscreants were convicted in US Federal District Court for some violation of the Communications Act. Re: Automated medication worse than the disease. I can't tell from the quote if the problem is (1) "automated medication is worse than perfect" or (2) "automated medication is worse than non-automated medication." The headline would indicate (2) but the text only supports (1). Could it be that the real problem with automated medication that it permits easy collection of data on medication errors?
> These issues happen despite training. They often are present in the best, > most well motivated, most effective people in the organization. These issues also happen BECAUSE of training and competitiveness. Here's an example. Over the holiday, I caught up on my TV arrears by watching a program I had taped from the History Channel. This program involved a group whose objective was finding and diving on the wreck of the Queen Mary (or Indefatigable or Invincible...I don't remember which one). The wreck is that of a battlecruiser, hit by a German shell during the Battle of Jutland, May 31, 1916. The battlecruiser exploded and sank, with the death of all hands but a very lucky few. It was known that the German shell had struck through to some magazine area, but the size and nature of the explosion indicated that something more had happened. The blast was too large to be explained by the magazine alone exploding, or one of the turret ready rooms. They were designed to contain any blast resulting from a shell incursion. An alternate theory was that the blast-proof fire traps between the magazine and gun turrets had failed. The dive revealed that there were blast effects in both the turret ready rooms, underneath the forward turrets, and in the main magazine for the forward guns. In addition, there were unexploded cordite bags all along the corridor between the magazine and the turret ready rooms. And the blast doors were not closed... In order to keep the guns firing "efficiently", the gunners (obviously with officer knowledge and implicit consent) were storing cordite in the corridor right up to the ready room blast trap, which they were not using anyway..... Serving the six forward turret guns with three 50 pound plus bags of cordite per gun per shot, and attempting to fire at the same rate as could be attained when using the ready room stores alone... meant not just ignoring, but subverting the very safety measures which were intended to make the ship safe. As best the divers could tell, the German shell exploded in one of the ready rooms. The blast should have been contained there, but... The physical design did not allow for a quick enough replenishment and serving of the guns, when the 'safe' method was used. So it was not. The sailors knew that the captain depended upon them to serve the guns and keep them firing as quickly as possible. Inter-ship competition at gunnery meant that every possible advantage had been discussed and explored. And wouldn't a captain be peeved if his crew could fire a broadside once every say 2 minutes during training, but only every 3 minutes in battle.... There's a picture of the Queen Mary explosion at www.gwpda.org in the naval photos page. R. Geoffrey Newbury, Barrister and Solicitor, Mississauga,Ontario, Canada 1-905-271-9600 firstname.lastname@example.org
Interesting. I have another idea to try. I would suspect that the software is implemented as "test for existence of an RFID tag in the control area" not "test for the existance of an RFID tag that is programmed as an active baby" So happens when you take an RFID that is not attached to a baby and bring it near the door? How about an RFIDed package that is being delivered? Given the nature of RFID, this would happen sooner rather than later. Also that I know of there has been no real attempt in RFID to prevent denial of service as far as reading the tags. I wonder if a fairly low powered device of the right frequency could override the primary IF amp in the RFID receiver and allow one to prevent the tag from being read, therefore prevent the system from locking the doors. So I wonder if this is such a great security device. Ray Todd Stevens Specialists in Network and Security email@example.com Suite 21, 3754 Old State Rd 37, N Bedford, IN 47421 (812) 279-9394
Please report problems with the web pages to the maintainer