The Duo battery chargers for NiMH batteries are safe, but the software that enables the user to monitor the batteries is infected, PC World reported Monday.

The infected software includes a “backdoor” that allows some computer files to be to be remotely controlled, PC World said.

The trouble begins if the consumer downloads Windows software from the Energizer company website If this was not done or if the consumer uses a Macintosh computer, consumer files are safe.

Consumers were advised to uninstall the infected software, reboot the computers and then go to the System32 directory in Windows. There, consumers were advised to delete “arucer.dll,” the file that is the actual backdoor, PC World said.

Energizer has discontinued the software, but you can still buy the DUO at Amazon for about $20.

The vulnerability was first discussed at this week’s Black Hat DC conference by Jorge Luis Alvarez Medina, a security consultant with Core Security Technologies.   Microsoft says the risk is highest for IE users running Windows XP or who have disabled the browser’s Protected Mode feature.

Medina’s  presentation demonstrated how an attacker can read every file of an IE user’s filesystem.  The attack scenario leveraged different design features of Internet Explorer that can be combined to do serious damage.

Here’s more on Medina’s talk from DarkReading’s Kelly Jackson-Higgins:

[Medina] says popular features in IE, such as URL Security Zones and the browser’s file-sharing protocol, can together be abused to execute an attack that results in the attacker being able to read all files on the victim’s machine. Medina plans to release proof-of-concept code for the attack next month after Black Hat DC, and after Microsoft issues a security update for the attack, which affects IE versions 6 and above, he says.

“These vulnerabilities are just features … the implementation of the features allow you to obtain certain information, which by itself is harmless. But when combined together with other features, it renders an attack vector,” Medina says. The attack requires the user to click on a malicious link.

According to Microsoft’s advisory,  IE’s Protected Mode prevents exploitation of this vulnerability and is running by default for versions of Internet Explorer on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008.

The problem does affect every version of the browser but is considered most serious on Windows XP.

The vulnerability exists due to content being forced to render incorrectly from local files in such a way that information can be exposed to malicious websites.

For pre-patch mitigations, see the “workarounds” section of Microsoft’s advisory.

Nitesh Dhanjani, a well-known security researcher and author of Hacking: The Next Generation, says he has discovered design flaws in Facebook that could allow attackers to collect the personal information of users on the social networking site, and even build profiles of “friends” that might facilitate direct attacks on specific individuals within a company.

The flaws were presented to Facebook in November; Dhanjani has agreed not to release specific code or other details for two weeks while technical staffers at the social networking site continue their efforts to patch the vulnerabilities. Dhanjani says he has begun to speak generally about the problem, without specifics.

The vulnerabilities center around the way Facebook enables users to place third-party applications on their social networking pages, Dhanjani says. In a nutshell, Facebook allows the use of third-party apps within the confines of the site, but only if the user authorizes them. “If you click on a link that requires a third-party application, you see a dialog box, and you have to click ‘yes’ to authorize it,” Dhanjani explains. “Once you authorize its use, all of your information — your user ID, your friends list, everything — is shipped to the third party. I’m not sure people really understand what’s happening to their data.”

Worse, Facebook also has enabled some applications to provide “automatic” authorization, Dhanjani observes. “When the user visits the application from within the Facebook environment, Facebook inserts “a parameter,” he states in a report about the vulnerability. “If this parameter is present when the application is rendered, the application is allowed to scour information from the user’s profile. The intention in this situation is that if the user clicked on the application [rather than a third-party site that redirects the user], the user has implicitly granted some level of authorization.”

Dhanjani calls this automated authorization a “design flaw” in Facebook, but the social networking site has chosen not to comment on this particular concern. “They want users to be able to use the applications more easily, so it’s basically a business decision to leave it the way it is,” he states.

However, Facebook is responding to Dhanjani’s assertion that flaws in these authorization procedures could potentially be exploited to create clickjacking attacks.

