1. The attackers can't be omnipresent at all times

2. Doing a MITM against all randomly-located HTTPS links is probably impossible to do without being discovered.

3. Some orgs like Torproject have an .onion address. Then you don't have to worry about MITM as long as your original copy of Tor was OK. If you're worried about Tor or other program being tampered with, try using one or more Linux Live CDs: Boot, update then install Tor or other secure proxy, then download keys and certs... leverage the built-in keys of the Linux distros.

Really, for anyone planning this type of attack, consistency is a HUGE problem and you only have to be slightly crafty to be reasonably sure about the keys you're getting. The only other thing to increase your certainty is to get key fingerprints from these people in person.

It ought to start by making certs and keys first-class GUI objects, starting with file browsers. Seriously, people should not see a blank square when they are copying or otherwise manipulating a key.

Further, there should be write-once devices that allow us to add keys and other identity info without worrying an attack will subvert that data.

Use Tor and some other proxies, sample multiple times.

You may have something there. Alarm bells were going off in my head when I saw the summary advocating a move toward not away from X.509. If someone wants us to move toward the tech used by (famously subverted) PKI, they better damn well spell out how PKIs mistakes won't affect verification procedures.

That's why security is not a boolean. If you regard it as black-and-white, it'll drive you nuts.

Be thankful you can at least whittle the trust issues down to things like switch vendors.

Hopefully we'll see more about it on Slashdot once it starts shipping.

I should also point out that, from a manager or user perspective, a Qubes system is just a re-mix of Citrix client products. Even if the user runs in only one domain, an exploit against PCs is far less likely to break out of the VM, making cleanup a quicker and much more certain task.

It also has ways to protect you from physical attacks on boot partitions and BIOS, so travellers with laptops are less vulnerable.

Well, much of it already exists as Qubes OS, and it runs most Linux and Windows apps just fine.

You can get CoreBoot BIOS for several systems, and they're just getting started. And given that Canonical has the best HCL (with the most compatible systems) and hardware partnership profile in the business (apart from MS), I think Shuttleworth's proposal is credible... Good luck to him!

Thanks for the advice.

He's no Tony Blair or even a Mitnick or a Zimmermann. He might make $10k if he's lucky.

...particularly for punishing small fries who get in the way of large corporate interests and other big shots.

Along the same lines, we can ask why 'Bidder 70' went to jail for stopping the illegal sale of public land.

Read more of their site (and Joanna's blog). DMA is isolated with an IOMMU; You must have an Intel i5 or better with the VT-d feature and a chipset + BIOS that supports it. AMD also has some processors with IOMMU capability under their own trade name.

PCIe devices are assigned to VMs as needed (you can even configure it in the GUI).

Uh, x86 virt "wasn't" about security. Intel has already responded to bugs reported by the ITL team and others, so its changing for the better. Stick with Ivy Bridge or later.

The addition of the IOMMU feature alone is evidence the focus has shifted toward VM security.

As for legacy, it turns out that those PS/2 interfaces that have hung around in a lot of laptops (built-in keyboards) and towers are what keeps the USB miasma from negating the security architecture.

The whole mess has a lynchpin (perhaps the only one?)....

Modern computers are vast amalgamations of logic (of varying quality), and we can see only the iceberg tip of the iceberg tip of that content at any given time. Even the experts are left constantly guessing about the doings of all the invisible things inside.

Start by creating a creating a desktop OS with a hypervisor ingrained into it (all the risky stuff, even graphics and IP stacks are isolated) to reduce the attack surface to a very small area. Then, hopefully, more and more eyeballs and minds will concentrate their attention on the really crucial parts instead of getting PTSD over the whole expanding theatre of apps and services.

Next, turn attention to system firmware (CoreBoot BIOS, and Shuttleworth's initiative to replace ACPI). We're almost half way there now...

Finally, open hardware: CPUs, GPUs and such (we may see mobile devices benefit from this first).

TL;DR: Make the whole logic stack inspect-able and open, and tightly link the security context provided by those components to the privileged part of the GUI.

The explosion of "brogrammers" et al is a reflection of increasing amounts of code and complexity. Maybe this site closure is a just a symptom of that trend going too far... the surface area to be protected, audited and patched has just become to large and the security culture is caving under that weight.

I think I've mentioned Qubes to you before... I can stuff all sorts of apps and functionality into it without impacting my attack surface and overall risk much. I just have to think about the 'who' and 'what' of the app and the task before I assign it to a domain-- a little reflection buys me great peace of mind (instead of making me more worried, the way other architectures do).

This is based on a particular kind of Security By Isolation. The upshot is that the area of security focus for the community is reduced to the bare essentials, and that could have a positive effect in terms of available skills with more eyeballs looking at a given piece of sensitive code.