Rest is always best. Again, based on what you’ve said, definitely go for the MAC, and quite frankly, if everyone you work with who has a PC prefers XP, then I’d say go with XP if - and that’s the crucial part - you have a good virtual machine. With a good virtual machine, you probably won’t get more than the average amount of attacks that would hit a regular XP install, and you almost certainly won’t get any spillover into your native MAC installation.
Also, just one little point of clarification on the driver shim: it’s not a matter of similarly spelled drivers, but rather of inserting a new driver between two existing drivers in the logical flow of information; Microsoft itself does this routinely with a lot of the diagnostic stuff, for example. A good example is Microsoft’s Network Monitor, which shims drivers into the network stack so that it can intercept and display IP packets going to and from your network card.
Think of it this way: App1 has to be able to “talk” to the screen, I’ll call it Screen1, to display information. To do that, App1’s information has to be translated into a form that the screen hardware will accept and display as an ordered set of LCD pixels. To make that translation, there is a driver, call it ScreenDriver, that sits between the two, so schematically it looks like:
App1 —> ScreenDriver —> Screen1
Now, App1 doesn’t know anything about the internal workings of Screen1; all it knows is that it spits out the ASCII line “hello world” and Screen1 then flips LCD pixels so that the lighted pixels arrange themselves to show that same phrase in lighted pixels.
It’s sort of as if App1 only spoke Russian, and Screen1 only spoke Mandarin: ScreenDriver is bilingual and speaks both.
Now, say that Hacker comes along and - for whatever reason - wants to intercept that traffic and reverse every sentence. To do that, Hacker can simply insert a new driver either between App1 and ScreenDriver, or between ScreenDriver and Screen1 - call it HackerDriver.
One configuration would be as follows:
App1 —> ScreenDriver —> HackerDriver —> Screen1
HackerDriver would need to speak Mandarin and Russian, even though it sits between two Mandarin speakers. It would work most simply by taking data from ScreenDriver, reverse engineering it so that it could figure out what Russian sentence the Mandarin it got from ScreenDriver was supposed to be, altering that Russian sentence, and then retranslating it into Mandarin before sending it off to Screen1.
Screen1, not knowing the original Russian that App1 sent - by definition - would happily display the altered sentence “dlrow olleh” and would send back an “OK” signal to confirm that it received the data - in Mandarin - and was able to display it. HackerDriver would then pass that confirmation back to ScreenDriver - after filtering it first to make sure that Screen1 wasn’t trying to pass back a digest or some other tell-tale of the actual data that was displayed (that would be an audit trail of a sort).
ScreenDriver would receive the “OK” signal from, to all intents and purposes, Screen1, and would in turn confirm back to App1 that the data was properly received and displayed.
Nonetheless, the user would immediately see that something funny was going on between his fingers hitting the keyboard and what was being displayed on the screen.
Of course, in the meantime, HackerDriver could be doing other nasty stuff because a lot of drivers are actually allowed to execute portions of their code within the so-called kernal-space of the OS - the protected inner sanctum.