From the fine article:

> The agents told Afifi they had other agents outside Khaled’s house.
>
> “If you want us to call them off and not talk to him we can do that,” Afifi said they told him. “That was weird. [...] I didn’t really believe anything they were saying.”

So it was worth covertly monitoring Khaled, but OK to mention it to his friend? And then ask if they wanted them to stop?

Dear FBI, who are presumably listening, neither myself nor any of my friends are terrorists, so you don't need to monitor us or infringe any of our rights. We're boring. Thanks.

Similar experience here - they called, got me to run event viewer. I lied and told them there were only Info and Warning messages - but he still exclaimed "OMG! you have a virus!" it was when he said "Now, it's very important - do not click anywhere or your computer will break" that I couldn't hold back and gave him a rant at how ludicrous he was being and asking what he's trying to scam. They hung up.

Of course, warnings and errors are completely run of the mill in Event Viewer (mine are mostly the DHCP service noting that I lose my address whenever I suspend my laptop)

from the where's-my-root-prompt dept.

$ sudo gainroot

There it is!

> Regardless of Theo's opinion of himself, he is right in that more complexity means more bugs.

That more complexity means more bugs I agree with. However:

• While the points of interaction are probably more complex (virtualizing interrupts, memory faults), there is a smaller number than in the typical kernel interface - so it's not clear whether the overall complexity is larger or smaller.
• The amount of code in a typical kernel includes many device drivers and other such features (filesystems, etc), which must all be written correctly. A Virtualization layer is providing a simpler set of primitives (block devices rather than filesystems), so there's likely to be less code.
• VM code is much less mature and hasn't had the security focus that OS's have. Unix-like OS's have been around for best part of 30 years, virtualization on x86 for, what, 10 years? Figures that Virtualization has had less security-related scrutiny (and almost certainly less than OpenBSD)

So I think there's potentially less code to be worried about in virtualization, but the code that is is still prone to security bugs, just the way page faults and the like are in conventional kernels. The lack of noise that's been made about virtualization security (until now) is a sign to pessimissists (or just those that are experienced) that it's not had the thorough peer review and battering that most OS kernels have. There's potential there for a smaller codebase to be worried about (thus more security), but in the short term, it's an unknown factor, which translates to less security. Long term, I think virtualization is a win, but there's no shortcut to a secure system.

His later points are pretty Apache-specific, but most of the early stuff (if-else, variables, case sensitivity, and so on) are all symptoms of trying to produce an ad hoc implementation of a general coding problem-- config file parsing-- instead of doing it just once in a library.

This problem is *everywhere*. Why are we still putting up with differently-designed config files for your webserver, your ftp server, your mailserver, your nameserver and heaven knows what else, all supported by their own pieces of custom code which, like Apache's, each have the possibility of growing up to be subtly wrong?

I know the Windows idea of a centralised registry sucks in too many ways (inscrutable binary is no match for human-readable text files), but there's one thing it's got right: all the apps which access their configuration use a consistent API to do so. Is it an impossible dream to hope that someone gets a bunch of large free software projects to agree on what needs to go into a libconfigparse, then implements it, and provides bindings for major languages? Then we might stand a chance of avoiding weird config file problems cropping up in Apache and everywhere else, slightly differently each time.