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…
Source: Jim Motavalli, *The New York Times*, 4 Feb 2010 http://nytimes.com/2010/02/05/technology/05electronics.html The electronic systems in modern cars and trucks — under new scrutiny as regulators continue to raise concerns about Toyota vehicles — are packed with up to 100 million lines of computer code, more than in some jet fighters. ``It would be easy to say the modern car is a computer on wheels, but it's more like 30 or more computers on wheels,'' said Bruce Emaus, the chairman of SAE International's embedded software standards committee. Even basic vehicles have at least 30 of these microprocessor-controlled devices, known as electronic control units, and some luxury cars have as many as 100. [Nice article on "throttle-by-wire" cars, eschewing physical linkages. PGN]
It appears that the problem was software: Toyota to recall 400,000 Prius cars over software glitch. Following driver complaints about poor braking performance, Toyota plans to recall around 400,000 Prius hybrid cars to replace software controlling the antilock braking system. http://www.itbusiness.ca/it/client/en/home/news.asp?id=56365
Increasingly, computers are in control of our cars, says Paul Horrell, and that is changing our relationship with the open road http://news.bbc.co.uk/1/hi/magazine/8510228.stm
Nancy Leveson commented to me, ``When is the auto industry (and everyone else) going to learn that you cannot `exhaustively test' software and introduce modern safety engineering techniques that are appropriate for digital systems and not just use those developed for the electro-mechanical systems of the past?''
It occurred to me that I've had a throttle stuck wide open twice in the past[*], and neither incident was at all dramatic; the recent Toyota problem is only deadly due to the misapplication of the PC-style "soft power button" concept to a safety critical system. This is compounded by the use of a non-standard control interface in an environment that is otherwise highly standardized - that very standardization is a "key" safety feature. Home-made dashboards with non-standard layouts and pushbutton ignition switches are common in motor racing, and a simple, robust solution was implemented decades ago - all race cars are required to have a *mechanical* switch which cuts power to all drive-train systems, with standard color, labeling and placement. Perhaps in future cars with ignition buttons like this Toyota, or software controlled drive-trains like in a hybrid, there could be a mandatory standard requiring a hard-wired engine cutoff knob on the right hand side of the steering column, thus implementing the UI everyone (who doesn't drive a Saab) is familiar with? Also ... I would have expected that the US federal "PRND21" standard for automatic transmission controls would require that a car could always be freely shifted from D or R to N to guard against just this circumstance ... any US auto engineers available to comment? * For Lindsay Marshall's amusement: one in Tyne Tunnel at rush hour, when it was used by the A1.
An ad for the Mercedes Benz E Class touts its "safety" features, among which is that it can "even stop itself if [the driver] becomes distracted". http://www.youtube.com/watch?v=3DgjfzHY5-2sM Right. Because nothing could EVER go wrong with THAT. Richard S. Russell, 2642 Kendall Av. #2, Madison WI 53705-3736 608+233-5640 RichardSRussell@tds.net http://richardsrussell.livejournal.com/ Any idiot, upon seeing the first automobile, could easily predict that it would revolutionize transportation. Only someone with exceptionally keen insight could have foreseen that it would also revolutionize the sex lives of teenagers. Isaac Asimov
I've been buying some medications through an online pharmacy run by my
health plan. They seem to have added a new feature: when it's refill time,
an automated system calls you and walks you through reordering. All in all,
I found it to be a pretty convenient system.
Of course, Federal law requires them to protect my privacy; as I understand
it, they can't legally reveal my prescriptions even to a family member. So
when they got to the point of telling me what was available for refill, the
automated voice kindly told me that they needed to verify my identity, then
asked me to enter my birthdate and one other super-secret piece of
information... my ZIP code.
Um, yeah. My wife *definitely* isn't going to know that one.
Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
Keep trying, and keep the best.
Who Owns Your PC? New Anti-Piracy Windows 7 Update
"Phones Home" to Microsoft Every 90 Days
( http://lauren.vortex.com/archive/000681.html )
( http://lauren.vortex.com/WAT-KB971033.jpg )
Greetings. Sometimes a seemingly small software update can usher in a whole
new world. When Microsoft shortly pushes out a Windows 7 update with the
reportedly innocuous title "Update for Microsoft Windows (KB971033)" — it
will be taking your Windows 7 system where it has never been before.
And it may not be a place where you want to go.
[Very long but worthy item TRUNCATED for RISKS. Check out the original.
PGN]
Seems that the EMV standard has been compromised: > "Chip and PIN is fundamentally broken," Professor Ross Anderson of > Cambridge University told ZDNet UK. "Banks and merchants rely on the words > 'Verified by PIN' on receipts, but they don't mean anything." http://news.zdnet.co.uk/security/0,1000000189,40022674,00.htm More reports: http://resources.zdnet.co.uk/articles/0,1000001991,40022669,00.htm http://www.telegraph.co.uk/science/science-news/7215920/ http://www.physorg.com/news185118205.html Anderson's paper is available: http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/ EMV is called often called "Chip and PIN", as well as "Chip Card" in Canada. Some financial institutions put a lot of stock in the security of this: > You are responsible for the full amount of all authorized activity or > other Transactions resulting from use of the Card or Connect ID and PIN or > Password by any person, including any entry error or fraudulent or > worthless deposit at an ABM or other machine. You are responsible for the > full amount of all unauthorized activity or other Transactions which occur > before we receive notification that your PIN, Password or Card was lost or > stolen or that your Connect ID, PIN or Password may have become known to > an unauthorized person. On receiving such notice from you we will block > the Card's, PIN's or Connect ID's ability to access our services and/or > the use of a Card or the Account. https://www.tdcanadatrust.com/tdvisa/pdf/select.pdf (column 9) In many cases, the banks' (now no longer trust-worthy) logs are the definitive record: > Our records will be conclusive proof of use of a Card or the Account or > electronic services and will be considered your written request to perform > the Transaction. Even though you may be provided with a Transaction > receipt, verification or confirmation number, or interim statement by or > through an ABM or other machine, the following applies to all Transactions > or other activity on the Account: > * our acceptance, count and verification of Transactions or deposits > will be considered correct and binding unless there is an obvious error > [...] (Ibid.) Some are a bit more reasonable, but if your card has been cloned (and put back in your wallet/purse), you may not notice the problem until too late: > If someone uses your Visa Card and your PIN or your Visa Account number > with any other security code to make unauthorized purchases or otherwise > obtain the benefits of your Visa Card, you will not be responsible for > those charges provided that you (i) are able to establish to our > reasonable satisfaction that you have taken reasonable steps to protect > your Visa Card [...] and (ii) cooperate fully with our > investigation. [...] > You are not responsible for unauthorized use of your Visa Card or your > Visa Account number in transactions in which neither a PIN nor a security > code is used as the cardholder verification method. http://www.rbcroyalbank.com/cards/documentation/pdf/ch-agreement.pdf
A driver's parking penalty fee escalates after the council payment web site repeatedly reports that she has nothing to pay - because she entered her car registration number in lower case. http://www.guardian.co.uk/money/2010/feb/12/southwark-council-car-registration
every ten years, because we forget or ignore what we should have learned.
In RISKS-25.89 ("Y2K+10 problem 4: SpamAssassin tags '2010' e-mail as
spammish") M. Burstein wrote that the problem was that "It seems the 'year
date' was hard/hand coded, as opposed to making a comparison to 'today's'
date." and observed that "The SpamAssassin folk have a new version which
corrects this problem." In fact, they do not. The replacement rule
incorporates the same problem as before, scheduled to occur simply ten years
further into the future, in January 2020. This mistake has not been learned
from, let alone corrected.
This is a core problem. The human race forgets or ignores problems that it
has already solved. Back in the 1990s I was quietly predicting that by the
year 2010 people would have forgotten all of the issues that had to be dealt
with for the 1999-to-2000 transition, and would have gone back to (say)
using two-digit year numbers. In part this would have been because people
were erroneously calling it a "Millennium Bug", causing the erroneous
inference that it was something that only ever arose every thousand years
and could be forgotten once the year 2000 was past. Michael C. Battilana
(www.cloanto.com/usrs/mcb), D. R. Ladd (writing in the letters page of New
Scientist on 1998-03-14), J. R. Stockton, and others besides, all more
loudly than I pointed out that the bug was due every century, and that the
foolish name "Millennium Bug" tended to disguise that. But in part it would
also have been because we won't have turned to people making the same
mistakes all over again, saying "What you are doing is a bad idea, that cost
the world a lot of time, effort, and money the last time we had to clean up
the mess made. Don't repeat it.".
And here we are, in 2010, showing that the world has not only not learned
from the mistakes of 10 (and more) years ago, but is even making mistakes of
the same type but with shorter periods than a century. The developers of
SpamAssassin hit a problem caused by, in effect, ONE-digit year numbers
(with regular expressions that fix the first three digits of the year at
"200"), and rather than learn from the world's experience with the problems
of two-digit year numbers of a mere ten years ago, they simply put the bug
off for another ten years. It's "Rollover Year" every ten years with
SpamAssassin.
And it's "Rollover Year" every century with others. It's sad to note that
not only have some parts of the world forgotten the lessons of two-digit
year rollover of a mere ten years ago, and gone back to using two-digit
years, but other parts of the world never really even fixed the problem in
the first place.
Here's one example from personal experience. Recently, I wrote an NNTP
server and updated an NNTP client. Following RFC 3977, section 7.3.2, I
made the client use 4-digit years in all "NEWNEWS" commands that it sends.
I also made the server outright reject "NEWNEWS" commands that used 2-digit
years, on the grounds that the RFC 3977 semantics for 2-digit years differed
from the RFC 977 semantics, differed from the Single Unix Specification
semantics, and were quite silly (requiring, as they did, the inference of
year numbers that pre-date by several decades the very existence of
NetNews); and that surely everyone had long since switched to 4-digit years,
it being more than a decade since the specification for 4-digit years in
NNTP (which has been around since IETF draft specifications of the 1990s)
was invented and (supposedly, given that IETF standardization is supposed to
follow practice) put into practice.
I was quite saddened to discover in testing that the world of NNTP simply
ignored the Century Bug completely, and largely ignores RFC 3977 too. I
have yet to find in production use (albeit that I've not finished testing)
an NNTP client that sends anything other than 2-digit years with the
"NEWNEWS" (and "NEWGROUPS") command, despite the strong recommendation in
RFC 3977 to the contrary, and I have yet to find an NNTP server (other than
my own) that actually recognizes 4-digit year numbers when sent, despite the
outright requirement in RFC 3977 for supporting this.
I haven't tested, but I strongly suspect that no-one even implements the RFC
3977 semantics for inferring four-digit years from two-digit ones, and the
world still implements the RFC 977 semantics, which date from 1986 and
mandate (for example) protocol commands as daft as asking for the NetNews
articles from the year 1961. (The RFC 3977 changes to those semantics make
things yet dafter, mandating protocol commands as daft as asking for the
NetNews articles from the year 1912, and which introduce a new problem of
jitter resulting from poor implementations on the 31st of December and the
1st of January every year.)
I'm sure that RISKS readers can produce similar experiences in other fields.
So WHY haven't we learned the lessons here? Why are people, only a mere ten
years on, forgetting the problem entirely and going back to employing
two-digit years? Why are people even creating and perpetuating new
ONE-digit year rollover problems, that they then had to deal with this year,
and will even have to deal with again a few years from now?
JosephKK, in RISKS 25.85, on a different subject, touched upon one of what
is almost certainly many reasons. Xe is right. Current computer
programming courses are inadequate in several areas which are perennial
RISKS staple topics: bad handling of personal names; bad handling of dates,
times, and timezones; and bad handling of geographic locations. I did a
quick review of a couple of IT textbooks at the time of RISKS 25.85 but
didn't turn up anything that explained the common IT errors to avoid with
personal names. It would be interesting to hear from RISKS' resident book
reviewer, M. Slade, or anyone else, how many IT textbooks he has encountered
that explain, for example, how it doesn't match reality to design database
schemata (or laws!) specifying "Christian name" and "Surname" fields that
hold one, capitalized, word each; how many books explain that there is an
inherent ambiguity in a timestamp that doesn't include, or have implicit in
its specification, a timezone; and how many books explain that there are
practices that the world discovered, from the 1999-to-2000 transition, to be
bad, and that it is simple foolishness to repeat them. How much of the
experience that we've gained with doing simple, everyday, things with
computers in the wrong ways, over and over again (as past issues of RISKS
will attest), have we written down, published, and taught, for the benefits
of those who will come after us?
On the subject of not learning lessons from situations that we've already
experienced years before, here's a final something to think about in
relation to the recent RISKS discussion of synthetic engine noise for
otherwise nearly-silent cars (Gezelter, RISKS 25.88; Strickler, RISKS 25.90;
and others): Look up and consider the decades-long legal battle in the
U.K. (and elsewhere) over the requirement for and use of the humble bicycle
bell.
Montgomery County Maryland public schools have learned that students apparently installed keyloggers on teachers' computers, then used the passwords they captured to log in and change their grades. Besides disciplining the students, they've given teachers two (ineffective) instructions: to check grades, and to change their passwords. The first is ineffective because most teachers enter grades directly into the system, and don't have hardcopies of the assigned grades to compare against. (According to the reports, there's an audit log, but no indication whether teachers are being sent copies of their portions of the log to examine for anomalies.) Changing the passwords is ineffective, of course, unless they're confidence the keyloggers are cleaned up.... Source: http://www.washingtonpost.com/wp-dyn/content/article/2010/01/28/AR2010012803494.html http://www.washingtonpost.com/wp-dyn/content/article/2010/01/29/AR2010012902352.html http://voices.washingtonpost.com/answer-sheet/montgomery-county-public-schoo/mcps-orders-password-changes-a.html?hpid=newswell The RISK is quite similar to many other types of systems — if there's no way to cross-check data, then data attacks are much harder or even impossible to detect. That's true if you have a bank account and don't balance your checkbook, a grading system if the teacher believes everything on the screen, or an electronically cast vote.
(putting aside the whole issue of whether "cap and trade" and AGW is good,
bad, or indifferent...)
[Speigel Online]
Phishing Scam Cripples European Emissions Trading
Sneaky cyber-thieves have made millions by fraudulently obtaining European
greenhouse gas emissions allowances and reselling them. The scam has
hampered trading of the credits, which are seen as an important tool in
curbing climate change, in several European countries. .... According to a
report in the Wednesday edition of the Financial Times Deutschland, hackers
sent e-mails last Thursday to several companies in Europe, Japan and New
Zealand which appeared to originate from the Potsdam-based German Emissions
Trading Authority (DEHSt), part of the EU's Emission Trading System (EU
ETS). Ironically, the e-mail said that the recipient needed to re-register
on the agency's Web site to counter the threat of hacker attacks.
The cyber-thieves then exploited the user data that was entered into their
spoof Web site to transfer emissions allowances to other accounts, mainly in
Denmark and Britain, from which they were quickly resold. The new owners of
the allowances would have assumed that they had acquired them legally.
... The crime has hampered the registering of trades in allowances across a
wide swath of the European Union.
--------------
rest:
http://www.spiegel.de/international/europe/0,1518,675725,00.html
I received the following message today (links removed for obvious
reasons) with a subject line "Russian spear phishing attack against
.mil and .gov employees". What's interesting is that it's carefully
written (good grammar), explains the real issue with Zeus, references
a real project ("2020 project" which is at DNI) and then provides
links to innocent (but presumably compromised) sites to download a
"fix". In fact, the first paragraph is taken from a legitimate site:
http://intelfusion.net/wordpress/2010/02/08/russian-spear-phishing-attack-against-mil-and-gov-employees/
and the signature at the bottom is a legitimate researcher/company -
but of course the email didn't come from him, as shown by the email
headers.
This is definitely the best example I've seen of a phish....
>Russian spear phishing attack against .mil and .gov employees
>
>A `relatively large' number of U.S. government and military employees
>are being taken in by a spear phishing attack which delivers a variant
>of the Zeus trojan. The email address is spoofed to appear to be from
>the NSA or InteLink concerning a report by the National Intelligence
>Council named the `2020 Project'. It's purpose is to collect passwords
>and obtain remote access to the infected hosts.
>
>Security Update for Windows 2000/XP/Vista/7 (KB823988)
>
>About this download: A security issue has been identified that could
>allow an attacker to remotely compromise a computer running Microsoft®
>Windows® and gain complete control over it. You can help protect your
>computer by installing this update from Microsoft. After you install this
>item, you may have to restart your computer.
>
>Download:
>http://REMOVEDTHEDOMAIN.org/downloads/winupdate.zip
>or
>http://www.REMOVEDTHEDOMAIN.com/file/tj373l
>
>___________
>Jeffrey Carr is the CEO of GreyLogic, the Founder and Principal Investigator
>of Project Grey Goose, and the author of “Inside Cyber Warfare”.
>EMAILREMOVED@greylogic.us
Hmmm, a accessible CAPTCHA http://en.wikipedia.org/wiki/CAPTCHA#Accessibility with ALT text for each letter, <img alt='0' src="0.gif"><img alt='9' src="9.gif">... (Seen on http://www.mofnpb.gov.tw/PubOpinionMail.php?cat_id=99) Well I suppose they aren't giving away the store by putting them all in one string, but it is still nice for we text browser users.
> Mostly affects military users, but also implications for some civilians. Good old RISKS! My old TomTom Go 300 has been having trouble telling which road I am on for the last couple of weeks. Usually it's out by about 20 yards - enough that sometimes it gets the road right and sometimes wrong. I thought maybe it was a hardware fault, but now I am not so sure. How long until we have a flurry of new SatNav-got-it-wrong related posts?
There's no way to enter an apostrophe on the GPS. (quoting John Varela)
Equally irritating is the inability to search for names which contain
digits on my iPod Classic. Since I have a large number of classical
music tracks with titles along the lines of:
BWV 198: Lass Fürstin, Lass Noch Einen Strahl
this makes life unnecessary awkward.
The risk, I suppose, is that next time I'll look for a product that provides
a better user interface - assuming such a thing exists.
Bob Bramwell +1 902 531 2289
Please report problems with the web pages to the maintainer