NVidia binary driver has security issues. Cat scratches man?

This isn't merely due to the Many Eyeballs rule. You probably do get many eyeballs on sexy, unique projects. But how many people ever work on any one X.org driver? Not necessarily more than the size of NVidia's driver development team.

The reason is much more fundamental. Good FOSS developers care about security. Fixing a security bug is a goal for them, just like fixing end-user-visible bugs, and just like adding features.

Proprietary software developers often care about security too, on an individual level. But their company doesn't care. A security bug for which no exploit has been published isn't very interesting. It's a potential liability, because it may be discovered one day and then it would have to be fixed. But it's better to delay that fix for as long as possible, simply to avoid wasting developer time on anything that doesn't directly bring the company revenue.

That's a basic, practically builtin behavior of for-profit corporations. As long as proprietary developers have to conform to deadlines and pre-determined feature sets, they're going to delay fixing security bugs (and any other bugs not immediately visible to the end user). Even looking for security bugs takes time. And neither finding them nor fixing them ever appears on the feature list for the next version due in December.

If the Devil quoted hacking scripture, he'd call that the 90-10 rule. Write the 90% [of features] today, and leave the 10% [of security testing and fixes] for later. It might not even ever be needed.

FOSS developers don't always have security at the front of their minds. But they have several advantages which just don't fit into the classic proprietary development model:

• No hard deadlines. Release when it's ready. If there's a target release date and you can't make it, the date is pushed back.


• No company pride/PR rating/stock price is on the line, so the developers aren't pressured to avoid admitting or just ignore the existence of bugs.


• Developers don't have an agenda forced on them from above, especially not by people who aren't or weren't developers themselves.


• Not working for money, not hurrying, and not being in danger of getting fired lets developers do things properly and spend time on things that aren't directly profitable, like fixing obscure bugs. (Of course, many FOSS developers do work for money, but their employers usually don't "own" the project in question.).


• You can add features just because they're nifty, even if you don't have a good case that the users would want them. Similarly, you can work on security issues even if you know you average user is a Windows junkie who neither understands nor cares about security.


• FOSS developers can ask for help from the upstream of the (free) software components they use. Proprietary code must be shrouded in secrecy, so asking outsiders for help becomes more difficult, and home-grown kludges tend to spring up.


• A FOSS project packaged for a major distribution will receive a huge amount of real-use testing in a mind-boggling variety of environments with different hardware, software and configuration. Only the very biggest companies have the resources to match that testing.


• FOSS developers get to use some great languages, like Python, Perl and Ruby, which are trivially decompile-able to source code. Many PHBs don't seem to understand that anyone could decompile their Java or C# or, with enough effort, C code easily enough to get whatever they wanted, and avoid these languages.

And, of course, the obvious ones which have been belabored elsewhere:

• Security through transparency


• Code quality through transparency, which leads to fewer bugs in general


• No backdoors in open code


• Some companies believe their bugs will never be found out since the code isn't available


• The ability of users to fix problems and contribute those fixes back to upstream


• Groups which, like OpenBSD, perform bug/security audits for free software

All this long-winded explanation can be summarized as follows. Proprietary and open development try to maximize profits and quality respectively. It's a horrible oversimplification, but if you want to remember a generalization that's right 90% of the time and horribly wrong the other 10%, use that one.

As a rule, I'll trust free software to protect me better than even the best proprietary software. In this case that means not buying NVidia cards, even though the latest ATi ones aren't supported by the respective free driver yet. (I wish I could have an AMD64 machine with one of those well-supported Intel GPUs...)

Of course there might well be bugs and security vulnerabilities in my hardware, the great majority of which which definitely belongs to the proprietary secret closed-source ideological camp. Or in my non-free BIOS (I wish LinuxBIOS would support just one motherboard I could actually use). Or in my network equipment. Or in the systems of my cable provider, my ISP, or my blog host. Or in those of some organization that keeps my private, confidential data, such as my government, bank, or credit company.

In fact, the probability that at least one of them has a security vulnerability that can and eventually will be exploited to substantially harm me probably approaches 1. But that's not a reason not to secure the system over which I do have control. Basic security really consists of two simple rules: being just a little bit more secure than the average guy (attackers will go for the easy targets); and not making any powerful personal enemies (if you do, the only good defence will be an offense).