“The goal is to write a rogue Facebook application that is rendered when a user visits a malicious third party Website,” Dhanjani explains in his report. “If the user already has an established session in Facebook [on another browser tab or window], the third-party site can load the malicious Facebook application in an iFrame to identify the user and steal the user’s Facebook information.”

Since only part of the actual Facebook site is being displayed in the iFrame, the attacker is essentially executing a “clickjacking” attack, Dhanjani says. The attacker is essentially creating a malicious application that looks like a legitimate app — and then when the user clicks on the right link, the malware uses Facebook’s flawed authorization process to collect all of the user’s Facebook data, including information about the user’s “friends.”

“We’ve already seen clickjacking work on Facebook, but those attacks were mostly used to spread spam to users and their friends,” Dhanjani says. “What’s happening in this case is that the attacker is using clickjacking to collect the data of the user, as well as the data on their friends. You could map that data to specific domains, such as users who are in a company and their friends.”

Cybercriminals could potentially use such a flaw to collect data on specific individuals, Dhanjani warns. “If you want to install malware on the computer of a user in a particular business unit of [a corporation], for example, that’s pretty hard to do with a traditional browser attack. But with this, you can actually target an individual or build a group of individuals that you want to target with a specific piece of malware.”

It’s hard to tell how dangerous these attacks might be because the severity of targeted attacks can’t be measured in numbers of infections or numbers of instances detected, Dhanjani says. “But I would be very surprised if there aren’t already [hackers] looking at this vulnerability,” he says.

Dhanjani plans to provide more details on the vulnerability, including specifics on code, in about two weeks — “Hopefully, after Facebook has fixed the problem,” he says.

A report released today by database security vendor Imperva Inc. serves as another reminder of why IT administrators need to enforce strong password policies on enterprise applications and systems.

Imperva’s report is based on an analysis of 32 million passwords that were exposed in a recent database intrusion at RockYou Inc. a developer of several popular Facebook applications. The passwords belonged to users who had registered with RockYou and had been stored by the company in clear text on the compromised database. The hacker responsible for the intrusion later posted the entire list of 32 million passwords on the Internet.

An analysis of that list provides the latest confirmation that a majority of users still don’t care about the strength of their passwords if they are left to choose on their own.

According to Imperva, about 30% of the passwords in the hacked list were six characters or smaller, while 60% were passwords created from a limited set of alpha-numeric characters. Nearly 50% of the users had used easily guessable names, common slang words, adjacent keyboard keys and consecutive digits as their passwords.

In fact the most common password among RockYou users was “123456″ followed by “12345″ and “123456789.” The other passwords rounding out the top five were “password” and “iloveyou.”

Many of the top 5,000 passwords in the list were identical to those found in password dictionaries, which are used by hackers to brute force their way into accounts, said Amichai Shulman, chief technology officer at Imperva. On average, a malicious attacker using such a password dictionary would have been able to break into a RockYou account at the rate of roughly one every second using an automated password guessing tool, he said.

Imperva’s report is by far not the first to highlight the tendency by many to use easily hackable passwords for online accounts. What sets it apart, however, is the sheer size of the sample that was analyzed for the report. Though the passwords in this case only controlled access to a relatively low-value user account, previous studies have shown that users tend to use the same password for multiple accounts, including corporate and financial accounts.

The Imperva report comes at a time when malicious attackers areincreasingly going after user credentials to break into enterprise networks.

Last November, for instance, the FBI’s Internet Crime Complaint Center noted that cybercrooks had attempted to steal approximately $100 million from U.S. banks using stolen log-in credentials. On average, the FBI is seeing several new cases opened each week, the complaint center said. In most instances, the crooks used sophisticated keystroke-logging Trojan horse programs to steal login credentials from company employees authorized to initiate funds transfers on behalf of the business, the FBI noted

