Safari does not automatically start any executables without prompting, at least that I've ever seen.
It will also prompt you before completing the download of a disk image file which contains an executable (although I'm not sure whether if you click "cancel" at this point if it deletes the file completely, or just stops it from being mounted). So theoretically, if you were downloading something that you thought were screenshots, Safari would warn you that you were actually getting a program. The language that it uses is pretty straightforward, also. I think it says something like "The file you are downloading contains a program, which could potentially harm your computer. Do you want to continue?"
You'd have to be pretty clueless for that not to give you pause, if you were downloading something that you KNEW wasn't a program. I don't doubt that some people are going to do it, but at a certain point you can't blame the OS for user stupidity. It's one thing if a system allows an action you take on the internet in a browser to hose your computer, it's quite another if it lets you download a file, click "Yes" when asked if they're sure they want to download, run a program, type their password, and their files get hosed. You can't prevent the latter from happening while still having the system be halfway useable.
I was thinking about this. I can't imagine it would be all that hard -- there is already a visual flag applied to all "alias" (that's symlink) files, so it doesn't seem like it would be out of the question to do something similar for executables, based on the eXecute bit.
However what I'm not sure about is how you'd make this work for MacOS bundles -- unlike UNIX applications they're not just single files; the thing that you click on in the Finder to launch a MacOS app (at least a Cocoa one) is actually a directory if you look at it in the Terminal, it just has the hidden suffix of ".app" (so for instance the program Mail in the finder is actually the directory/folder Mail.app). The actual executable file is normally buried somewhere within the folder -- usually like (appname).app/Contents/MacOS/executablefile.
I suppose what you'd have to do is put the visual flag on if a file was either a directory ending in ".app", or if the regular eXecute bit was set on a file itself.
It's almost impossible for a clueless user to run as root on an OS X box.
Actually running/logging-in as root requires either some non-trivial Terminal work, or going in through NetInfo Manager (a fairly intimidating config utility) and enabling the root account (which at least the time I did it, a few years ago, gave you some pretty stern warnings).
That's not to say that you can't have root-like privs -- the default first user on a Mac is an "Administrator," which just means that they can sudo -s and become root temporarily. However to do this you have to authenticate for every action. (Or every 5 minutes or so.) The MacOS "Administrator" level user is not as powerful as the WinXP type of Administrator (which is effectively a root account). Macs have three levels of users: root, Admins (who can sudo), and everyone else (who can't).
So yes, there are definitely ways that a clueless person could damage themselves with a trojan, if they just mindlessly type in their password into any box that comes up, regardless of the context in which they're being asked, but there is at least one more step stopping you from doing it compared to running on a Windows system.
The "novel" thing here is that they've created an easy-to-use server component, so that people don't have to futz around with setting up a secure, redirecting proxy in order to do this.
I don't think there's really any new technology here, it's more a repackaging of existing stuff. But I'm not criticizing in saying that -- it's really the packaging that matters. A system that's not easy to set up is worse than useless, it's frustrating and might cause people to give up when they're interested in helping.
He doesn't need to install anything on his computer. Only you do. (At least this is my understanding of how it works.) One of the mentioned goals of this project is to avoid leaving incriminating traces on the client.
That's what makes this system better than Tor or some of the other anonymizing systems -- there's no client download. Plus it's HTTP-only, so it can't be abused by people who just want a way to download music, which might encourage people to actually set up clients.
I don't quite buy this. People in China can't just decide to open an account with Deutchebank or BoA -- they can only keep their money in one place, and that's in the Chinese state-run central bank. In fact, individuals in China can't even directly invest in overseas capital markets, only the central bank itself can do that.
So I'm not sure that there's really any big downside keeping them from blocking individuals' financial transactions: they're not supposed to be making any, except at the friendly local branch of the Central Bank. It's the sort of reasoning that makes sense if China were anything like Canada, but it's not. They could quite easily block all SSL traffic in and out of China except for a approved whitelist of companies and individuals, and probably not hurt their economy noticably. In fact I'm a little surprised that they haven't already.
Well it is an encrypted proxy also, I think, so the data going out along port 443 would theoretically look just like financial data (most online banks use SSL), or any other kind of encrypted HTTP connection.
However given that most Chinese people aren't allowed to hold accounts/investments with banks not run by the government, I'm not sure that it's really a great cover story. In fact I'm somewhat surprised that all SSL connections in and out of China aren't blocked by default.
They'd be better off burying the data on whatever port Blizzard uses for World of Warcraft client connections, honestly.
Tor requires that you install software on your local machine. As such, it's inappropriate for many people to use. I'd imagine that possession of the software in a place like China or Iran is considered prima facie evidence of seditious behavior and would probably land you in the re-education center regardless of what you were doing with it.
As is explained in TFA, "Mr. Villeneuve built a system that won't leave dangerous footprints on computers." As you can read here, the client machine doesn't require anything besides a regular web browser in order to operate, and you only need a secure channel once in order to set it up (to distribute the IP address, username and password) which can be pretty easily disguised. Also, you can use it from a computer on which you're not allowed to install software -- e.g., a netcafe. This provides an additional level of physical security: with a number of proxies and by moving from one cafe to the next, a user could make it very difficult to be picked out due to traffic analysis or usage patterns.
What we really need though, is something which combines the automatic routing of Tor and the ease of use of Psiphon: really, Tor without the barrier to entry that is a required software download.
I don't think your post makes sense. The Manchester Mark I was constructed post-ENIAC. Even though it might have been in development before, so it could count as a parallel discovery, it wasn't first by anyone's account.
The first Turing-complete machine actually constructed (to the best of both my and Wikipedia's knowledge) was the Z3, built by Konrad Zuse in 1941, in Germany. Nazi Germany. It was blown up in 1944, so it probably can't really be counted as the progenitor of modern computing; however, if you're looking to assign credit for "first invention" of a computer, after Charles Babbage, it's probably Zuse that you'd want to be looking at.
The reason that ENIAC is so important -- and recognized as being "a first," if not "the first" -- is because it's the beginning of a direct lineage which extends to the computer you're (probably) using today.
Perhaps if either the Germans had won the war or we hadn't bombed wherever the Z3 was being stored and captured it afterwards, then history would be told differently. Or if the British government hadn't been so secretive about the Colossus machines after the war. Or if Charles Babbage had been as good an engineer as he was a designer. There are lots of what-ifs that we can play, which would change how the story stands.
There are a lot of people who could have been first, if only circumstances had been slightly different. But they weren't, and so they're going to be stuck as a footnote to ENIAC in the history books. Is this fair? Arugably not; but it's life happens. Sometimes you're there at the right time in the right place, and sometimes you're just not.
I should have been more clear about the scenario -- I was assuming a situation where, because of either a TPM module or some other system, there was a requirement to recover the data in vivo from the computer where the drive resides.
Obviously if they can make a copy of the data by simply pulling the hard drive, then there's not much use to such a system.
Although I don't know the man, I just looked up what I think is his blog, and provided he's not lying through his teeth, the Politics and Public Policy section of his blog seems quite agreeable in spirit to me.
He also has some really interesting papers on there. (Check out the "Cocaine Auction Protocol" and "Programming Satan's Computer" -- the first is a methodology for creating an un-mediated auction house, the latter is about programming on untrusted networks.)
You shouldn't take this as an authoritative answer, but I believe the answer is no.
On a FileVault-enabled system, the only things which are encrypted are the user's home folder. The default location for swap space is not in the user's folder, ergo it's not encrypted. At least via FileVault, and I can't imagine it would just be encrypted by default using some other means, because that would necessitate a big performance penalty which a lot of users wouldn't be interested in.
The way filevault works is, when you enable it, a variable-sized, encrypted disk image is created at "/Users/.(username)/(username).sparseimage". Then, on login, this image is mounted to "/Users/(username)/". On logout, it's unmounted and compacted. This is all accomplished using the hdiutil program.
The rest of the filesystem is not encrypted, so I don't imagine that swap would be.
Maybe you realize this, but the RIP bill was passed in Britain, which last time I checked, doesn't recognize the 5th Amendment (or any other) to the U.S. Constitution.
I'm not sure whether you could take the 5th in response to a request to divulge your key, in the United States. I'm not aware of any cases where it's been tried, but that doesn't mean that it hasn't happened. I think it's far more likely that they'd just avoid the whole issue and use a keystroke logger (or hidden camera, or microphone) and get at the password that way.
That's US v. Scarfo; basically a mobster was using PGP to encrypt his communications and rather than breaking the encryption the hard way, the investigators got a warrant to install a keylogger. I'm not sure exactly how they did it, but I'm pretty certain that it was a hardware device implanted in the keyboard, rather than software. (The warrant they got was pretty much a blanket thing, approval for 'hardware, software, and firmware as necessary...') However they didn't divulge the exact methodology in the trial, because they successfully claimed an exemption under the Classified Information Procedures Act.
In addition, you'd want a system whereby you could enter a distress password, and unlock one level of security, while at the same time transparently destroying data, from the most secure level on upwards. So let's say you had three levels of encrypted data. The first layer is just some dodgy pictures of you and your wife. The second contains some emails showing you were evading taxes. The third is whatever you really want to protect.
For each level there are two passwords, one which will unlock it as normal, and another which will unlock it, and also begin a routine which will start securely erasing the third level data, then the second level, and then the first level + OS, and maybe trigger a lump of thermite sitting on top of the RAM for good measure. Or maybe it would be better just to get rid of the third level silently, so that it's as if it never existed. That's probably healthier, on second thought.
So that after you provide a good show of resisting giving out the password, you hand over the 'distress' one and let them have fun getting through the first level of junk data, while at the same time the system is slowly eating away at the stuff you really don't want, down on the third level.
You could even set it up so that the mal-effects caused by the distress passwords increase as you move through the levels of security. The distress password on the first level of security just starts the "silent erase" mechanism. The distress password on the second level speeds it up at the cost of less subtlety (because obviously they're getting closer to the actual data, so you need it gone faster). The distress password on the third level physically destroys the system in some sort of obvious (but quick) fashion. That way you're almost guaranteed not to compromise the data, but you also don't have to necessarily compromise yourself, unless they're really close to getting the stuff.
Nothing, but in the UK it is an offence to refuse to pass encryption keys to the Police if you are requested to do so.
It would probably be so in the U.S., as well, provided you could be shown to actually know it (i.e., you could claim to have spontaneously forgotten it, the old "I have no recollection of that, Senator," defense, but I'm not sure how long it would work).
However, let's say there was something truly incriminating on the drive -- something that would have you in prison for longer than refusing to aid the investigators would -- then it might be to your advantage to just refuse to divulge the password, and live with the consecquences.
Now, what you really need is a self-destruct system, and I think this is the direction we're going to see things go in: rather than just having a single password for the system, you have two. One is the real password, which you never, ever divulge. The other is a emergency/distress password, which you divulge if you are under sufficent duress. This would, when entered, create the impression that the system had been unlocked, but would in reality display a dummy set of data, and begin immediately destroying the real set of data. In a system where the 'real' data was stored in what appeared to be free space on the 'dummy' data's drive (similar to the TrueCrypt scheme mentioned further up in the thread), and if there weren't any outside signs that the drive was being accessed/written to, then it seems quite possible to destroy all the secure data without an observer noticing. At least until it was too late.
Camino puts an end to annoying pop-up windows and advertisements, which makes surfing the internet a much more enjoyable experience. The built-in annoyance blocking technology stops distractions that get in between you and the information you're looking for.
Most pop-ups are unwanted, but some sites make legitimate use of them. Camino displays an icon in the status bar whenever a pop-up is blocked, allowing users to unblock legitimate pop-ups with ease.
I'm not entirely clear how it works, or whether the blocklist is updatable, but there is also a freeware add-on called CamiBlock which allows you to import a blocklist (so I suppose you could use Filterset.G?).
I was interested up until this point. Once you've used Adblock (or PithHelmet on Safari, a shareware tool that does effectively the same thing) you'll never, ever go back to a "stock" browser. Or at least, I never will. It's a "killer feature" if I've ever seen one.
Somebody wake me up when they get a clue and build ad blocking into the browser like they should.
Good points. I have a feeling that you're not ever going to get a convincing gunfire sound simulation from conventionally designed speakers -- that pressure wave just isn't there. Maybe you could do it with compressed air or CO2 or something.
However I do think that sound from nearby shooters is more of a problem than recoil issues, at least with rifle shooting in military situations (i.e. predominantly from the prone position, most often now with the M16 or a derivative). The recoil on the M16 is pretty negligable; I've trained a number of people on it whose previous shooting experience were.22s or air rifles, and I've not seen anyone with a significant flinch problem (when wearing ear protection -- I don't think anyone trains without it). With handguns it's a different story, and I suppose for non M16-based weapons systems it might be more of a concern. (I probably wouldn't want to train a new shooter on a M98k, I have to admit.)
At any rate, I've found both in personal experience and working with others that it's more distracting and harder to get used to the sound of another person shooting right next to you, than it is just to deal with your own firearm in isolation; part of this might be because a rifle with a muzzle brake will be louder if it goes off next you you than in front of you. (You wouldn't think this is the case but it's quickly apparent if you've used one, there's sort of a cone right behind the muzzle that's quieter than the surrounding area.) Also, by the time you react to the noise of your own weapon, the bullet is out of the barrel, the guy next to you can fire just as your trigger is breaking and there's nothing you can do really to keep yourself from flinching involuntarily -- unless you're used to that happening and can back off and retry, you're probably going to miss where you're aiming.
Oh, we do. The U.S. sells all sorts of neat military toys to Taiwan, and we keep a nuclear aircraft carrier parked somewhere nearby most of the time.
Basically, presidents that came after Carter took less of a conciliatory attitude towards Beijing, and it goes back and forth with every new Administration; today the situation is "status quo maintanance," we give lip service to the PRC's position while at the same time selling guns to the ROC via the AIT. When Beijing starts rattling sabers too loudly, Taiwan gets a new Aegis or some Tomahawks. When we need the Chinese to stop dragging their feet in the UN Security Council on something, a few Taiwanese orders suffer "unfortunate delays."
However I think it's worth remembering who kicked off this wonderful and ongoing example of realpolitik, the next time he's criticizing another Administration for not upholding democracy or adding to his collection of peace medals.
That case was pre-DMCA. I'm not sure that the same thing would work now.
I think in order to make a Mac clone, you would almost necessarily have to break Apple's 'content protection' at some level or another (the obfuscated code, probably many other things as well). This seems to me like it would be an obvious DMCA violation.
I don't think that Compaq could do what it did to IBM, if the laws existed then as they do today. Sad commentary on our legal system, but it's the situation nonetheless.
Slashdot Mirror
Safari does not automatically start any executables without prompting, at least that I've ever seen.
It will also prompt you before completing the download of a disk image file which contains an executable (although I'm not sure whether if you click "cancel" at this point if it deletes the file completely, or just stops it from being mounted). So theoretically, if you were downloading something that you thought were screenshots, Safari would warn you that you were actually getting a program. The language that it uses is pretty straightforward, also. I think it says something like "The file you are downloading contains a program, which could potentially harm your computer. Do you want to continue?"
You'd have to be pretty clueless for that not to give you pause, if you were downloading something that you KNEW wasn't a program. I don't doubt that some people are going to do it, but at a certain point you can't blame the OS for user stupidity. It's one thing if a system allows an action you take on the internet in a browser to hose your computer, it's quite another if it lets you download a file, click "Yes" when asked if they're sure they want to download, run a program, type their password, and their files get hosed. You can't prevent the latter from happening while still having the system be halfway useable.
I was thinking about this. I can't imagine it would be all that hard -- there is already a visual flag applied to all "alias" (that's symlink) files, so it doesn't seem like it would be out of the question to do something similar for executables, based on the eXecute bit.
However what I'm not sure about is how you'd make this work for MacOS bundles -- unlike UNIX applications they're not just single files; the thing that you click on in the Finder to launch a MacOS app (at least a Cocoa one) is actually a directory if you look at it in the Terminal, it just has the hidden suffix of ".app" (so for instance the program Mail in the finder is actually the directory/folder Mail.app). The actual executable file is normally buried somewhere within the folder -- usually like (appname).app/Contents/MacOS/executablefile.
I suppose what you'd have to do is put the visual flag on if a file was either a directory ending in ".app", or if the regular eXecute bit was set on a file itself.
It's almost impossible for a clueless user to run as root on an OS X box.
Actually running/logging-in as root requires either some non-trivial Terminal work, or going in through NetInfo Manager (a fairly intimidating config utility) and enabling the root account (which at least the time I did it, a few years ago, gave you some pretty stern warnings).
That's not to say that you can't have root-like privs -- the default first user on a Mac is an "Administrator," which just means that they can sudo -s and become root temporarily. However to do this you have to authenticate for every action. (Or every 5 minutes or so.) The MacOS "Administrator" level user is not as powerful as the WinXP type of Administrator (which is effectively a root account). Macs have three levels of users: root, Admins (who can sudo), and everyone else (who can't).
So yes, there are definitely ways that a clueless person could damage themselves with a trojan, if they just mindlessly type in their password into any box that comes up, regardless of the context in which they're being asked, but there is at least one more step stopping you from doing it compared to running on a Windows system.
I think that's exactly what this is.
The "novel" thing here is that they've created an easy-to-use server component, so that people don't have to futz around with setting up a secure, redirecting proxy in order to do this.
I don't think there's really any new technology here, it's more a repackaging of existing stuff. But I'm not criticizing in saying that -- it's really the packaging that matters. A system that's not easy to set up is worse than useless, it's frustrating and might cause people to give up when they're interested in helping.
He doesn't need to install anything on his computer. Only you do. (At least this is my understanding of how it works.) One of the mentioned goals of this project is to avoid leaving incriminating traces on the client.
That's what makes this system better than Tor or some of the other anonymizing systems -- there's no client download. Plus it's HTTP-only, so it can't be abused by people who just want a way to download music, which might encourage people to actually set up clients.
I don't quite buy this. People in China can't just decide to open an account with Deutchebank or BoA -- they can only keep their money in one place, and that's in the Chinese state-run central bank. In fact, individuals in China can't even directly invest in overseas capital markets, only the central bank itself can do that.
So I'm not sure that there's really any big downside keeping them from blocking individuals' financial transactions: they're not supposed to be making any, except at the friendly local branch of the Central Bank. It's the sort of reasoning that makes sense if China were anything like Canada, but it's not. They could quite easily block all SSL traffic in and out of China except for a approved whitelist of companies and individuals, and probably not hurt their economy noticably. In fact I'm a little surprised that they haven't already.
Well it is an encrypted proxy also, I think, so the data going out along port 443 would theoretically look just like financial data (most online banks use SSL), or any other kind of encrypted HTTP connection.
However given that most Chinese people aren't allowed to hold accounts/investments with banks not run by the government, I'm not sure that it's really a great cover story. In fact I'm somewhat surprised that all SSL connections in and out of China aren't blocked by default.
They'd be better off burying the data on whatever port Blizzard uses for World of Warcraft client connections, honestly.
Tor requires that you install software on your local machine. As such, it's inappropriate for many people to use. I'd imagine that possession of the software in a place like China or Iran is considered prima facie evidence of seditious behavior and would probably land you in the re-education center regardless of what you were doing with it.
As is explained in TFA, "Mr. Villeneuve built a system that won't leave dangerous footprints on computers." As you can read here, the client machine doesn't require anything besides a regular web browser in order to operate, and you only need a secure channel once in order to set it up (to distribute the IP address, username and password) which can be pretty easily disguised. Also, you can use it from a computer on which you're not allowed to install software -- e.g., a netcafe. This provides an additional level of physical security: with a number of proxies and by moving from one cafe to the next, a user could make it very difficult to be picked out due to traffic analysis or usage patterns.
What we really need though, is something which combines the automatic routing of Tor and the ease of use of Psiphon: really, Tor without the barrier to entry that is a required software download.
What the hell is a "novel optical technique" and how do we know whether it has moving parts in it or not?
That doesn't say a thing about how it actually works. For all we know, there could be leprechauns in there, sorting out the different colored photons.
Interesting. I was not aware of this.
Do you need to do anything other than enabling it in the System Preferences (do you need to wipe/secure erase the old swap files, etc.)?
I don't think your post makes sense. The Manchester Mark I was constructed post-ENIAC. Even though it might have been in development before, so it could count as a parallel discovery, it wasn't first by anyone's account.
The first Turing-complete machine actually constructed (to the best of both my and Wikipedia's knowledge) was the Z3, built by Konrad Zuse in 1941, in Germany. Nazi Germany. It was blown up in 1944, so it probably can't really be counted as the progenitor of modern computing; however, if you're looking to assign credit for "first invention" of a computer, after Charles Babbage, it's probably Zuse that you'd want to be looking at.
The reason that ENIAC is so important -- and recognized as being "a first," if not "the first" -- is because it's the beginning of a direct lineage which extends to the computer you're (probably) using today.
Perhaps if either the Germans had won the war or we hadn't bombed wherever the Z3 was being stored and captured it afterwards, then history would be told differently. Or if the British government hadn't been so secretive about the Colossus machines after the war. Or if Charles Babbage had been as good an engineer as he was a designer. There are lots of what-ifs that we can play, which would change how the story stands.
There are a lot of people who could have been first, if only circumstances had been slightly different. But they weren't, and so they're going to be stuck as a footnote to ENIAC in the history books. Is this fair? Arugably not; but it's life happens. Sometimes you're there at the right time in the right place, and sometimes you're just not.
Fry: "Do refrigerators still come in boxes in the future?"
Bender: "Yeah, but the rent is atrocious."
I should have been more clear about the scenario -- I was assuming a situation where, because of either a TPM module or some other system, there was a requirement to recover the data in vivo from the computer where the drive resides.
Obviously if they can make a copy of the data by simply pulling the hard drive, then there's not much use to such a system.
Although I don't know the man, I just looked up what I think is his blog, and provided he's not lying through his teeth, the Politics and Public Policy section of his blog seems quite agreeable in spirit to me.
He also has some really interesting papers on there. (Check out the "Cocaine Auction Protocol" and "Programming Satan's Computer" -- the first is a methodology for creating an un-mediated auction house, the latter is about programming on untrusted networks.)
Of course, to each his own.
Here's the link:
http://www.cl.cam.ac.uk/~rja14/#Lib
You shouldn't take this as an authoritative answer, but I believe the answer is no.
On a FileVault-enabled system, the only things which are encrypted are the user's home folder. The default location for swap space is not in the user's folder, ergo it's not encrypted. At least via FileVault, and I can't imagine it would just be encrypted by default using some other means, because that would necessitate a big performance penalty which a lot of users wouldn't be interested in.
The way filevault works is, when you enable it, a variable-sized, encrypted disk image is created at "/Users/.(username)/(username).sparseimage". Then, on login, this image is mounted to "/Users/(username)/". On logout, it's unmounted and compacted. This is all accomplished using the hdiutil program.
The rest of the filesystem is not encrypted, so I don't imagine that swap would be.
Maybe you realize this, but the RIP bill was passed in Britain, which last time I checked, doesn't recognize the 5th Amendment (or any other) to the U.S. Constitution.
I'm not sure whether you could take the 5th in response to a request to divulge your key, in the United States. I'm not aware of any cases where it's been tried, but that doesn't mean that it hasn't happened. I think it's far more likely that they'd just avoid the whole issue and use a keystroke logger (or hidden camera, or microphone) and get at the password that way.
Worth pointing out that keyloggers are exactly the route that the FBI here in the US has taken:
http://www.epic.org/crypto/scarfo.html
That's US v. Scarfo; basically a mobster was using PGP to encrypt his communications and rather than breaking the encryption the hard way, the investigators got a warrant to install a keylogger. I'm not sure exactly how they did it, but I'm pretty certain that it was a hardware device implanted in the keyboard, rather than software. (The warrant they got was pretty much a blanket thing, approval for 'hardware, software, and firmware as necessary...') However they didn't divulge the exact methodology in the trial, because they successfully claimed an exemption under the Classified Information Procedures Act.
In addition, you'd want a system whereby you could enter a distress password, and unlock one level of security, while at the same time transparently destroying data, from the most secure level on upwards. So let's say you had three levels of encrypted data. The first layer is just some dodgy pictures of you and your wife. The second contains some emails showing you were evading taxes. The third is whatever you really want to protect.
For each level there are two passwords, one which will unlock it as normal, and another which will unlock it, and also begin a routine which will start securely erasing the third level data, then the second level, and then the first level + OS, and maybe trigger a lump of thermite sitting on top of the RAM for good measure. Or maybe it would be better just to get rid of the third level silently, so that it's as if it never existed. That's probably healthier, on second thought.
So that after you provide a good show of resisting giving out the password, you hand over the 'distress' one and let them have fun getting through the first level of junk data, while at the same time the system is slowly eating away at the stuff you really don't want, down on the third level.
You could even set it up so that the mal-effects caused by the distress passwords increase as you move through the levels of security. The distress password on the first level of security just starts the "silent erase" mechanism. The distress password on the second level speeds it up at the cost of less subtlety (because obviously they're getting closer to the actual data, so you need it gone faster). The distress password on the third level physically destroys the system in some sort of obvious (but quick) fashion. That way you're almost guaranteed not to compromise the data, but you also don't have to necessarily compromise yourself, unless they're really close to getting the stuff.
To be fair, you can also get your fix of backdoor action using Firefox or Opera.
Nothing, but in the UK it is an offence to refuse to pass encryption keys to the Police if you are requested to do so.
It would probably be so in the U.S., as well, provided you could be shown to actually know it (i.e., you could claim to have spontaneously forgotten it, the old "I have no recollection of that, Senator," defense, but I'm not sure how long it would work).
However, let's say there was something truly incriminating on the drive -- something that would have you in prison for longer than refusing to aid the investigators would -- then it might be to your advantage to just refuse to divulge the password, and live with the consecquences.
Now, what you really need is a self-destruct system, and I think this is the direction we're going to see things go in: rather than just having a single password for the system, you have two. One is the real password, which you never, ever divulge. The other is a emergency/distress password, which you divulge if you are under sufficent duress. This would, when entered, create the impression that the system had been unlocked, but would in reality display a dummy set of data, and begin immediately destroying the real set of data. In a system where the 'real' data was stored in what appeared to be free space on the 'dummy' data's drive (similar to the TrueCrypt scheme mentioned further up in the thread), and if there weren't any outside signs that the drive was being accessed/written to, then it seems quite possible to destroy all the secure data without an observer noticing. At least until it was too late.
From the Features page: I'm not entirely clear how it works, or whether the blocklist is updatable, but there is also a freeware add-on called CamiBlock which allows you to import a blocklist (so I suppose you could use Filterset.G?).
Thanks for pointing this out.
I was interested up until this point. Once you've used Adblock (or PithHelmet on Safari, a shareware tool that does effectively the same thing) you'll never, ever go back to a "stock" browser. Or at least, I never will. It's a "killer feature" if I've ever seen one.
Somebody wake me up when they get a clue and build ad blocking into the browser like they should.
Good points. I have a feeling that you're not ever going to get a convincing gunfire sound simulation from conventionally designed speakers -- that pressure wave just isn't there. Maybe you could do it with compressed air or CO2 or something.
.22s or air rifles, and I've not seen anyone with a significant flinch problem (when wearing ear protection -- I don't think anyone trains without it). With handguns it's a different story, and I suppose for non M16-based weapons systems it might be more of a concern. (I probably wouldn't want to train a new shooter on a M98k, I have to admit.)
However I do think that sound from nearby shooters is more of a problem than recoil issues, at least with rifle shooting in military situations (i.e. predominantly from the prone position, most often now with the M16 or a derivative). The recoil on the M16 is pretty negligable; I've trained a number of people on it whose previous shooting experience were
At any rate, I've found both in personal experience and working with others that it's more distracting and harder to get used to the sound of another person shooting right next to you, than it is just to deal with your own firearm in isolation; part of this might be because a rifle with a muzzle brake will be louder if it goes off next you you than in front of you. (You wouldn't think this is the case but it's quickly apparent if you've used one, there's sort of a cone right behind the muzzle that's quieter than the surrounding area.) Also, by the time you react to the noise of your own weapon, the bullet is out of the barrel, the guy next to you can fire just as your trigger is breaking and there's nothing you can do really to keep yourself from flinching involuntarily -- unless you're used to that happening and can back off and retry, you're probably going to miss where you're aiming.
Oh, we do. The U.S. sells all sorts of neat military toys to Taiwan, and we keep a nuclear aircraft carrier parked somewhere nearby most of the time.
Basically, presidents that came after Carter took less of a conciliatory attitude towards Beijing, and it goes back and forth with every new Administration; today the situation is "status quo maintanance," we give lip service to the PRC's position while at the same time selling guns to the ROC via the AIT. When Beijing starts rattling sabers too loudly, Taiwan gets a new Aegis or some Tomahawks. When we need the Chinese to stop dragging their feet in the UN Security Council on something, a few Taiwanese orders suffer "unfortunate delays."
However I think it's worth remembering who kicked off this wonderful and ongoing example of realpolitik, the next time he's criticizing another Administration for not upholding democracy or adding to his collection of peace medals.
That case was pre-DMCA. I'm not sure that the same thing would work now.
I think in order to make a Mac clone, you would almost necessarily have to break Apple's 'content protection' at some level or another (the obfuscated code, probably many other things as well). This seems to me like it would be an obvious DMCA violation.
I don't think that Compaq could do what it did to IBM, if the laws existed then as they do today. Sad commentary on our legal system, but it's the situation nonetheless.