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…
Happy New Year! Germans now have the answer as to why they came up short at the ATMs after the New Year. Tagesschau reports online that people who were using newer cash machine cards that had new-fangled golden chips in them were told at the machine that their cards had an error because of a "software error". Not only ATM machines were affected, supermarkets and such that check cards online refused to accept the cards. http://www.tagesschau.de/wirtschaft/eckarte102.html Since I have spent the first 4 days of the year writing "20010", anyone want to speculate that this is the error? No details on the exact nature of the error as yet. It is scheduled to be fixed tonight (Jan. 4!). Not all of the machines refused to work, only the newer ones with the "EMV-Standard" (http://en.wikipedia.org/wiki/EMV) which are to keep the cards from being duplicated illegally and "secure" the data. Older cards, which store information on a magnetic strip, were not affected. I'm glad I still have an old card and an ancient machine around the corner. I got money after New Year's. More: Wed, 06 Jan 2010 17:36:57 +0100 It is getting curiouser and curiouser! The Tagesschau reports in http://www.tagesschau.de/wirtschaft/eckarte108.html and http://www.tagesschau.de/wirtschaft/kreditkarten144.html, which I translate and summarize here: It turns out that even more cards are affected, and even more people are unable to use either their EC cards or their credit cards to obtain cash or to pay in stores. The culprit has been named: The company that produces the cards, Gemalto. Seems that the software thinks that it is the year 2016 and not 2010, so all of the cards are no longer valid. A friend pointed out to me that 2016 is 11111100000 in binary. [*] The problem is a program stored on the chip. The banks don't want to have to exchange all of the cards (a really expensive solution), so they are looking for a workaround. One was promised for Monday evening, but it has not yet materialized. ATMs are generally now accepting the cards again [meaning they probably don't do any checking now...], but the Point of Sale terminals refuse to cooperate. 30 million cards are affected, and changing them would entail the owners all having to learn a new code for their cards. Only German cards are affected. Many hundred thousand cards were just exchanged in November because of problems with the data of cards used in Spain having been available after a security breach. The company Gemalto was formed 2006 in the fusion of the French company Gemplus International and the Dutch Axalto Group. The company has 10.000 employees and produces bank cards, telephone SIM cards and electronic passports. The company reports a volume of 1,68 billion euros in 2008. Consumer organizations and the consumer minister are blasting the banks for informing the consumers only a little bit at a time. * On a side note, customers of smartphones using Windows Mobile operating system have been noticing that incoming SMS messages also have the date 2016. Still More: Thu, 07 Jan 2010 08:58:34 +0100 Just a bit of scotch tape, sir! The great Y2K+10 problem in Germany continues: The chips were put on the cards to make them more difficult to duplicate. But it turns out, they at least have a fail-safe mode. If the chip is found to be malfunctioning or not there, the card readers resort to reading the magnetic stripe. Spiegel and others report that all it takes is a little Scotch tape over the contacts of the card, and the readers will switch to fail-safe mode. Retailers now dispense tape at the cash registers. http://www.spiegel.de/wirtschaft/soziales/0,1518,670433,00.html It is great that they have this mode, but it kind of makes you wonder how safe these expensive chips really make you, if they can so easily be defeated. Prof. Dr. Debora Weber-Wulff, HTW Berlin, Treskowallee 8, 10313 Berlin Tel: +49-30-5019-2320 http://www.f4.htw-berlin.de/people/weberwu/
Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bug-Hits-Endpoint-Protection-Manager-472518/?kc=EWKNLSTE01072010STR1 Updates after 31 Dec 2009 11:59 p.m are being labeled as "out-of-date."
Retail businesses across the country have lost thousands of dollars over the long weekend because a computer glitch left shoppers unable to use the Bank of Queensland's Eftpos terminals. BOQ's Eftpos machines skipped ahead six years when the clock ticked over to January 1 and started date stamping January 2016. BOQ staff have not been able find what caused the problem, but a temporary solution has been put in place to ease retailers' frustrations. The glitch cost businesses untold amounts as the Eftpos terminals read customers' [debit] cards as having expired and refused their transactions. [Source: *Sydney Morning Herald* 3 Jan 2010, AAP news wire]
Spam Assassin is a pretty widely used e-mail filtering program. One of the rules it uses is checking the date on incoming e-mail. If it's wrong, then some points are added to the "is this spam?" score. It seems that up until a rushed update the afternoon of Jan. 1st, 2010, the standard installations, using the default rule set, considered the year "2010" to be way off in the future. Accordingly they gave e-mail with that date an automatic 3.5 points. Five points gets you to the "spam threshold", so lots of material coming through on the new year got clobbered. It seems the "year date" was hard/hand coded, as opposed to making a comparison to "today's" date. The SpamAssassin folk have a new version which corrects this problem. Folk running SA can also modify that one rule set and bypass the issue. Details: http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 [Also noted by Dave Horsfall: "To summarise, it blocks messages with dates set too far in the future (which apparently is a common spammer trick - I read my e-mail in forward order of delivery) and 2010 was inside the range of 2010-2099."] https://secure.grepular.com/blog/index.php/2010/01/01/spamassassin-2010-bug/
Recently, I have seen several letters questioning the whether Y2K was a real hazard, or whether it was an invented crisis. Several of these letters have appeared in *The New York Times* Letters page following the publication of "It's Always the End of the World as We Know It" (Op Ed, 1 Jan 2010). The coincidence is uncanny. Yesterday (5 Jan 2010), Network World published "Y2K all over again in 2010?" on a series of outages related to this most recent decade change. The Network World article can be found at: https://www.networkworld.com/news/2010/010510-date-change-problems.html The New York Times Op Ed can be found at: http://www.nytimes.com/2010/01/01/opinion/01dutton.html The Letters relating to Op Ed can be found at: http://www.nytimes.com/2010/01/06/opinion/l06climate.html - Bob Gezelter, http://www.rlgsc.com
Recently, Verizon took over MCI, resulting in me getting them as my new local telephone provider. This afternoon, I used Verizon's online site to change the billing address for my account. About an hour later, I got a nice automated phone call that was intended to verify that the change was legitimate. So far, so good. But the automated voice informed me that if I hadn't authorized the change, I should "contact us at [slight pause] between the hours of [slight pause] and [slight pause]. Thank you for choosing Verizon." I guess I should be glad that "[slight pause]" didn't come out as "left parenthesis null pointer right parenthesis." Geoff Kuenning email@example.com http://www.cs.hmc.edu/~geoff/
On December 18th, 5 Eurostar passenger trains failed, in the Channel tunnel trapping 2000 passengers. (Eurostar is the rail service through the tunnel under the English channel) The service only resumed on Tuesday 22nd. The failure was due to inadequately "winterised" trains encountering snow and extremely cold weather: "The snow entered the locomotives' ventilation system... When the trains entered the great warmth of the tunnel, the electrical system short-circuited and the traction motors of the Eurostars cut out and would not start again." This problem was known. It is NOT a "Black Swan" ! Apparently in contrast to the passenger trains, the car-transporter trains are sufficiently winterised. If the failure was not already a disaster, there is no doubt at all about the evacuation. Some passengers were trapped in the tunnel for up to 14 hours, and complained about lack of/conflicting information, as well as the heat. Thousands of passengers waited at the railway (train) stations for a service that would not be available for days. There was not much of an alternative: huge queues for ferries , and planes delayed by the weather. e.g. http://www.independent.co.uk/news/uk/home-news/thousands-stranded-as-eurostar-service-is-suspended-1846350.html The risks: 1. (IMHO) an inadequately tested contingency plan. 2. We passengers assume that a rail service will be reliable -because it almost always is. Perhaps we should not/cannot and need to take our own "emergency equipment" along?
I suppose it's fair game these days to hide anything you like within an HTML div style="display: none; visibility: hidden; overflow: hidden;" like they do on http://topics.cnn.com/topics/weather . They even store a "404 Error The page you requested cannot be found" inside that HTML div. "Who would ever browse without using (our) stylesheets?"
After an extensive multiyear collaborative effort, the RSA 768-bit challenge number has been factored, suggesting that 1024-bit prime products may be somewhat closer to approaching the end of their practical lifetimes. http://bit.ly/8xXSgy (International Association for Cryptologic Research)
KLAMATH FALLS, Ore. A Nevada couple letting their SUV's navigation system guide them through the high desert of Eastern Oregon got stuck in snow for three days when the GPS unit sent them down a remote forest road. http://www.foxnews.com/story/0,2933,581303,00.html
It is common to rely on downstream syndication feeds (e.g., ATOM, RSS, usenet news) for information. Unfortunately, sometimes there are "clogs" in the pipeline that result in delayed, lost, or out of sequence messages. Those who read RISKS using Google Groups have recently experienced just such an episode. RISKS 25.85, 25.86, and 25.87 are out of sequence on the archive at http://groups.google.com/group/comp.risks and RISKS 25.88 is completely missing as of this date (4 January 2010), despite having been posted on 26 December. Fortunately, the RISKS page at http://www.risks.org is up to date. Bob Gezelter, http://www.rlgsc.com
The default browser, Polaris 6.0, on my Samsung Rant is nearly useless so I installed the Opera Mini-Browser. I ran into IP geolocation issues when responding to e-mailed employment alerts, as many websites would reject my application with a message informing me that one must be a United States resident to apply for their position, even though I am an American using the phone in the mid-Atlantic region of the United States. The Opera mini-browser evidently brings with it an IP address out of what IP geolocation types would label a "Norwegian address pool". I had to wait until my return home to apply, rather defeating the purpose of purchasing a web and e-mail enabled cellphone. Gary Bliesener, Unix System Administrator
<http://www.latimes.com/business/la-fi-toyota-throttle29-2009nov29,0,5254584.story> An *LA Times* item has lead the coverage of the issue, bringing up the accusation that the problem is not just mechanical interference between the mats and the pedals, but also more. Eric Weiss was stopped at a busy Long Beach intersection last month when he said his 2008 Toyota Tacoma pickup unexpectedly started accelerating, forcing him to stand on the brakes to keep the bucking truck from plowing into oncoming cars. .. But Weiss is convinced his incident wasn't caused by a floor mat. He said he removed the mats in his truck months earlier on the advice of his Toyota dealer after his truck suddenly accelerated and rear-ended a BMW. Also, I saw a mention that a previous driver of the car that crashed had complained to the dealer about the problem, but it was reissued to the victim despite that. If true, THAT would not alter the cause, but would likely change the legal liability issues.
Re: Mark Thorson, RISKS-25.88 > When the target position is cleared, it would probably be better to > initialize it 100 meters to the east or something, rather than right on > top of the observer position. Where it might drop on your friends? It seems to me one wants to expand the range of values to include "no target position." It can't be all that unusual sometimes not to want to drop a bomb. Curt Sampson <firstname.lastname@example.org> +81 90 7737 2974
John Johnson (R 25 88): "The problem is also evident on motor vehicles with LED signal and stop lights. Snow is not melted away by the signal and stop lights and accumulation blocks the lights." Neither can incandescent stop and signal lights melt snow if they are not used often; such as long stretches of driving on the open highway. Nor could they melt snow when there was a generous air gap between the bulb and the lens cover. I can't recall any mention of this risk in the pre LED era. What's new?
John Johnson's mention (R 25 88) of a story that LED traffic lights can be a problem if it snows because they don't generate enough heat to clear themselves brings to mind a repeated story from the NY area. Every fall, we get delays in mass transit because of wet leaves on train tracks. I never recalled hearing of such problems years back, and indeed reports have indicated that this is another side-effect (or lack of a side-effect!) of new technology. In the old days, trains stopped by apply brake pads to the wheels. The resulting friction heated the wheels and rails and rapidly dried and burned off any leaves. Today, the trains use regenerative braking: The wheel motors are run as generators, recovering much of the kinetic energy of the train as electricity. Much more efficient - but as a result, the wheels and rails no longer hot enough to perform a leaf-clearing function.
This is actually an old problem with a new twist: the designers of traffic lights and headlights were — probably unknowingly — relying on an undocumented feature of incandescent light bulbs, namely their ability to generate enough heat to melt snow on cold days. Obviously it did not occur to anyone that light fixtures should be redesigned for a different type of bulbs.
The general class of risk here is that of unintended consequences. It may be helpful to drill down into the specifics of what is going wrong. In both of these submissions (traffic or vehicle signals), LEDs are replacing incandescent bulbs in outdoor applications subject to varying weather conditions. The notion appears to be that nobody could have predicted that more efficient lamp technology would be subject to a failure mode in the snow. Such a notion is mired in confusion over the difference between describing a problem and entertaining solutions to that problem. "Unintended consequences" is another way of saying "undiscovered requirements". The underlying problem is one of signaling, not of lighting technology. After all, before there were traffic lights, there were unlighted traffic semaphores. Drivers still use hand signals on occasion to supplement lighted turn signals and brake lights. The common goal is to communicate signals (of intent, permission, and proscription) between a community of drivers, pedestrians, and other roadway users. In addition to numerous requirements relating to sequencing of interlocking signals, there are - as a matter of course - various requirements regarding weather and ambient visibility (and other sensory) conditions. For instance, presumably the LED manufacturers did not neglect to consider the effect of rain on the operation of their signals. A complete set of top level requirements for a roadway signaling system might not even mention lighting technology at all. More likely, constraints on lighting will appear as non-functional requirements describing current practices and standards (eg., the order of the colors on a traffic signal). A statement that a signal device should continue to operate when it is snowing (presumably up to some NNN-year blizzard threshold) is very much a functional requirement inherent in the concept of operations. A compliance audit/acceptance test should have caught this issue - almost by inspection - before deployment. LEDs are desirable because they inexpensive to operate due to their high efficiency. They are efficient because they emit far less waste heat. What happens to the snow accumulation when heat is removed from the system? Some possible solutions have already been mentioned: a heating element (perhaps actively controlled), weather shielding, special coatings. The point is that there is one problem description ("signal must continue to operate when it is snowing"), but many different options for solutions. It is impossible to evaluate the acceptability of any solution without matching it point-by-point against the problem requirements the solution is meant to address. Some risks are long and involved to describe. It is precisely that this issue can be characterized so succinctly that reveals a requirements failure. Whether the vendor or the customer bears a larger burden of the responsibility for the failure is a separate question. Rob Seaman, National Optical Astronomy Observatory email@example.com
Please report problems with the web pages to the maintainer