Such attacks are highlighting the need for stronger access control and user authentication measures. For IT administrators, the main takeaway is the need for them to enforce a strong password policy over applications that they own, Shulman said. “If you let the user choose at their convenience, they will choose weak passwords,” he said.

Companies should also consider implementing controls for slowing down brute-force attacks, in which attackers try breaking into an account by trying to guess the password using an automated tool. Putting obstacles such as CAPTCHAs (Completely Automated Public Turing Test to Tell Computers and Humans Apart) in the way of a brute-force attacker are a good way to slow them down, the Imperva report noted.

Administrators also need to enforce a periodic password change policy and encourage users to create harder-to-crack passphrases instead of passwords, the report said.

The vulnerability in the Windows Virtual DOS Machine (VDM) subsystem was disclosed Tuesday by Google engineer Tavis Ormandy on the Full Disclosure security mailing list. Coincidentally, Ormandy received credit for reporting the single vulnerability that Microsoft fixed last week on its regular Patch Tuesday.

The VDM subsystem was added to Windows with the July 1993 release of Windows NT, Microsoft’s first fully 32-bit operating system. VDM allows Windows NT and later to run DOS and 16-bit Windows software.

Yesterday’s advisory spelled out the affected software — all 32-bit editions of Windows, including Windows 7 — and told users how to disable VDM as a workaround. Windows’ 64-bit versions are not vulnerable to attack.

It was Microsoft’s second advisory in seven days; last week, the company posted a warning of a critical flaw in Internet Explorer after Google said its corporate computers had been hacked by Chinese attackers. That bug is to bepatched later today.

“An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode,” said the newest advisory. “An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.”

Jerry Bryant, a program manager with the Microsoft Security Response Center (MSRC), said that the company had not seen any actual attacks using the vulnerability, and also downplayed the threat if hackers do exploit the flaw. “To exploit this vulnerability, an attacker must already have valid logon credentials and be able to log on to a system locally, meaning they must already have an account on the system,” Bryant said in an e-mail.

Typically, Microsoft ranks this kind of vulnerability — which it classified as an elevation of privilege flaw — as “important,” the second-highest of the four ratings in its four-step system.

Ormandy said that the vulnerability goes back nearly 17 years to Windows NT 3.1’s release, and exists in every version of Windows since. He reported the bug to Microsoft more than seven months ago.

“Regrettably, no official patch is currently available,” Ormandy wrote on Full Disclosure Tuesday. “As an effective and easy-to-deploy workaround is available, I have concluded that it is in the best interest of users to go ahead with the publication of this document without an official patch.” The workaround Ormandy included in his message was the same as Microsoft’s: Edit group policies to block 16-bit applications from running.

Although Ormandy divulged information about the vulnerability, even posted attack code that works on Windows XP, Server 2003, Vista, Server 2008 and Windows 7, Microsoft didn’t take him to task in the advisory for prematurely revealing the bug, as it almost always does researchers who spill the beans before a patch is ready.

Presumably, Microsoft will issue a fix for the flaw at some point, but as is its practice in security advisories, it didn’t promise to do so. The next regularly-scheduled security update is slated for Feb. 9.

Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld.

I am switching !

The maker of a life-saving radiation therapy device has patched a software bug that could cause the system’s emergency stop button to fail to stop, following an incident at a Cleveland hospital in which medical staff had to physically pull a patient from the maw of the machine.

The bug affected the Gamma Knife, a device resembling a CT scan machine that focuses radiation on a patient’s brain tumor while leaving surrounding tissue untouched. A patient lies down on a motorized couch that glides into a chamber, where 201 emitters focus radiation on the treatment area from different angles. The patient wears a specialized helmet screwed onto his skull to ensure that his head doesn’t move and expose the wrong part of the brain to the machine’s pinpoint tumor-zapping beams.

Courtesy NRC

