Alan: Do you see Qubes as simply a proof-of-concept or something that will ultimately be a mainstream release?
Joanna: Definitely not a proof of concept! We hope it will be of interest to various organizations, commercial and government, which care about data security and are willing to invest some effort into configuring Qubes desktops. We plan to work on some commercial extensions, such as centralized policy management. The Qubes architecture is just great for use with Remote Attestation technology that might provide good security control to the IT staff over how employees’ workstations are configured (i.e. that they are configured properly).
On the other hand, I'm realistic enough to realize that it would never be a system for home users. The setup part would be just too difficult for a typical user, at least to do it right.
Alan: Are you still on track for a production-quality, stable release in October?
Joanna: I'd rather expect it at the end of the year :)
Alan: Why do you think things happen so slowly in security? We have the hardware technology to develop more secure operating systems. But it’s slow to get adopted. TPM still isn’t a standard feature on every new computer in 2011, despite the fact that it was introduced seven years ago. We even have software technology to develop secure systems, but it’s not getting implemented either. What will it take to get companies on-board?
Joanna: TPM is not something that can auto-magically make your system more secure. It can help implement trusted boot, which might be a reasonably good measure against Evil Maid Attacks, but doesn't make your OS any more secure against software attacks.
Much more important security technology is the previously-mentioned Intel VT-d, which allows for creation of untrusted driver subsystems like an untrusted networking subsystem, a USB subsystem, and so on. But this requires a radical redesign of the OS, so no surprise that it's not being adopted by most vendors.
I'm not sure which "software technology to develop secure systems" you have in mind? Perhaps you’re referring to Safe Languages and projects like Microsoft's Singularity?
Joanna: Well, when we read some early papers from the Singularity folks, such as this one, we see how excited they were about the software-enforced isolation that they have even proposed to remove some hardware isolation technologies from the processor (MMU, ring0/3)! Then, fast-forward two years ahead, and in another paper from the same folks, we see how they suddenly start to reconsider the use of hardware-enforced memory protection. Why do you think this happened? Because, hardware-enforced memory protection happens in just a bunch of gates (say a few thousand, maybe?), while the safe language-enforced protection is likely to be millions of lines of code that comprise the compiler/verifier and the runtime (e.g. garbage collector) that all need to be trusted!
So, don't get me wrong, I wish we had more software written in safe languages (I would love to have an email client written in a safe language), but we will never be able to replace the low-level hardware security mechanisms, such as memory protection (MMU), or DMA protection (IOMMU). The latter technology (Intel VT-d is an example of IOMMU) is absolutely critical, and even the early reports from the Singularity people (the optimistic ones) still recognize it.