Robot Drivers and Driving Tests

If we require training and licensing of humans to fly aircraft and cars, then how do those standards apply to software that pilots these things for us?


A key is situational awareness. You wouldn't easily give a blind pilot a flying license, yet effectively that is what Airbus tried to do with an engine control system that "landed" a test plane in a forest. It's one thing having a robot hospital cart that negotiates around people's ankles at walking speed, quite another to do that at road speeds, or while attempting to keep an airliner within its flight envelope.


Perhaps the human pilot or driver is expected to remain in control, on standby and ready to override the robotics? Good luck with that, as attention wanders and distractions take the foreground in the human's mind.


I see Google's already had cars driven by software logic on public roads. I wonder what the traffic cops would have to say about that?

Driver Cure or Driver Curse?

If you'd just dropped into the PC world last week, you'd think all software was perishable and had to be continuously refreshed. Must always have the latest version BIOS, drivers, etc.

This attitude runs counter to an older wisdom, that the first question when something goes wrong, is: "What changed?" With this in mind, the last thing you want is vendor-driven changes to your code base; in fact, for a critical working system, you want no changes at all.

The logic behind all this is contradictory...

• Software vendors make mistakes, requiring software repairs ("patches" or "updates")


• This happens so often, you may not be able to keep up with the constant flow of updates


• So it's best to let the software vendor push updates whenever they see fit

This boils down to: Trust software vendors to push changes into your code, because they fail that trust so often you can't keep up with the pace of quality repair required.

So, should you always patch, or never patch? Or sometimes patch? If "sometimes", then on what basis do you use to decide what needs patching?

Balancing risks

Some code is so critical, you may consider it too risky to change, e.g. BIOS and device firmware, device drivers, core OS code, and code that is running all the time and can crash the PC if it goes wrong.

Some code is so exposed to arbitrary unsolicited material, you may consider it too risky to leave unpatched, for fear that malware may exploit defects in the code to attack your PC.

Code should never fall into both of the above categories; if it does, you're probably looking at really bad software design. For example, integrating a web browser so deeply into the system that it's indivisible from the system's own UI, would be a bad design decision. Or consider a service so critical to the system's internal functioning that the OS shuts down the whole PC every time the service fails, that is waved at the Internet on the basis it's "networking"; that would be a really bad decision (Lovesan vs. RPC, remember?).

Trust me, I'm a software vendor

The two reasons not to trust a software vendor are incompitence and perfidity. A vendor who claims you "must" leave your system open to a constant stream of fixes, has declared themselves incapable of writing code that can be trusted to work properly.

And frankly, when even "legit" vendors hide deliberately user-hostile code within their products, set to automatically deny you service if its logic considers your license state is invalid (product activation) or distribute rootkits within "audio CDs" (Sony), I'd not trust any vendor's ethics.

Finally, even if you trust the vendor's ethics, you have to look at the mechanics of code distribution. Fakeware abounds, so when a third party claims to serve you fresh code from the vendors you trust, you have to ask yourself how trustworthy is that third party?

You also have to ask why you'd trust a particular software package. Open source advocates would say it's because you can read the source code yourself, or at least feel safer in that others have done this on your behalf. Closed source advocates would say it is unrealistic to read source code yourself, and instead would point to pre-deployment testing that would pick up unwanted behavior before the code was used in the real world.

Patches and updates change both of these equations, because now the code you read and/or tested, is no longer the actual code that is running. Any patch may add unwanted behaviors that favor whoever pushed the patch into your system. For the same reason, you should avoid software that stores "your" settings on the server side rather than on your PC (e.g. Real Player, many Instant Messaging apps) and "Privacy Policies" and End User License "Agreements" that state "these terms can be changed whenever we see fit", as so many do.

The race to patch

There's a race between freshly-released malware, vs. your antivirus scanner that protects your system. When a new malware is found, the antivirus vendor analyses the code to work out how to detect it, then how to safely remove the code, then that logic is packages as an update that your PC's scanner pulls to update your protection.

Compares this to what happens when a new vulnerability is patched. The malware coders can compare pre- and post-patched code to isolate the fix, then work out what the unfixed code did wrong, and thus how to attack that code. The exploit code is then packaged into malware prepared earlier, such as a downloader stub, and that's pushed into the wild.

Notice the similarities between these processes, i.e. recognizing and removing malware compared to extracting and exploiting code defects from studying patches?

If you rely on resident antivirus to protect you, then you are betting on the av vendor to beat the malware in the race. By the same token, you may expect malware coders to be fast enough to exploit your edge-facing code before the patch arrives to fix the defect. Hence the manic rush to patch, for fear of prompt exploit.

It's actually a bit worse than this, for two reasons. Firstly, sometimes it's the malware folks who find and exploit defects before the code vendor learns about these and fixes them. Secondly, software vendors have to ensure their patches don't break any systems, whereas a malware coder just wants it work enough of the time to spread, and doesn't care if it breaks other systems in the process. Less rigorous testing means "faster to market", right?

Self-spreading malware can also spread faster from more systems, and thus beat the patching or updating processes to the punch. Malware can be delivered in real-time via pure network worms, or links to servers that are themselves updated in real time. Often the malware that enters the system is just a downloader stub; it only has to last long enough to pull down the "real" malware, which can replace itself in real time as well.

