Let's assume for a second that every website in existance used self-signed certificates.
Let's further assume Firefox stores them automatically and keeps track of them for you.
Let's also assume Firefox will give you a big red warning when one of these self-signed certificates suddenly changes.
How do you propose to start monitoring this user's internet without him/her knowing about it? Keep in mind that your man-in-the-middle attack will immediately cause several big red warnings to pop up because suddenly every website you visit has had their certificate changed (coincidence?).
Man-in-the-middle attacks are something to be wary off, but assuming you aren't ALREADY being monitored, even self-signed certificates will give you instant warning when they DO start monitoring you.
No, actually it is a normal website like any other that offers a service that makes whatever you do on that website an order of magnitude harder to monitor. If every website did this, and you stored their certificates, then you would immediately know when you were being monitored because suddenly all those HTTPS sites have had their certificates magically changed, all on the same day!
It actually is security, because assuming they're not ALREADY out to get me, I will know once they are out to get me because Firefox will warn me that the certificate changed.
That and the fact that it is an order of magnitude easier to monitor plain text communication makes any form of encryption desirable over plain HTTP.
1) Run unencrypted over HTTP 2) Run encrypted over HTTPS and a bribe to Verisign 3) Run encrypted over HTTPS using a self-signed certificate
You're saying I have only two choices. Since I'm not going to give free money to Verisign, I guess I will just offer an unencrypted service only for stupid people like you who donot understand encryption has value even without Verisign saying it is "ok".
Hard drives themselves already do extensive error correction and checksumming of all their blocks, which led me to believe that any bit errors are not from the hard drives themselves (since the checksum would fail then and it would be flagged as a read error). It's therefore extremely unlikely that a hard drive returns you data with a bit error in it, unless of course it already had this error when the block was written.
I used to have problems on an older system where copying 100 GB of data usually had atleast 1 bit error when compared to the original. Since the problem in my opinion couldn't be the hard drive I went looking for other places such bit errors could be introduced.
What I found was that the bit errors actually occured in the systems main memory. There are no checksums on disk buffers in memory and so any error there goes completely undetected. When copying 100 GB of data, there's a good chance atleast one of those bits gets flipped while in memory. Anyway, after I switched to ECC memory the problem disappeared and I haven't seen it since (and I religiously use a copy program that verifies data after the copy).
Fortunately, there's an easy way around this problem.
Instead of having just your "sensitive" data in a DFS, just use put an entire OS in there, which you can use with for example VMWare. So, you boot up your machine, type in your encryption password and end up in your safe and clean "nothing to see here" OS, with some decoy applications and VMWare. Then when you want to actually do something with your system, decrypt the DFS, start the VMWare image found there and do your normal work.
All they could prove in this case is that you use VMWare. Just make sure VMWare has no leaks pointing to the image in DFS, but that's trivial compared to cleaning up behind Vista and it's myriad of ways it keeps track of whatever you do (for your benefit usually, but not always).
I have some CD's with valuable data to sell you might be interested in. The data is also available elsewhere for free, but that doesn't reduce the values of my CD's right?
Capital I not being an option on my rm, I assume you are talking about the "interactive" mode. The problem is that rm's behaviour is ridiculous in this mode. Watch this:
[root@MyServer 0 ~]# rm -Ri MPdeletethis rm: descend into directory `MPdeletethis'? y rm: descend into directory `MPdeletethis/Gui'? y rm: descend into directory `MPdeletethis/Gui/wm'? y rm: remove regular file `MPdeletethis/Gui/wm/ws.c'? y rm: remove regular file `MPdeletethis/Gui/wm/ws.h'? y rm: remove regular file `MPdeletethis/Gui/wm/wskeys.h'? y rm: remove regular file `MPdeletethis/Gui/wm/wsmkeys.h'? y rm: remove regular file `MPdeletethis/Gui/wm/wsxdnd.c'? y rm: remove regular file `MPdeletethis/Gui/wm/wsxdnd.h'? y rm: remove directory `MPdeletethis/Gui/wm'? y rm: descend into directory `MPdeletethis/Gui/skin'? y rm: remove regular file `MPdeletethis/Gui/skin/cut.c'? y rm: remove regular file `MPdeletethis/Gui/skin/cut.h'? y rm: remove regular file `MPdeletethis/Gui/skin/font.c'? y rm: remove regular file `MPdeletethis/Gui/skin/font.h'? y rm: remove regular file `MPdeletethis/Gui/skin/skin.c'? y rm: remove regular file `MPdeletethis/Gui/skin/skin.h'? y rm: remove directory `MPdeletethis/Gui/skin'? y rm: remove regular file `MPdeletethis/Gui/interface.c'? y rm: remove regular file `MPdeletethis/Gui/interface.h'? y rm: remove regular file `MPdeletethis/Gui/Makefile'? y rm: remove regular file `MPdeletethis/Gui/bitmap.c'? y rm: remove regular file `MPdeletethis/Gui/bitmap.h'? y rm: remove regular file `MPdeletethis/Gui/app.c'? y rm: remove regular file `MPdeletethis/Gui/app.h'? y rm: remove regular file `MPdeletethis/Gui/cfg.c'? y rm: remove regular file `MPdeletethis/Gui/cfg.h'? y rm: descend into directory `MPdeletethis/Gui/win32'? y rm: remove regular file `MPdeletethis/Gui/win32/interface.c'? y ... few 1000 lines more removed...
You get the idea. Is no wonder I type -f when I want to remove a directory.
Fine, assume I'm an idiot then. No expert would ever want such a feature, or expect to be able to recover files in some way after they had made a mistake, even if that takes taking the drive offline immediately and having it perform a full disc scan.
I don't expect it to manage "deleted" files at all. It's that sinking feeling you get when you think you're deleting a directory that should be mostly empty, and rm is taking longer than expected (as your only indication that something is horribly wrong.
It's not unreasonable to expect to be able to undo that action when I immediately press cancel it and make sure the drive is not written to anymore. Ext2 can do this easily. Ext3 goes out of its way to make this impossible. XFS/ZFS/ReiserFS etc.. all make it way too hard or impossible.
I'd alias rm to something with a more sane cmdline interface, but that would break every shell script in existance.
Recycle bin solutions are crap. I want stuff to hang around for 30 minutes at most, not weeks on end taking up valuable free space causing unnecessary disk fragmentation.
Yes, I have that too, and it's useless.
Frankly, the whole command is poorly designed. I don't want to confirm each and every directory, I want an overview of what is getting deleted, and then I want it to ask me "are you sure?". It doesn't even offer an option "yes to all" when using interactive mode when you finally tire of pressing "y" 50.000 times.
I've even went looking for replacements that did just that, but that turned up nothing.
There is no way I'm installing anything Oracle on my Linux system ever. I will definitely not entrust my data to them after having witnessed over the past years what a mess their flagship product is.
That's all fine and dandy, but will it allow me to somehow undelete/recover when I accidently type rm -Rf/hugedir -- yes I know there are other ways to delete stuff, I just find it ridiculous that all linux file systems with the exception of ext2 make no effort at all to be able to recover from such a common mistake.
Of course, rm not giving any indication at all about how many bytes and files it is about to remove doesn't help either.
Since the purpose of most lossy audio compression algorithms is to make the audio as small as possible by removing as many stuff you can't hear (ie, unheard information) then the inevitable outcome is that at some point watermarks must be audible or the latest codec will strip it.
The proposed solution is DRM-free high quality tracks, where *if* you leak it onto a file-sharing site, then you can be traced. How is this a bad thing?
It's great actually!
Until of course someone that doesn't like you maliciously places a copy watermarked with your details on a P2P site, or some RIAA executive decides you are worth bringing down and spreads their own copies with your watermark. They will have to prove the copy originated from you same as always.
All lossy compressed music formats are designed in such a way to remove everything that you CAN'T hear.. that's where they get their efficiency from. You're claiming they will put it in portions you can't hear, which is the very thing these compressed formats do their best to filter out. Sure it might work currently for MP3's, as they're not as advanced, but what about AC3, Vorbis, etc.. re-encode in those and you may find your watermarks have been stripped as nobody could hear them anyway.
What a lot of people fail to realise is that encryption can be made unbreakable even by brute force by simply choosing a large enough encryption key. What people also fail to realise is that 256 bit encryption doesn't take twice as long to crack as 128 bit encryption. It in fact takes 2^128 times as long to crack.
Let's for a second assume that 128 bit encryption is crackable by your own personal home computer in a period of 1 hour.
136 bit encryption would take 2^8 times as long (250 times as long)... so we use 250 computers, and crack it in 1 hour still.
144 bit encryption takes again 250 times as long, so instead we use 250 superpowerful server computers and crack it in 1 hour.
156 bit encryption takes another 250 times longer, so we use a top-secret government super computer the size of the Pentagon and still crack it in 1 hour.
164 bit encryption takes.. you guess it, 250 times longer to crack. All the governments in the world pool their top-secret super computers and crack your content in.. 1 hour.
172 bit encryption takes 250 times longer to crack. We use all the computers on the entire planet and manage to crack it in 1 hour.
180 bit encryption takes 250 times longer to crack. We use all those computers, but let them run 250 hours (10 days) instead.
188 bit encryption takes 250 times longer to crack. We let those computers run 6 years to crack your password.
192 bit encryption takes 250 times longer to crack... never mind, we're not THAT interested in your personal photo album.
Then again, it could be a random file of garbage that looks like encrypted data (I use "looks" here with a grain of salt, since any random data COULD also be encrypted data -- there is no way to tell).
A file encrypted using a decent encryption scheme will have:
1) No identifying patterns at all that could be used to determine the encryption used
2) Looks like random garbage
In other words, they cannot even proof a file is encrypted, let alone what encryption scheme was used (having PGP installed doesn't proof anything for some other random file on your harddrive) or what the contents of that file might be if decrypted.
There's a fundamental difference. The police doesn't need your help to open doors, or even to open your safe. If you refuse to cooperate, the police can break down a door or crack a safe. You donot have to help them at all, it will just result in more damage than necessary to your property.
With encrypted files though, the police cannot get at them without your help. If you refuse to help, they cannot just "crack" the encryption (not even your equivalent of a secret service can crack it -- nobody can crack it in any reasonable amount of time, which is what scares the authorities). So realising they have no hope in hell of ever cracking a decent encryption scheme, they think they can just create a law that says your required to give up your keys. If they knew what they were dealing with, they'd realise however that such a law is complete nonsense. Since you cannot proof that a file is encrypted (since it looks like random data) you have the rather large problem that the authorities can claim any file with random garbage must be encrypted.
Nice try!
1440 * 1024 bytes = 1474560 bytes = 1.47 * 10 ^ 9 bytes.
Calling it a 1.44 MB floppy is wrong on both counts, so I don't see how it supports your argument.
2k and XP are practically the same OS in every respect, and hence switching from one to the other is hardly significant.
Donot be fooled by the new desktop background and the "skins" -- it's the same OS, just a different explorer -- practically everything that runs on 2K runs on XP and vice versa (including low level stuff like drivers). Infact, you'd have a hard time telling the difference between the two when you use the classic themes and settings in XP (XP was mainly a cosmetic explorer upgrade after all).
The step from XP to Vista cannot be compared in the slightest with the step people took by going from 2k to XP. It's not as compatible, it doesn't consume similar amounts of resources, it cannot be tweaked to look and feel like the previous version of Windows (as XP could).
On top of that, each and every OS upgrade MS has released over the decades has become more and more invasive. Instead of focusing on being a good OS and keeping as much as possible out of the user's way, each and every new version of Windows has gotten more and more annoying with stupid eye-candy defaults, annoying questions like do you want passport? do you want a tour? do you really need all those unused icons? do you want to install upgrades? and so on. I actually feel like the OS is going out of its way to not only create problems (background stuff happening I never sanctioned, automatically installing things, auto run, etc..) but also to keep the user occupied with questions and maintenance that have little relevance.
Since Vista's main focus was to get in the users way (be it with eye-candy, DRM, signed drivers, UAC, or whatever else) I sincerely doubt it will be the same experience for me as it was when I went from 2k to xp.
Ah, I see... so when you have more applicants for your university than you can accept, then you are free to treat them like lesser human beings until the point where demand lowers enough that you can meet it.
Slashdot Mirror
Let's assume for a second that every website in existance used self-signed certificates.
Let's further assume Firefox stores them automatically and keeps track of them for you.
Let's also assume Firefox will give you a big red warning when one of these self-signed certificates suddenly changes.
How do you propose to start monitoring this user's internet without him/her knowing about it? Keep in mind that your man-in-the-middle attack will immediately cause several big red warnings to pop up because suddenly every website you visit has had their certificate changed (coincidence?).
Man-in-the-middle attacks are something to be wary off, but assuming you aren't ALREADY being monitored, even self-signed certificates will give you instant warning when they DO start monitoring you.
No, actually it is a normal website like any other that offers a service that makes whatever you do on that website an order of magnitude harder to monitor. If every website did this, and you stored their certificates, then you would immediately know when you were being monitored because suddenly all those HTTPS sites have had their certificates magically changed, all on the same day!
It actually is security, because assuming they're not ALREADY out to get me, I will know once they are out to get me because Firefox will warn me that the certificate changed. That and the fact that it is an order of magnitude easier to monitor plain text communication makes any form of encryption desirable over plain HTTP.
I have three choices as a web-site owner.
1) Run unencrypted over HTTP
2) Run encrypted over HTTPS and a bribe to Verisign
3) Run encrypted over HTTPS using a self-signed certificate
You're saying I have only two choices. Since I'm not going to give free money to Verisign, I guess I will just offer an unencrypted service only for stupid people like you who donot understand encryption has value even without Verisign saying it is "ok".
About the bit errors...
Hard drives themselves already do extensive error correction and checksumming of all their blocks, which led me to believe that any bit errors are not from the hard drives themselves (since the checksum would fail then and it would be flagged as a read error). It's therefore extremely unlikely that a hard drive returns you data with a bit error in it, unless of course it already had this error when the block was written.
I used to have problems on an older system where copying 100 GB of data usually had atleast 1 bit error when compared to the original. Since the problem in my opinion couldn't be the hard drive I went looking for other places such bit errors could be introduced.
What I found was that the bit errors actually occured in the systems main memory. There are no checksums on disk buffers in memory and so any error there goes completely undetected. When copying 100 GB of data, there's a good chance atleast one of those bits gets flipped while in memory. Anyway, after I switched to ECC memory the problem disappeared and I haven't seen it since (and I religiously use a copy program that verifies data after the copy).
Fortunately, there's an easy way around this problem.
Instead of having just your "sensitive" data in a DFS, just use put an entire OS in there, which you can use with for example VMWare. So, you boot up your machine, type in your encryption password and end up in your safe and clean "nothing to see here" OS, with some decoy applications and VMWare. Then when you want to actually do something with your system, decrypt the DFS, start the VMWare image found there and do your normal work.
All they could prove in this case is that you use VMWare. Just make sure VMWare has no leaks pointing to the image in DFS, but that's trivial compared to cleaning up behind Vista and it's myriad of ways it keeps track of whatever you do (for your benefit usually, but not always).
What better place to hide your data in a system that everybody uses all the time.
I have some CD's with valuable data to sell you might be interested in. The data is also available elsewhere for free, but that doesn't reduce the values of my CD's right?
You get the idea. Is no wonder I type -f when I want to remove a directory.
Fine, assume I'm an idiot then. No expert would ever want such a feature, or expect to be able to recover files in some way after they had made a mistake, even if that takes taking the drive offline immediately and having it perform a full disc scan.
I don't expect it to manage "deleted" files at all. It's that sinking feeling you get when you think you're deleting a directory that should be mostly empty, and rm is taking longer than expected (as your only indication that something is horribly wrong.
It's not unreasonable to expect to be able to undo that action when I immediately press cancel it and make sure the drive is not written to anymore. Ext2 can do this easily. Ext3 goes out of its way to make this impossible. XFS/ZFS/ReiserFS etc.. all make it way too hard or impossible.
I'd alias rm to something with a more sane cmdline interface, but that would break every shell script in existance.
Recycle bin solutions are crap. I want stuff to hang around for 30 minutes at most, not weeks on end taking up valuable free space causing unnecessary disk fragmentation.
Yes, I have that too, and it's useless.
Frankly, the whole command is poorly designed. I don't want to confirm each and every directory, I want an overview of what is getting deleted, and then I want it to ask me "are you sure?". It doesn't even offer an option "yes to all" when using interactive mode when you finally tire of pressing "y" 50.000 times.
I've even went looking for replacements that did just that, but that turned up nothing.
There is no way I'm installing anything Oracle on my Linux system ever. I will definitely not entrust my data to them after having witnessed over the past years what a mess their flagship product is.
That's all fine and dandy, but will it allow me to somehow undelete/recover when I accidently type rm -Rf /hugedir -- yes I know there are other ways to delete stuff, I just find it ridiculous that all linux file systems with the exception of ext2 make no effort at all to be able to recover from such a common mistake.
Of course, rm not giving any indication at all about how many bytes and files it is about to remove doesn't help either.
There are ways to turn off computers that bypass "Start > Shutdown"
Since the purpose of most lossy audio compression algorithms is to make the audio as small as possible by removing as many stuff you can't hear (ie, unheard information) then the inevitable outcome is that at some point watermarks must be audible or the latest codec will strip it.
Until of course someone that doesn't like you maliciously places a copy watermarked with your details on a P2P site, or some RIAA executive decides you are worth bringing down and spreads their own copies with your watermark. They will have to prove the copy originated from you same as always.
There is just one problem.
All lossy compressed music formats are designed in such a way to remove everything that you CAN'T hear.. that's where they get their efficiency from. You're claiming they will put it in portions you can't hear, which is the very thing these compressed formats do their best to filter out. Sure it might work currently for MP3's, as they're not as advanced, but what about AC3, Vorbis, etc.. re-encode in those and you may find your watermarks have been stripped as nobody could hear them anyway.
Botnets cannot break decent encryption either.
What a lot of people fail to realise is that encryption can be made unbreakable even by brute force by simply choosing a large enough encryption key. What people also fail to realise is that 256 bit encryption doesn't take twice as long to crack as 128 bit encryption. It in fact takes 2^128 times as long to crack.
Let's for a second assume that 128 bit encryption is crackable by your own personal home computer in a period of 1 hour.
136 bit encryption would take 2^8 times as long (250 times as long)... so we use 250 computers, and crack it in 1 hour still.
144 bit encryption takes again 250 times as long, so instead we use 250 superpowerful server computers and crack it in 1 hour.
156 bit encryption takes another 250 times longer, so we use a top-secret government super computer the size of the Pentagon and still crack it in 1 hour.
164 bit encryption takes.. you guess it, 250 times longer to crack. All the governments in the world pool their top-secret super computers and crack your content in.. 1 hour.
172 bit encryption takes 250 times longer to crack. We use all the computers on the entire planet and manage to crack it in 1 hour.
180 bit encryption takes 250 times longer to crack. We use all those computers, but let them run 250 hours (10 days) instead.
188 bit encryption takes 250 times longer to crack. We let those computers run 6 years to crack your password.
192 bit encryption takes 250 times longer to crack... never mind, we're not THAT interested in your personal photo album.
A file encrypted using a decent encryption scheme will have:
1) No identifying patterns at all that could be used to determine the encryption used
2) Looks like random garbage
In other words, they cannot even proof a file is encrypted, let alone what encryption scheme was used (having PGP installed doesn't proof anything for some other random file on your harddrive) or what the contents of that file might be if decrypted.
With encrypted files though, the police cannot get at them without your help. If you refuse to help, they cannot just "crack" the encryption (not even your equivalent of a secret service can crack it -- nobody can crack it in any reasonable amount of time, which is what scares the authorities). So realising they have no hope in hell of ever cracking a decent encryption scheme, they think they can just create a law that says your required to give up your keys. If they knew what they were dealing with, they'd realise however that such a law is complete nonsense. Since you cannot proof that a file is encrypted (since it looks like random data) you have the rather large problem that the authorities can claim any file with random garbage must be encrypted.
Nice try! 1440 * 1024 bytes = 1474560 bytes = 1.47 * 10 ^ 9 bytes. Calling it a 1.44 MB floppy is wrong on both counts, so I don't see how it supports your argument.
The step from XP to Vista cannot be compared in the slightest with the step people took by going from 2k to XP. It's not as compatible, it doesn't consume similar amounts of resources, it cannot be tweaked to look and feel like the previous version of Windows (as XP could).
On top of that, each and every OS upgrade MS has released over the decades has become more and more invasive. Instead of focusing on being a good OS and keeping as much as possible out of the user's way, each and every new version of Windows has gotten more and more annoying with stupid eye-candy defaults, annoying questions like do you want passport? do you want a tour? do you really need all those unused icons? do you want to install upgrades? and so on. I actually feel like the OS is going out of its way to not only create problems (background stuff happening I never sanctioned, automatically installing things, auto run, etc..) but also to keep the user occupied with questions and maintenance that have little relevance.
Since Vista's main focus was to get in the users way (be it with eye-candy, DRM, signed drivers, UAC, or whatever else) I sincerely doubt it will be the same experience for me as it was when I went from 2k to xp.
Ah, I see... so when you have more applicants for your university than you can accept, then you are free to treat them like lesser human beings until the point where demand lowers enough that you can meet it.