Positioning is vital in the procedure, so when the couch moved out of position during a treatment at an university hospital in Cleveland last December, staffers hit the “emergency stop” button, expecting the couch to pull the patient out of the Gamma Knife, and the radiation shields at the mouth of the machine to automatically close. Instead, according to a report eventually filed with the Nuclear Regulatory Agency, nothing happened.

“Staff had to manually pull out the couch from the Gamma Knife and manually close the doors to the Gamma Knife to shield the source,” reads the report, which states that neither the patient nor the workers were harmed. “Radiation exposure to all individuals involved with the incident was minimal.”

When the hospital called the company that makes the Gamma Knife, it learned that there was a “known software bug problem” affecting the unit’s couch sensors. Known, anyway, to the company, Stockholm-based Elekta AB.

“Elekta was aware of the software ‘bug’ at the time of the December 2008 event and had implemented actions to correct the ‘bug’ in a future software release,” says Thomas Valentine, director of quality assurance and regulatory affairs for the Elekta’s U.S. arm, in an e-mail.

Since then, he adds, “The ‘bug’ has been corrected in software upgrades that have been implemented to all of the affected sites in the U.S. The U.S. NRC was notified of the completed status of software upgrades to correct the identified ‘bug’.”

We don’t know why “bug” is in quotes; surely this wasn’t a feature. In any case, Valentine says the Ohio incident was the only one of its kind “in the U.S.,” and that the bug had been triggered by an unusual combination of events.

It’s worth noting that Gamma Knife has been used to treat about half-a-million people without trouble. But the bug is another reminder that increasingly smart medical devices are susceptible to the same kind of programming errors that have long afflicted less critical applications. This week, the Los Angeles Times reported that Cedars-Sinai Medical Center made an error while tinkering with the settings on a hospital CT scan machine in February 2008, resulting in about 80 patients temporarily losing patches of hair due to radiation overdoses.

The most notorious medical bug was a “race condition” in the software powering the Therac-25 medical accelerator in the 1980s, which resulted in three patients dying from radiation overdoses from 1985 to 1987.

The far less serious Gamma Knife bug came to light in the medical community four months after the incident, after an inspector with the Ohio Department of Health spotted a discussion of the Cleveland incident in the minutes of the hospital’s radiation safety committee meeting. The hospital is not named in public filings, but had apparently failed to report the incident to the state, as required by law.

The Department of Health went on to report the matter to the NRC, which in April alerted hospitals around the county in an e-mail to its medical mailing list.

The following is a true story that illustrates a common problem with complex systems:

I cannot call my bank from my cell phone. The call will not go through.

Here are the facts:

• My cell phone can call ANY other number except my bank. It can even call other numbers in the same exchange. Therefore, it is unlikely that the problem is with my phone.

• The bank says that all their other customers can call them except for me. Therefore, it is unlikely that the problem is with the bank.

• My cell phone carrier says that every other customer can call every other destination and there are no outages between me and my bank. Therefore, it is unlikely that the problem is with the carrier.

So, by eliminating all probable causes, I have eliminated every cause.

Sir Arthur Conan Doyle Doyle once said “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.”

But in the world of complex systems, we cannot determine nor eliminate the impossible, so we are left to eliminate the improbable, and once you eliminate the improbable, whatever remains might be impossible.

Neither my bank nor my carrier is willing to spend the considerable effort it would take to trace down a problem that “probably” isn’t even theirs.

Somewhere in the connection between me and my bank, something very improbable has occurred. However, sitting between me and my bank are dozens of complex systems with millions of intricate interactions that are too fine for human comprehension.

There was a time in the early days of computer science when the entire workings of the hardware and software could be intimately understood by one human being.

Programs could be written on punch cards and reasonably understood without the aid of an IDE, compiler, or unit test cases. The code you wrote was only 1 or 2 levels removed from the metal and you did not interact with other systems. If there was a problem, it was relatively easy to determine which causes were impossible.

