I specifically quoted OPs statement about Explorer, a core Windows component, and Adobe, a popular, non-Microsoft program, and was responding to that. I don't know if various Office programs exhibit this behavior, but if they do, the people at Microsoft responsible should be blamed. But not the people at some unrelated division.

The point was that this isn't something inherent to the design of Windows. It was something that was caused by the choice of flags used by the programmers when calling the Windows API. With that said, there's a legitimate issue in renaming under Windows, caused by the operating system itself, but it doesn't involve files; it involves directories: you cannot rename a directory if a file inside that directory is open.

Oh look, I can't rename that file in Explorer until I close the file in Word (repeat for any other program and file). [...] Hell, I can't even rename a PDF file that I happen to simultaneously have open in Adobe Reader, and it's read-only!

Don't blame Windows for that. Blame the programmers who coded the app in which you opened the file. Because they are the ones who called CreateFile to open the file, and set the share mode to either 0 (which means that nobody else can open the file) or to FILE_SHARE_READ (which means others can only open the file to read its contents). If they had set the share mode to FILE_SHARE_DELETE in one API, you could delete and rename the file to your heart's content!

But I guess it's just easier to just blame Microsoft.

TNG certainly showcased a tablet like device (the "PADD") in most of the shows.

[...] the "educational" software available on linux (for free no less) is vastly more available/abundant than on windows

Even if that is true, that may not be the only concern. When your book comes with a CD and bundled apps that require Windows, the abundance of other software (free or not) on Linux doesn't help. When your school requires that a certain online-test-taking application (really, just a custom shell for an IE control) be used to access the online tests, that your Linux browser of choice can also render HTML (better than IE, even) doesn't help.

There is more to this than "let's get kids using Linux, yay!". The simple fact of the matter is Windows is used in the vast majority of desktop and so educational software written by publishers and used by school usually targets that platform. Kids have to use Windows software if their school curriculum mandates the use of materials that only run on Windows. It's no different than the situation some of us face at work, where we have to run the software that our employers require. I have to run Windows at work, because I develop software for a living and the company develops Windows software. I also have to use Outlook because that's what the IT department requires and they don't care that Thunderbird can also access the mail server too.

I don't necessarily disagree re: OpenOffice/LibreOffice/whateverit'scalledtoday. It is pretty good in saving most basic stuff in vanilla .doc although I wouldn't call it perfect. I've never used the spreadsheet and presentation apps, so I can't speak to those but let's assume that they are also good enough for the majority of school work.

The problem is that this isn't the only suite of apps that kids have to use for school work, your sisters' experience notwithstanding. Some of those apps, luckily, are done in Java, so they can work on Linux systems, but not all. A friend of mine had to deal with a number of Windows-only apps that are required for his kids schoolwork, and he eventually gave up and installed XP, rather than deal with Wine or contacting the school and the publisher. So while in your particular case and context, Linux works fine, you should be careful about extrapolating that, therefore, Linux works fine for everyone in the same context.

As for your contention that most stuff is done through a browser, online, it's true that more and more stuff is now done through browsers. That's not as great as you imagine. Do you know how many educational applications have browser version checking and how many of them actually "require" the use of IE? The reason, of course, is that they want to minimize their testing & support, and the webapp might work perfectly on your browser of choice once you tweak the browser agent string. And while you may be able to easily figure that out and do the necessary tweaks, this isn't about you. It's about a kid that has no idea about Linux, Windows and browser agent strings, or about their technically inept parents.

Does not compute... He didn't say there's NO educational software available on Linux. Only that most such software (and games) are Windows-only. Which is certainly true.

And while it may be fine to say that there are Linux alternatives for some educational apps, good luck having a kid find the Linux alternative to the particular app that comes with the book used in the class or the one which his school/teacher requires that he use. But let's say the kid does find the Linux alternative. Unless that alternative is 100% compatible with the Windows version (which the teacher is likely to use) vis-à-vis the files/output it generates then it's practically useless.

But only practically. Through the wonders of the GPL we can tell the kid to fix the app and commit the changes back to the community and everyone will be happy. Especially the kid who will make a dead-on Homer Simpson "Oh, look at me! I'm making people happy! I'm the Magical Man from Happy-Land, in a gumdrop house on Lollipop Lane!"

But that only keeps you safe if your storage media is somehow stolen. Given that the media is soldered into the phone, that's an unlikely scenario.

First of all, it is not an unlikely scenario. Why should someone bothering with getting the media when they can simply get the container of the media much more easily. Secondly, that is the only scenario where encryption helps -- your phone is stolen, or taken by police or somesuch. I would venture to say that is a very probable scenario, and from a risk analysis point of view one that must be addressed. And that's why encryption makes sense.

But if the attacker can gain access to your phone (or computer) so as to modify it and then return it for you to reuse it's game over. There's nothing that can protect against such an attack.

There is no real way of storing a password securely in an encrypted form, without requiring a password to decrypt it.

