I was able to do this with my own volumes, but I don't have access to other users' volumes. An employee at Amazon, however, could potentially have that access, and therefore could reproduce these steps. Or what about the government and the NSA? If they can get a copy of the volume, they could go to town on your data.

I like how he went on about running things through psexec, as if you can do that as a normal user (which would obviously be Really Bad), and then suddenly said "Oh, you need to have an administrator account to run psexec".

Anyone with local access and time can eventually access your data, the attack is OS agnostic, news at 11

//yes with good crypto that time increases well beyond a life time assuming no major break in quantum computing///Much like bank vaults, crypto should be measured in hours to crack instead of assume unbreakable

I agree that the "OMG fundamental Windows security flaw" angle of the article is overblown, there are some interesting tidbits there. I thought the chntpw tweak was good stuff, and the registry edit was useful too.

But yeah, if someone can mount your drive the CIA of your data has been compromised, regardless of operating system.

The author's concerns are valid; for that reason, I only run Linux servers, which will require use of a third-party program for reading extfs partitions in Windows before a hacker who gains access to the drive can read my data. I am therefore entirely secure and safe.

Wasn't the article about virtual drives or volumes in the cloud -- not a hardware drive in the computer. I believe that there are different ramifications. I am responsible for a corporate database -- I want hands on - not a big fan of the "Cloud". Clouds always imply storms.

Though if you mount a linux partition in another copy of linux that you have root on, you can do all these same things. Its not even a "windows" issue, its an issue of having access to the hardware (or at least virtual hardware in this case)

Keeping in mind that Slashdot isn't loading for me, so I'm just basing this off what everyone's saying in the comments.

1) If the attacker has physical access, you are owned. End of Story. No ifs, ands, or buts.2) Yes, the administrator employees at Amazon have access to your accounts and data. I work at a Big Data startup, and yes, if we so desired, we could totally screw with you. However, because we like eating food, and we aren't that stupid, we don't.

I haven't been able to read Slashdot for a few years now without a growing sense of how entitled and out of touch its community has become in terms of 'news for nerds'. These days its a thinly veiled platform for stalmanites harping about everything they don't like and letting their little impotent rage-quits/fanboyisms turned articles vent in an echo chamber of safety.

You just can't take the site seriously any more, I'm surprised the article wasn't filled with S->$ replacements, which just further reinforces how low the bar has gotten over there. They are the Linux_yes of technology news sites, a parody of what they used to be, nothing more.

So, basically, that idiotic screed boils down to you've discovered that physical security is an important consideration for servers and data that are housed in locations you don't have direct control over?

Good job. For your next trick maybe you could try discovering your own ass?

That code ("ev.which") might not even work in all browsers; although I guess JQuery could add the "which" if the browser only has "button" for mouse events.

Oh, and:Mozilla browsers like Firefox since at least(!) Netscape 4:

[i.imgur.com image 342x272]Firefox probably hides those options behind an "Advanced" button or even in about:config

At this point I've really lost track of whether people are playing along with the joke or taking it seriously. Nevertheless, that particular pref never thwarted the right click nag scripts, at least not on any browsers I ever used. It just blocked the oncontextmenu event, IIRC.

serial_crusherNevertheless, that particular pref never thwarted the right click nag scripts, at least not on any browsers I ever used. It just blocked the oncontextmenu event, IIRC.

The alert will appear, but so will the context menu (either before the alert or after you clicked it away).

Interestingly enough though, in my browser the context menu will appear with right-click "disabled" whether I use that option or not.So maybe that option is indeed just for the contextmenu event, but - at least in my browser - stopping the propagation of the right-click event won't stop the browser from opening the context menu.

The Voice of Doom:serial_crusherNevertheless, that particular pref never thwarted the right click nag scripts, at least not on any browsers I ever used. It just blocked the oncontextmenu event, IIRC.

The alert will appear, but so will the context menu (either before the alert or after you clicked it away).

Interestingly enough though, in my browser the context menu will appear with right-click "disabled" whether I use that option or not.So maybe that option is indeed just for the contextmenu event, but - at least in my browser - stopping the propagation of the right-click event won't stop the browser from opening the context menu.

Probably has changed in recent years. Used to be that the popping up of the alert dialog made the menu go away (on Windows. no guarantees about other OSes). This was back when browsers used the basic system dialog APIs for whatever reason, and the alert box was fully modal. About 10 years too late Firefox finally implemented their own alert box that's only tab-modal.