This is no longer true; not even close. Systems are so complex that anything is possible. Once you eliminate the probable causes, you are left with a practically infinite set of improbable causes.

The relatively recent emphasis on Unit Testing is (IMHO) a response to the ever-increasing complexity of software interactions. Not only is my code 4 or 5 levels away from the metal, but my code is dependent on a half dozen other massive systems that are also 4+ levels away from their own metal. The networking between systems adds another 2 or 3 levels. When systems call other systems the number of levels involved increases geometrically!

So now when I store my name as “Bert” in the database, but later retrieve it as “Ernie”, I have no reasonable way to even guess, much less trace, all the places that might have damaged my data along the way.

The only way to determine the output of a complex system is through constant and rigorous experimentation (unit testing). The days of predictable outcomes are all but gone.

But unit tests are still vulnerable to the layers of unknowns beneath them. A unit test may fail because some system 8 layers down failed. This is where mocking becomes valuable. If you mock out all of your external dependencies, you can bring all of your code back to within 4 levels of the metal and have a much better chance of executing accurate tests.

The big downside of mocking (besides the extra time and complexity it adds to your test) is that you’ve replaced an external dependency with your own fallible assumptions and fallible implementations of how that external dependency should behave in a real-world scenario.

Programmers now live in fear of the “real world” because the real world cannot be reduced to testable components.

Another factor working against us is that even high improbabilities can multiply into certainties. If you have a system that only fails once per year due to freak accident, then that’s a reasonably reliable system. But in a big I.T. shop you likely have at least 52 such systems, which means you’ve set yourself up for 1 freak accident every week! Every week you find yourself trying to find the cause of a problem that is virtually irreproducible!

This has become a serious problem that I don’t see anyone addressing in a meaningful manner. It is too time consuming and frustrating when every system failure results in finger pointing.

Sure there are profiling tools that can trace your code and let you punch through 3 or 4 layers of abstraction to watch what is going on in your code, but these are limited by many factors. (There are so many factors that I’m not going to list them all here lest I go off on a very long tangent)

My overall experience with profilers is that they find 10% of the problems dead-on, and they can give you good leads to follow for another 30% of the problems, but for the rest you are on your own.

Off the top of my head, the only cure I can think of is making our systems far more traceable. Here are some ideas I’ve come up with to accomplish that:

Trace Logging
Everything a system does should be logged in a common location so that it’s possible to trace all the communication from point A to point Z without having to run a TCP tracer or system profiler. Use “trace” level logging! That’s what it’s there for!

Treat your logging system like the black box on an airplane. Use it to record anything that can be helpful in determining the cause of a crash.

Live Testing
The assumptions made in the creation of the Unit Tests and mock objects should be tested against the live data as it arrives, and if anything falls out of bounds, that system must have the ability to sound an alert that results in human notification and not just another line written to a massive log file.

I’m not saying that your Unit Tests should be run in production, but consider enforcing the same assumptions you made about the inputs and outputs in your Unit Test. Having an clean interface isn’t good enough anymore. A Java/C# interface only enforces data types, not contents. You have to have code that validates the actual data that arrives AND validates the data that is returned.

Alerting
If you encounter an error, just don’t log it to some log file that nobody reads. Implement mechanisms that will alert an actual human being when there is a failure. The simplest way would be a tool that parses the log file and sends urgent e-mails for each error it finds. In the case of my inability to call my bank, there is SOME system somewhere in the chain that is recognizing an error state but has no mechanism to inform a human being of the problem. This is especially true of routers and switches and other magic black boxes.

Modern hardware servers (the physical boxes) implement both Live Testing and Alerting. If a memory chip fails a CRC test, then an alert is sent to the system admins. On more than one occasion they have detected a flaky memory chip that way. If it were not for those server features, we’d have yet another source of untraceable freak accidents. If hardware servers can do it, then why can’t software do it?