That is certainly true. But at the same time, it points to how Android (or iOS, or WP7 and so on) could implement better security. Encrypt all files (say with AES-128 for the purposes of this discussion) using a randomly generated AES key. Then encrypt that key with a password/passphrase required when the phone boots. This would ensure that data would be stored securely when at-rest, which is a step in the right direction.

Protecting the device while it's running is, of course, trickier. Clearly, the device needs to be able to securely lock itself and allow unlocking only when the proper credentials are used. A more tricky question is what happens when you plug a USB port into the device. Ideally, the system should prompt in a secure fashion, asking for authorization to enable the USB port. Furthermore, critical security-related files, such as the keychain and any encrypted data stores should only be exportable in their encrypted form.

Someone might, at this point say, "ahh! but the attacker can install some special software on the phone and it's game over!" True, an attacker can do that. He can gain access to a computer/smartphone, modify it and then return it for you to use. Frankly, there's no way to protect against that scenario, and it is not the scenario that encryption is supposed to solve. Encryption is meant to allow your data to be secure and non-accessible after the device itself is taken from you -- whether it is stolen by a thief or taken by the police during a traffic stop or during an arrest.

OK, so you store a hash. Now this means that the hash (remember, hashes are one-way -- you can't get the password back from the hash) itself must be usable to log into your account. In other words, the hash itself is a password. Password hashing is meaningful only on the server-side (by server-side, in this case, I mean whichever side of the protocol does the validation of the username/password and grants access) and not on the client side.

DriveShare is pretty nice. It's really kind of addictive to be able to access all my files from my iPhone and from any machine and to not worry about having to give Dropbox (or any Dropbox) access to it.

Nonsense. A simple, properly implemented salted hash is perfectly adequate for the vast majority of sites, provided you use large (at least 32 bit and preferably 64 bit) random salts, and a cryptographically secure hash algorithm (although I would avoid MD5).

00894983a50dc526-0e71bd5a380617a402bd24c6be3e7a7f2dd06109

This is salted password, hashed with SHA1. The salt is the part of the data before the dash. Please show me how I lost?

It might cost them some time, and possibly some money, but it wouldn't be at all impossible to rent some time on EC2 or a botnet to effectively create their own specialized rainbow table for the job.

I'm sorry, but this borders on nonsensical... Assume each user has a distinct, hopefully large (at least 32-bit and preferably 64-bit) salt, generated by a cryptographically secure PRNG and the SHA-1 algorithm for hashing. What does this mean? If Eve somehow gets a dump of the salted-hashed passwords from Alice's database, she would need to generate a unique rainbow table for each user. Sure, Eve could just target one particular user from the database -- say Bob -- explicitly and get together enough computing power to attempt to mount a brute-force attack on the salted-hash, but that's an awful lot of work to compromise one account.

So much work, in fact, that will almost certainly make an attacker choose a different attack vector. It's just an impractical attack for all but the most well-funded adversaries -- adversaries who work for three-letter government agencies that employ more mathematicians and programmers than you can count, and who run massive data centers that require their own, dedicated power plants -- and who are targeting a particular very-high-value target, we're talking about the sort of attackers who work for .

Password stretching, as you mention, is a great idea, and more people should use it. But a simple salted hash, provided the salt is large and the hash is cryptographically secure, is almost certainly good enough for the vast majority of applications.

Timothy:

Is it too cynical to mention that the US government has a vested interest in denigrating Bin Laden, and that he's no longer around to deny this claim?

It's not cynical to mention it, however, it's unclear what the US government gains by releasing this information however. The overwhelming majority of people fall into one of two categories: those who see bin Laden as a moral compass and those who see him as a terrorist thug, beyond redemption. The former won't believe the porn story and will assume it's propaganda to discredit and insult bin Laden; the latter wouldn't care about whether bin Laden liked scheiße porn.

This may be cynical of me, but I wish you'd added a "Warning: FUD story ahead, submitted by the writer of the story" disclaimer to the FUD "twitpic will sell your pics!!!!1111one!!! I HAVE DIVINED THIS FROM TEA LEAVES!" story you approved by Andy Smith.

The OP says that a practical issue is whether one should trust closed source software to do this? Because, of course, being closed source should implicitly invoke gloomy music, dark clouds and cause people to break out in a cold sweat? Seriously, enough with this bullc*** already... There's nothing inherently wrong with running closed source software, nor is a given piece of software magically better by virtue of being open-source, nor are open-source developers somehow better than those who develop closed-source software. There's legitimate arguments to be made that open-source has advantages. That open-source is, somehow, more trustworthy, isn't one such argument. And it's high time we stopped peddling it as one, or accepting it as one.

LOL... Everything is Microsoft's fault. Sure enough this must be Slashdot. Perhaps Microsoft doesn't issue patches as fast you'd like -- or as fast they could -- but that doesn't detract from the fact that Tavis' behavior in this situation was completely irresponsible.