The point is the iframe/JS is used to break out of the browser sandbox, due to a bug in the browser, with techniques like heap spraying (mentioned in the article).

Once you manage to get arbitrary code running in the context of the browser, you can do anything the browser can, including (presumably) making raw non-TOR connections to anywhere, identifying the TOR user and correlating that with what they were doing over TOR.

Among other things like installing arbitrary malware kits that completely compromise the machine.

you can use a raspberry pi for it. there's a nice tor-proxy kit on adafruit.

personally i think a separate machine booted using the tails bootdisk and no write access to anything is probably the safest.

I actually use a setup that involves a bunch of VMs for pretty good separation. It's a bit of a complicated setup, so I won't elaborate here. The main thing about it, is that even if an attacker runs with root privs on the "anonymous" VM, they'll need a 0-day in the Virtualization engine itself to de-anonymize the machine. I make sure that the VMs are as isolated from the host machine as they can be, so the attack surface is indeed minimized to the VM engine itself. Some "VM busting" attacks did occur in the past, but I believe very few (if any) attacked the VM engine itself. Most used the wider attack surface provided by stuff like the "VMWare tools" API (which for "isolated" VMs should be disabled). Edit: come to think of it, I should probably write up my method and post it to HN at some point...