Slashdot Mirror
2010 Bug Plagues Germany
krou writes "According the Guardian, some 30 million chip and pin cards in Germany have been affected by a programming failure, which saw the microchips in cards unable to recognize the year change. The bug has left millions of credit and debit card users unable to withdraw money or make purchases, and has stranded many on holiday. French card manufacturer Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.' They claim cards in other countries made by Gemalto are unaffected."
from TOA
I wonder how does it compare to the losses from Y2K bug... I know it is hard to compare, because there was an unspecified money loss as part of unnecessary checks, difference in scale, anticipation and efforts to fix before manifestation.
I guess it hits you when you are least expecting.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
Who would have thought 2010 was going to be a big deal. We just had a 2010 programming problem at work. Everything worked great in December then in January our software simulation stopped sending the correct time to our hardware. Turns out the simulation handles 2010 incorrectly. We now have to set our PC clocks to 2009 until the team gets a fix out. I bet we see more of this.
It only took 65 years, but they finally got their revenge for those invasions. Subtle, the french are, very subtle and patient. Like mice.
Those who have telepathy have no need to RTFA.
Again, it's surprising that such an obvious software bug makes it into the real world. You really can never trust untested software at all. What disturbs me most are the proposed "solutions": the companies issuing the cards try to avoid the exchange of the cards by all means due to the costs involved. However, that comes at the cost of sacrificing the security gained by the introduction of the now ill-functioning chip. What has been mentioned as well was updating the software on the card at the banking terminal - I'm surprised that this is possible at all. Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).
Eye was going two say the same thing. They knead to insure they are spelling things the write weigh.
Moreover, it makes you wonder who much of a problem Y2K may have actually been if we hadn't of looked for all the problems and fixed them.
Chances are things like this would have only been the beginning if Y2K hadn't have been anticipated and planned for, even if we over-reacted. Maybe we should be giving some people more credit than we do...
Reminds me of a story I mention every so often. When I was an undergrad, I along with a few other enterprising students discovered that our university ID cards stored our social security numbers in the clear on the magnetic stripe. We eventually brought this to the attention of the school, who rushed to find a solution. They needed a unique identifier that was also not important information. They quickly settled on using our "university ID numbers" - arbitrary numbers whose value had no importance to the individual, and they reissued cards to the entire university.
A few weeks after they finished reissuing cards, one of us discovered that the "university ID number" was a primary key in the school's LDAP database. By using a directory browser, you could look up any student, staff, or faculty member by name, and obtain their university ID number. Since this was the number on their ID card, and their ID card controlled access to buildings, labs, etc., it was trivial to obtain access privileges to pretty much anywhere on campus. Want to make it look like the president of the university broke into the nuclear reactor? Look him up, write his ID number to a magnetic stripe card (we had built the hardware to do this, as well as to "fake" cards, which allowed us to simple type in numbers and generate signals, without actually making a card), and have at it.
Again, it was brought to the attention of the university. After a failed attempt to begin disciplinary action against one of us, they recalled everyone's cards and wrote new, presumably pseudo-random identifiers to them that were not publicly accessible.
Moral of the story? In your rush to fix one problem, make sure you don't create an even bigger one.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Hah, hah, hah!
Their they're doing there hair.
Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.'
I hope that money isn't in a German bank...
The response for y2k was not planned for, and it was not an over reaction.
Y2k issues were known in the 80's. Had IT been allowed to respond in a timely manner, it would have cost much less, been checked more thoroughly and finished earlier. Instead they waited until the last possible moment and poured much more money into it, hiring as many developers as possible to put in a rushed hackjob and then firing them when the hack worked instead of retaining them to vet, verify and implement permanent solutions where needed. This issue is a result of the failure to react apropriately to y2k. The rushed temporary get-it-done-yesterday hacks are starting to fail.
I was running a Y2K lab at my company from 1999 to 2000, and we found a TON of serious problems. Nearly all of our internal stuff had major issues, as well as email, phone systems, backup systems, and several operating systems.
The tests I ran went from 1998->2012 in one year increments (with full tests by all teams at each year step) and most of those problems were nailed down.
I'm guessing not all shops tested much further out than 2001 or 2002 - probably due to poor planning and lack of funds. As it was we had to cut ours back to 2012 because of budget constraints, so I can only imagine other shops did likewise.
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
Plus, by waiting until the last minute, no labor was wasted in pre-fixing systems that would already be obsoleted by 1999.
Yeah, but recall that in the Y2K bugs were mostly found in corporate COBOL programs, and COBOL code doesn't get retired. It just accumulates in the musty corners of old runtime libraries. There was a lot of COBOL code from the 1960s that was patched for Y2K
To see how bad the COBOL retention syndrome is, consider that IBM has had to supply emulators of older processors, so that customer companies could continue to run binaries for which the COBOL source has been lost. Yes, it really is that bad in the corporate DP/MIS/IT world. Of course, the binary-only programs generally couldn't be fixed for Y2K, and had to be rewritten. But they were rewritten by people adapted to the same corporate culture, and made the same mistakes in date/time handling that they've always made.
I remember reading a story by a fellow who got curious about the date problems in COBOL code, and started collecting examples of COBOL date-manipulating code. He said that when his count of the number of different date formats passed 180, he decided that he understood the problem quite well. This is still going on, as can be seen by looking at the date-handling code in newer software, and we still have the same problems.
Just last week, I gave a demo of some web code that I've been developing for a (mercifully) unnamed client. During the demo, some of the screens exposed the fact that the code internally saves all dates in ISO standard form, for the UT "time zone". I assured them that I could add the obvious translations to local time fairly soon, but this turned out not good enough. They were insistent that they didn't want the code "working on European time", and wanted the internal times all in local time. This despite the fact that they (and their visitors) are scattered across about 10 time zones. Just displaying all times in the local zone isn't acceptable; they object to Universal Time internally on general principles. I've seen this repeatedly on a lot of projects. It tells you a lot about why our software continues to have time-handling problems, whenever any particular ad-hoc time representation reaches a value ending with some number of zeroes (in base two or ten).
It was really funny a few days ago, when we read about spamassassin's bug triggered by the first day of the year 2010. I predict that we'll get reports like this in every year ending with a zero, for as long as any of us is alive. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.