Fault Intolerance
Fault-tolerant systems lead to the most difficult bugs to trace. These systems try to be very forgiving of bad data and bad environments and do their best to continue their process no matter what. That’s fine, but tolerating faults without Alerting is a major cause of unexplainable system behavior.

I have personally witnessed an error that was caused by a firewall that was prematurely closing connections when it got overloaded. This made the firewall Fault Tolerant so that it would keep running under the extreme load. But it also caused many *months* of finger pointing when our applications would have mysterious errors under heavy load. If the firewall is unable to alert a human, then I would rather see it just crash completely and take everything down than keep operating in a way that causes mysterious and untraceable problems! If the firewall were to shut itself down completely, then we’d be able to zero in on the cause in no time! Otherwise we are left trying to catch live bugs in running systems which is damn-near impossible. The very act of trying to trace them can sometimes cause them to not happen! (We call those “Heisenbugs”)

I have personally witnessed other freak accidents caused by code that tried to “fix” bad data on-the-fly. If a required field was passed in as NULL, the code would replace it with empty-string or “none” and effectively kick the problem further down the road. DON’T DO THAT! Someone obviously thought they were helping reliability by making their code able to handle any situation. But what they really did was undermine the reliability of all the downstream systems and undermined the traceability of all upstream systems!

Error Failing
I don’t like the term “Error Handling” because that seems to imply that an error is something you can recover from. In most cases it’s not. If something isn’t what you expect, then fail noisily and alert someone.

Hibernate was the first major framework (that I know of) to abandon exception handling in favor of just failing outright via Runtime Exceptions that are thrown all the way up the stack. Catching an exception and trying to recover is quite often a bad thing to do.

Monitoring
Not everything that can go wrong will produce an alterable error. Systems are organic things that must receive constant checkups to see how they are growing. Tools that capture statistics about traffic must be kept so they can be analyzed for unexpected growth areas that might lead to bottlenecks.

The Cost
Here is the problem with all of my above suggestions: They aren’t easy or cheap. Many of the advances of Computer Science have been in pursuit of allowing developers to focus on business logic and not the plumbing. What I am proposing here is a LOT of plumbing that must be created by hand.

What is the cost of implementing so much plumbing? It’s high. What is the cost of months of finger pointing between various systems in your I.T. infrastructure? In the long-run it’s even higher.

You can argue that all this plumbing isn’t worth it just to solve the problem of the 1 customer out of millions who can’t call their bank. But I would argue that those 1-off problems are quite often seeds for much bigger problems, especially in the realm of performance issues.

I FEEL SO SAFE ALL OF A SUDDEN !

WASHINGTON – Department of Homeland Security official John Verrico admitted that a Chinese researcher had detailed precisely how vulnerable the U.S. electric grid is to a cyber-terrorist attack.

The disclosure reveals the government’s familiarity with a report released more than six months ago, in which Jian-Wei Wang used publicly available data to explain exactly how the United States’ West Coast grid was connected and how the computers that control the grid could be easily sabotaged.

Wang and his colleagues at the Dalian University of Technology in China demonstrated how an attack on even the most unimportant and least used networks within the power grid could cause what engineers refer to as a “cascading failure,” or a domino effect, in which one grid after another becomes overloaded and shuts down.

Most Americans can recall an event fitting this description when in the summer of 2003, a surge at one plant in Ohio caused just such a “cascading failure” and led to complete blackouts in New York City, on much of the East Coast and even in the Midwest. More than 45 million people were left without electricity, and telephone and even water services were disrupted. In all, the outage caused more than $10 billion in losses.

Official reports immediately denied any possibility of terrorism, but a Wall Street Journal report in April of 2009 revealed that hackers from China and Russia have twice breached the national security grid and may have left software programs behind that could be used to remotely crash the system. The same type of hackers successfully compromised a water treatment facility in Australia and caused 200,000 gallons of sewage to flood a city.