Edge-facing software

With all this in mind, you can see why one would want to patch edge-facing software as soon as possible. Examples include web browsers, Java, Acrobat Reader, Flash and media players, and anything that is constantly exposed to the outside world, such as software that waits for instant messages or "phone" calls.

The best solution is to remove that edge-facing software, and thus the need to patch it. Do this whenever you don't need that software, when the software or its vendor are too flaky to trust, or when the update process itself is something you want to avoid.

For example, you may catch a vendor trying to shove new edge-facing software as "updates", even when that software is not present and therefore doesn't require patching. That's how Apple used to push Safari to PCs running iTunes or QuickTime, until they were pressurized to stop.

For another example, a vendor may decide you don't need to be asked before updates are pushed, or even told when this has happened. And when you look at that vendor's updater, you find it running as multiple scheduled tasks; then when you look at the details, you find a task that appears to be run once a day, is actually repeatedly run every hour throughout the day. That's the equation with Google, and why I would avoid any edge-facing Google software.

If you can't avoid edge-facing software, then you can protect yourself in two ways; by updating it as soon as possible, and/or by choosing such obscure, small-market-share products that they aren't likely to be attacked. The latter is like living in an unlocked shack in the countryside; that works not because shacks are "so secure", but because there are so few attackers around.

Driver Cure or Driver Curse?

So now we come to Driver Cure, which is a third party product that pulls in the latest versions of your device drivers. Would you want this? I'd say no, for two reasons.

Firstly, device drivers are code that runs so "deep" in the system, that any mistakes are very likely to crash the entire OS, leaving the file system corrupted, data files unsaved, etc. Device drivers usually run all the time, so bad code may prevent the system from being able to boot or run at all, even in Safe Mode. So I definitely don't want unexpected changes to this code, any of which may cause the system to stop working.

Secondly, device drivers are not edge-facing, so the risk of explosure exploit should not be high. That means less reason to patch in haste.

Thirdly, if malware were to be integrated into the system as deeply as a device driver, it would have considerable power and be very hard to remove. So we'd want to know a lot more about third party software that inserts "drivers" into the system.

The "Driver Cure" folks also push XoftSpy, which was one of several hundred fake anti-spyware scanners, until they supposedly "went legit". As such, sites and blogs may no longer call XoftSpy "malware" for fear of being sued; we may instead consider it as a legit antispyware that isn't very good at what it does, and costs money where better products are free.

So, in spite of "reviews" like these, I would avoid Driver Cure and anything else from that particular software vendor or distributor.

Zoundry Raven Double-Spaces On Blogger

I've started using Zoundry Raven as my off-line blog editor instead of Windows Live Writer, as the latter depends on Live Passport before it can do anything, anywhere, and for some reason that's gone haywire in my case.

It posts OK to my WordPress blog, but on Blogger (here), I see my text paragraphs are separated by two blank lines, rather than one.

Well, HTML always seems to have trouble with white space control; either too many blank lines, or not as many as you'd expect; reminds me of DOS vs. UNIX CR/LF issues in the days of dot matrix printers. Looking at the source code, I see previous posts have the (/p)(p) sequences I'd expect (where I've used parantheses rather than angle brackets to show the codes as text), but the new post has a (/p)(br /)(p) sequence instead.

OK, so I'll clean up my posts in the HTML code window before posting, right? Nope; this is "XHTML" in Raven, and it innocently shows the expected (/p)(p) sequences. So perhaps the transport process and/or Blogger's server side is screwing up - bleh.

AVG 9 Update Blocked By Ashampoo Firewall

Geek summary: AVGUpd.exe can't pass Ashampoo Firewall when launched within AVG, but works when run explicitly; as a workaround, create a Task to run on startup and every few hours

Firewalls sometimes block antivirus updates, even when all of the antivirus executables have been permitted full Internet access through the firewall. In this case, I hit the problem on a Windows 2000 PC, on which I'd installed AVG 9.0 Free antivirus and Ashampoo Free Firewall.

I searched about this and found several threads at AVG's forums, which usually pointed to an article that lists the AVG executables that should be allowed through the firewall. Other posts elsewhere simply declared Ashampoo as incompatible with AVG.

Even listing every AVG executable in Ashampoo's rules does not fix the issue, which is more subtle than it looks. Specifically, the AVGUpd.exe update tool does work if launched explicitly, but if it is invoked through AVG's general UI, the update fails.

If you run AVGUpd.exe directly, nothing visible happens unless you already have the general AVG dialog open at the time. If you do, then you will see that dialog indicate the update is now in progress, and it works.

The problem may be Ashampoo blocking interprocess communication within AVG (though I had disabled that sort of internal functionality), or failing to recognise when AVGUpd.exe is invoked from AVG's code (perhaps it calls it as a .DLL?).

A fix (aside from ditching Ashampoo, which I'm reluctant to use for the next Windows 2000 PC that needs a free firewall) is to create Start Menu and desktop shortcuts to run AVGUpd.exe, and/or set a Task to launch this when starting the system and/or every few hours during the day. Both approaches appear to work so far.