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…
An unfortunate series of events:
Eventually UAL put out a press release clarifying that the story was almost 6 years old, and that they were not in bankruptcy. Later that day the stock (mostly) recovered to over $10/share.
This could be a very clever method of market manipulation. If spammers sent out millions of messages with links to the story, and just a small fraction of recipients clicked the link, the story could easily move to the “popular stories” list. Or perhaps hackers controlling botnets just directed the computers they control to send a request to the server to load the story.
Among the risks I can spot (no doubt I'm missing some):
A. The story was undated, making it appear current. Possible solution: The automated system that adds stories to the database could include the date the story was added to the database.
B. The story was automatically spread by lots of systems doing exactly what they're supposed to do.
C. Neither Income Securities Advisors nor Bloomberg have humans fact-check these automated stories.
The story was widely covered. I learned about it here: http://online.wsj.com/article/SB122100794359017593.html
Steven J Klein, Your Mac & PC Expert (248) YOUR-MAC or (248) 968-7622
There are (at least) two interesting points here:
(1) The current mystery is why this article became “popular” in the first place? How many HTTP requests did that take? Are the User-Agent: headers identical (in which case one should suspect a botnet) or not (which does not rule out a botnet, of course)? How are the IP addresses of requesters distributed? What time interval did the requests arrive in?
(2) What we really have here is a failure of composition: Google didn't see a date on the article, so picked up the date on the web site's front page — something that the web site author didn't intend to imply the date of content linked to from the front page. Oops. Both parties did a reasonable thing, but the composition turned out to be completely unreasonable.
Tribune, Bloomberg and Google unite to clobber United
A nice summary of the events, followed by Google's and Tribune's take on what happened.
http://googlenewsblog.blogspot.com/2008/09/update-on-united-airlines-story.html
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-09-2008/0004882072&EDATE=
Philip Elmer-DeWitt, How Steve Jobs' obit got published, 28 Aug 2008
The first rule of publishing is that anything that can go wrong, will go wrong. (A corollary favored at Time Magazine, where I labored for nearly three decades, is that all copy is guilty until proved otherwise.)
None of this excuses, but it does help explain, how Bloomberg News managed to publish an obituary on Wednesday afternoon of Apple (AAPL) CEO Steve Jobs, who is still quite alive.
Advance work on famous figures' obits is nothing new, and given Jobs' well-publicized brush with pancreatic cancer four years ago and recent concerns about his weight loss, it's understandable that Bloomberg might choose this moment to update its piece on Jobs, although the version that got published contains no details about his health that weren't already in the public record.
According to a Bloomberg spokesperson, however, it was a routine update of the kind regularly performed by the obit department. …
http://apple20.blogs.fortune.cnn.com/2008/08/28/how-steve-jobs-obit-got-published/
[Source: John Markoff, The New York Times, 30 Aug 2008]
The era of the American Internet is ending. Invented by American computer scientists during the 1970s, the Internet has been embraced around the globe. During the network's first three decades, most Internet traffic flowed through the United States. In many cases, data sent between two locations within a given country also passed through the United States.
Engineers who help run the Internet said that it would have been impossible for the United States to maintain its hegemony over the long run because of the very nature of the Internet; it has no central point of control.
And now, the balance of power is shifting. Data is increasingly flowing around the United States, which may have intelligence - and conceivably military - consequences. … http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserland&emc=rss&pagewanted=all
Brad Stone, Global Trail of an Online Crime Ring, The New York Times, 12 Aug 2008
As an international ring of thieves plundered the credit card numbers of millions of Americans, investigators struggled to figure out who was orchestrating the crimes in the United States.
When prosecutors unveiled indictments last week, they made a stunning admission: the culprit was, they said, their very own informant.
Albert Gonzalez, 27, appeared to be a reformed hacker. To avoid prison time after being arrested in 2003, he had been helping federal agents identify his former cohorts in the online underworld where credit and debit card numbers are stolen, bought and sold.
But on the sly, federal officials now say, Mr. Gonzalez was connecting with those same cohorts and continuing to ply his trade, using online pseudonyms - including “soupnazi” - that would be his undoing. As they tell it, Mr. Gonzalez had a central role in a loosely organized online crime syndicate that obtained tens of millions of credit and debit card numbers from nine of the biggest retailers in the United States.
The indictments last week of 11 people involved in the group give a remarkably comprehensive picture of how the Internet is enabling new kinds of financial crimes on a vast international scale.
In interviews over the last few days, investigators detailed how they had tracked Mr. Gonzalez and other members of a ring that extended from Ukraine, where a key figure bought and sold stolen numbers over the Internet, to Estonia, where a hacker infiltrated the servers of a Dallas-based restaurant chain.
The criminals stored much of their data on computer servers in Latvia and Ukraine, and purchased blank debit and credit cards from confederates in China, which they imprinted with some of the stolen numbers for use in cash machines, investigators say. …
http://www.nytimes.com/2008/08/12/technology/12theft.html?partner=rssuserland&emc=rss&pagewanted=all
[Source: Ron Lieber, YOUR MONEY: Automated Bill Payments Are a Cinch (Not So Fast), The New York Times, 30 Aug 2008]
A few months ago, in my first column for this newspaper, I extolled the virtues of automated bill payments: Set them up once, let your utilities, phone and credit card companies pull what you owe from your bank account each month and never sit through the drudgery of a bill-paying session again.
And boy, did you let me have it. I heard from a number of readers who thought I was out of my mind for suggesting that they send money out automatically each month or give billers unfettered access to their credit cards and bank accounts. Horror stories poured in, as well as several specific questions and concerns.
So this week, we'll look at five reasons that people are wary of automating their financial lives this way. But first let's back up and define precisely what we're talking about.
Until the 1990s, most of us were stuck writing a whole bunch of checks each month to pay our various bills. Then came the early Web-based bill payment systems, where we'd go to a bank or biller's Web site and push a few buttons to move money to the right places.
Only more recently, however, has it become possible to pay each bill every month without lifting a finger. There are three basic ways to do this. You can give each biller permission to pull the full amount from your bank account. You can use the online bill system at your bank to push payments out automatically each month. Or you can charge every bill to your credit card and give only that card company permission to pull money from your bank account when the credit card bill is due.
Each of these methods has its potential shortcomings, which will become clear as we march through the hiccups that can occur when automating your payments. …
Self-checkout systems in UK supermarkets are being targeted by hi-tech criminals with stolen credit card details. A BBC investigation has unearthed a plan hatching online to loot US bank accounts via the checkout systems. Fake credit cards loaded with details from the accounts will be used to get cash or buy high value goods.
The supermarkets targeted said there was little chance the fraudsters would make significant gains with their plan. With the help of computer security experts the BBC found a discussion on a card fraud website in which hi-tech thieves debated the best way to strip money from the US accounts.
http://news.bbc.co.uk/2/hi/technology/7584258.stm
> […There should be no need for anti-virus software in a > well-designed voting system. PGN]
This is exactly a point I have been trying to make in several discussions about critical systems for satellite telemetry and telecommanding:
If you think you need anti-virus software in a (safety) critical system, there is something wrong with your design. Such systems, and many other safety-critical systems, should not contain
Said differently, any data entering the system should be in a format YOU define, and should have no accommodations for importing executable code. And there should be no software in the system that will attempt to execute any imported files.
So, no e-mail, no web servers or clients, no office packages, etc.
Actually, if the system has to undergo some kind of certification, I wonder whether anti-virus software would be certifiable. Its behavior is, after all, dependent on virus definition files updated regularly, and originating from uncertified sources. Anti-virus scanners do have false positives (I have seen at least one), so they may accidentally flag legitimate data as malicious, and may endanger the proper operation of the system.
The reaction I mostly get is something like : You might be right, but let's keep it just in case… Which means they didn't get the point.
Hmm, a lack of creativity here, methinks.
Innocent question: no chance of supplying a few to researchers to see if an acceptable alternative can be developed? If a company has the choice between a. flogging dead stock b. trying to make something acceptable of the remnants (i.e. get at least a return on the junk) by developing a new approach that can be audited, is open and can be proven to be safe (assuming that such is possible)
… wouldn't that be an excellent argument to supply a few systems to researchers for better, open developments? I refuse to accept that such systems are completely useless. Maybe sponsoring of an open, auditable project would be a better investment of government and corporate funds than parking the lot forever or scrapping it, and even the Company Formerly Know As Diebold (we know who you were) could then at least retain some market value.
Or is that a far too sensible idea?
It seems that what's needed here is for one of these jurisdictions to make some of the machines available to some public-spirited open source people, who could reverse engineer the thing and then write open source software that would make them perform correctly.
The instructions for a certain GPS device are excerpted in the October issue of Consumer Reports:
When you are directed to press a key, you should press and quickly release the key. (You may need to be held down for a period of time to start a secondary function, when the instructions tell you to do so.)
Mark Brader, Toronto, msb@vex.net | “Fast, cheap, good: choose any two.”
Background: most of the major lenders in the US are in deep financial trouble, and are trying to reduce their risks. One of the ways they're doing that is to cut back on HELOCs (Home Equity Line of Credit, aka “second mortgages”) - telling existing customers that even though they have a loan that says they're allowed to draw against the equity in their house, the homeowner is no longer allowed to draw money out because (the lenders claim) the value of the house is no longer enough to support the loan amount. This is being done in a blanket fashion - hundreds of thousands of people are getting these letters, based on generalized trends, not individual assessments.
My situation is similar to that of hundreds of thousands of other people, but I'm being bitten by the Automated Valuation Method (AVM) used by Homecomings Financial. Basically, they have a secret formula that gives a “value” to a house - and if you disagree with their conclusion, you have to pay for an appraisal to challenge it. In my case, I claim the value of the house is about $X, they say it's between 39% and 51% of $X (the most recent sale in my neighborhood was 1.1X, so I'm definitely in the right neighborhood). But because “the answer came from the computer”, it's nearly impossible to fight - the ability of the paper-pushers to look beyond the computer has been taken away.
I've recently been listening to some old Isaac Asimov Robot stories, where he talks about “the positronic machines” which make all of the financial decisions, including adjusting production, based on gathering every possible data point and even accounting for human desires to ignore the machines' instructions. At some point, the humans in the story become impossible of operating without the Machines, and no longer even understand how the Machines make their decisions. Dealing with Homecomings makes me think that Asimov's prediction has already come true, at least in some domains!
> $ sleep 55; launch_rocket > The problem is if one discovers a missing O-ring etc., then a Control-C > interrupt will not cancel the whole launch … Next time use an && > operator instead of a ;.
Unfortunately, && doesn't work so well either if one needs to temporarily put the launch on hold, but not abort it altogether:
$ sleep 55 && launch_rocket <Control-Z> [1]+ Stopped sleep 55 $ fg … Hey, how come my rocket's still sitting there?
Steven Greenwald's radio synced clock error is not so weird once you understand more pieces of the puzzle.
http://tf.nist.gov/timefreq/stations/wwvbtimecode.htm
If you check the above site for the time code format used by WWVB, you will get the information you need to figure out the problem.
The time code format uses a “day of the year” system, where days are counted from 1 to 365 during the regular year. August 18th, 2008 (a leap year - days will count to 366) is day 231. September 27th is day 271.
The difference is 40 days, AND both days are in the same “100”, and under 80 — one date is between 00 and 39 and the other is between 40 and 79. Because WWVB uses a BCD representation, such a pattern means that the error corresponds to a single bit error.
Normally, clocks will try some form of validation on the received data to prevent problems like this. They might try to receive several minutes worth of data and see if the results are consistent. If you read the spec carefully, you will see that this is necessary because there are no error detection capabilities in the format.
Although this may seem like an oversight when you are used to internetworking protocols, it's much more common in the industrial design space, where designers may have a final budget of only half a dollar for all of the electronics in such a clock.
It is certainly possible that your location (in Miami, FL - not close to Boulder, CO) and the storm create conditions sufficient to consistently have your clock read wrong by one bit. I expect that by this time, your clock is back to normal.
This happens frequently. The signal is transmitted by extremely-low- frequency radio, and if you are far from the nearest transmitter the signal can be faint or erratic. There is just barely enough bandwidth in the signal to send the time as a series of bits with no error correction and no redundancy. I've seen the wrong time and date on my own atomic clock.
You should use a quartz clock (or a plug-in electric clock if your 60Hz house current is dependable enough) as your primary reference and set it once a day from the atomic clock but only if the time shown on the atomic clock is reasonable. Under no circumstances should any automated process be controlled directly by a radio atomic clock.
This very subject had been discussed in RISKS-25.08; I quote my post (under the subject “Risks of Leap Years and Dumb Digital Watches”, http://catless.ncl.ac.uk/Risks/25.08.html#subj14), about a similar device by LaCrosse:
(…) It sets itself by listening to a radio time signal, so theoretically it should never have to be set at all, but every now and then it glitches and displays a wrong time, date or year; the difference is always a power of 2 in one of the digits, which looks like it's getting the data in some sort of BCD format, without any checksum or sanity check (which is not news on RISKS). I wonder how many critical installations are using the same chip.
The method described for subverting online checkin procedures must be airport / carrier / destination dependent to a certain extent. I usually checkin online and the printed boarding pass invariably carries a barcode that is scanned at security. A quick peek at the screen appears to show my checkin information, so only a very lax official would miss differing names. This happens at least at SFO and LHR.
The newly formed U.S. TSA has a serious problem: they have to supply Security, but they have no idea how (and it seems that they are unaware that nobody else does, either). But they do know that Security causes Harassment, and they do know how to do Harassment. So the obvious logic is, the more Harassment they'd do, the more Security will be produced. QED
Ron Garret <ron@flownet.com> writes:
> 1. The web site used a secure authentication scheme that behaves almost > identically to a less secure scheme > > 2. I am familiar with the more common design of secure sites […]
Are you? Then surely, you're aware that the common form-based login method also sends your password in the clear? The HTTP “digest” method is the only purely HTTP / HTML authentication method that doesn't.
I assume that you are also aware that this is all moot if the web site makes proper use of SSL.
> Are you? Then surely, you're aware that the common form-based login > method also sends your password in the clear?
Yes. That is why sites use HTTPS, and users are trained to look for little padlock icons.
> The HTTP “digest” method is the only purely HTTP / HTML authentication > method that doesn't.
Yes. Notwithstanding, it is hardly ever used, and I think my experience may be one reason why.
> I assume that you are also aware that this is all moot if the web site > makes proper use of SSL.
That depends on your definition of “proper use.”
But yes, I am aware of all this, and I assumed that the article's readers would be as well, so I left out some details in the interest of parsimony. Perhaps I should not have.
The user experience that surprised me was the following:
1. Restart my browser. Clear the cookie cache.
2. Go to the web site in question. Navigate to the page with the LOGIN link. This page was not secure.
3. Click on the LOGIN link, expecting to be taken to a secure page with a form to enter my credentials. I wasn't. Instead I was taken directly to my account information. This page was secure, but since I was not aware that my browser was silently accessing my keychain it appeared that I had just logged in without providing any credentials. The fact that the process started on an insecure page and ended on a secure one didn't seem relevant.
Please report problems with the web pages to the maintainer