Some experts believe the 2003 blackout was in fact caused by a hacker – a software bug within an operating system responsible for managing alarm systems led operators to believe systems were functioning normally when, in fact, they were on the verge of collapse. The “worm” inside the computer system at just one facility contributed to the scale of the catastrophe.

The Obama administration claims the problem is being solved with $200 million of funding, but the reality is that much of the grid uses 1940s equipment and that a few terrorists with a little explosive material – like the kind used at many construction sites around the country – could attack the grid in dozens of vulnerable places at once.

Threats to the grid are not limited only to terrorist attacks or hackers. As Newt Gingrich pointed out in a recent speech, a nuclear weapon detonated in the atmosphere above a U.S. city could act as an Electromagnetic Pulse device, destroying the electrical circuitry that powers every computer in the city. His claims are based on the Report of the Commission to Assess the Threat to the United States from Electromagnetic Pulse Attack from April 2008.

Natural disasters can also wreak havoc on our relatively fragile infrastructure, as was the case in New Orleans after Katrina, after the blizzard of 2006 that dumped 26 inches on New York City, and after floods in north Georgia in September of 2009.

Citizens who sit back and expect the government to help them may be shocked to find that getting the power turned back on is not always easy and is rarely a priority for officials. In some cases it takes weeks before all the power facilities are back on line and lines are connected.

In response to the growing threat, many consumers are turning to alternatives, such as the one offered by Solutions from Science, an Illinois-based company that sells a solar-powered generator. Bill Heid, the chief executive officer of the company, explained how the solar power generator works. “The solar powered generator harnesses free energy from the sun, stores it and then delivers it cleanly and quietly whenever you need it,” explains Heid.

Unlike traditional gasoline powered generators, the solar powered generatoruses entirely free energy from the sun, and emits no fumes and makes no noise. “If you’ve ever used a gas-powered generator, you know how loud they are and how much they smell,” he said. “That’s hardly a practical solution in a residential situation.”

The solar-powered generator raises another concern of many survivalists whose plans rely on traditional gas or diesel powered generators; the long-term availability of those fuels in the event of a terrorist attack or natural disaster. If the electric grid is down for any reason, the pumps at gas stations won’t work and if there is any serious disruption to the electric grid, the entire “just in time” inventory system will fail altogether.

Consumers who have worked hard to prepare by counting on their traditional generators may find themselves with an expensive piece of equipment that does nothing but take up room.

Heid explains, “A gas powered generator may run out of fuel in as little as a few hours. If you’ve planned ahead maybe you’ve stored extra fuel, and if you’ve taken precautions to prevent it from spoiling, maybe that will buy you a few extra days, but then what? What will your family do when there is no more gasoline?”

Many observers have pointed out that the problems facing the U.S. power grid are likely to remain with us for generations. The aging infrastructure, the left’s opposition to nuclear power, a growing population and increased electric consumption are driving demand, while fossil fuel prices inch upwards year after year.

In the book, “Brittle Power: Energy Strategy for National Security,” author Amory Lovins makes the case that the U.S. energy infrastructure is even more susceptible to disruption, by accident or through malice than even imported oil.

It is this growing danger of blackouts that has driven many consumers to prepare for the worst, while praying that day never comes. Other consumers cite a desire for peace of mind, recognizing that without electricity, even the best-prepared family will suffer many hardships that could be avoided.

The rather minor glitch that led to the blackout in the northeast in 2003 disrupted water service, communication, transportation and even contributed to the deaths of more than a dozen people. Some consumers were without power for days. A few citizens remained calm and confident in their homes, despite the chaos outside, because of their preparations.

As Heid says, “Having a solar generator is like having a secret power plant hidden in your home…with clean, quiet, permanent electrical power at your fingertips.”

[via WorldNetDaily]

Email Received = 5:45 pm

Reply Sent = 5:58 pm

Reply Received = 5:56 pm

Finding a Google Error = Priceless ! !