It's actually not. Master Password doesn't do any encryption of passwords. It doesn't store anything. It just takes a master password, does some clever hashing seeded by a site name, and calculates a password for the site from the result. Meaning all you need to reproduce your passwords is your master password and a program that can execute the algorithm.
The biggest issue I have with all of these solutions, 1Password, LastPass, KeePass, the OS X Keychain, browsers storing passwords, et al, is that they basically just all store all of your passwords in their own custom ways, often on remote stores beyond your control, while leaving you with the mess of creating the passwords and keeping them "in-sync" between all of your devices. What if you're not behind your laptop? How do you log into your email?
Thought I'd mention Master Password which aims to address this issue by letting you remember a single master password (which you already do for each of these solutions anyway) and then calculating your password for a given site from it. The algorithm is completely offline, uses no inputs other than those remembered by the user and others documented by the algorithm, and the output will pass most any of those pesky "password policies".
It basically means all you need is a calculator and your password to get access to any of your sites. And if you loose your device, no data lost and you've got your identity back just by picking up any other device.
The actual app is currently in beta and only for iOS, but the algorithm is fully documented for anyone to reproduce and a Mac version is already planned.
That's exactly why I said "Nobody's claiming that free software will cure politicians of their idiocy or prevent it." Free software gives you transparency and options. It doesn't force anybody else's hand (even if it's to *not* censor content).
Nobody's claiming that free software will cure politicians of their idiocy or prevent it. What the article is claiming is that under a world running exclusively on free software, or at least one with plentiful free alternatives, at least I'd be able to buy electronics that won't police me and turn me in under the strict regulations forced upon me by my government.
When you buy a knife, you know what it does and what it's capable of. When you buy a house, you can look in every nook and cranny of it, you can see how it's built and what it's built of. You can modify it however you like. When you buy software, or any non-free electronic equipment, you've bought a black box. It advertises features, but it's capable of so much more. What it really does behind the scenes is completely unknown to anyone but perhaps a security researcher.
Buying a computer is like voting for a politician: The features are as advertised, but the agenda is largely unknown to you; and they'll both do much that you didn't bargin for.
The article is trying to say: If we force free software on our electronics, we basically make them on equal standing with the house example. You can now look at the source, inspect it for all it's worth. Modify it however you like. That is Stallman's dream, and to tell you the truth: It won't kill the economy. It will just be a different economy and we'll all be better off for it.
Whether they have is largely irrelevant to the point the article is trying to make. What matters is, is it guaranteed that they won't? No, it's not. Thank the lack of a clear definition for terrorism for that. The point being that if you want to be able to trust your computers to not turn you over to your government for something you personally wouldn't see as terrorism but they might, then you need your computers to run free software so you can at least see what it's been programmed to do.
Why do we have these CAs around? A completely decentralized system that has no system of control whatsoever. All you need is for some company to manage to somehow convince some browser venders that they have good security policies. And with that, everybody around the world is basically forced to follow in that "trust". How fucked up is that anyway.
At the same time, the whole thing is so tightly coupled with DNS already. The common name has to be the domain name. So why the heck are these CAs separate from that? At least DNS has a control body. CAs have nobody but the browser vendors; and they don't report to them.
I say dump the current CA trust model. Make all DNS root servers a CA, let them issue CA certificates to their registrars, and let the registrars issue certificates to their customers, and only for those domains that their customers have registered under them. Publish the certificates in the domain's DNS records. Make ICANN compose strict rules that all registrars must obey, just like they already do before they allow registrars to service TLDs. And punish violations by revoking the registrar's certificate. Install all DNS root certificates in all OSes, and force those OSes to keep a local OCSP cache that is no older than a few minutes at any given time.
What are we doing fucking around with trusting arbitrary companies that survive on charging exuberant amounts of money to do openssl commands, and have no form of oversight whatsoever?
You'd be a bad script writer for using #!/bin/bash. Most OSes (outside of Linux) won't have bash under/bin/. All the *BSDs will be/usr/local/bin/bash. Sadly, I haven't seen a consistent location for env (/bin or/usr/bin ?) either, so you're at best 50/50 there.
I've found env is most commonly found in/usr/bin/env and as such #!/usr/bin/env bash is a fair attempt at a constant hashbang, but as you've indicated yourself; if you really need to write a script and deploy it to random target OS'es, you'll probably want to customize the hashbang for each to point at wherever you've got or decided to put bash in it. It's not such a major undertaking.
My point in short, changing the hash bang in a script is trivial. Replacing all bash'isms is NOT. "Porting" to a system with only ksh, perhaps where bash won't compile, can be trivial, or a nightmare, all for the sake of a few features that are just as easy to use in a more compatible way, rather than the bash way...
Writing bash code by using often broken pure-POSIX equivalent solutions just because it'll mean you'll have it easier in a few years from now if you were silly enough to consider changing the language of your script to POSIX without rewriting it is going to give you bad bash code now and bad POSIX code later. If your needs require you deploying to targets where bash is really unavailable (it rarely happens that you can't even install it), then either write specific code for those targets in ksh (or heck, perl?) or suffer restricting yourself to POSIX. In the latter case, use/bin/sh as your hashbang. Changing a hashbang from bash to something else is always silly: Either you made the wrong choice of language initially and you should rewrite your code for the new language or you made the wrong choice of hashbang initially and you should never have put a bash hashbang in your POSIX-code. Writing C++ code in a C way because maybe you'll decide to switch back to C at some point is equally dim.
printf to ed, nested inside a find, awkwardly escaped, incidentally with poor performance (one file at a time)
The FAQ does its best to offer all the alternatives. This is indeed a convoluted method, but there is no portable alternative. GNU sed comes with a -i and BSD sed comes with a -i, both work differently, and neither is "standard" (and indeed, neither handle symlinked files well), ed is. I'm not sure what you're implying here, but if you were trying to make a case for sed's -i, it would utterly defeat your case for portable shell code in bash scripts. Non-interactively editing files is a difficult thing to do right, even more so if you want it to be "standard" or portable. You can't get a simple one-liner for everything. In this particular case, it would be better to iterate find's results with a while read loop and do non-escaped ed'ing inside, IMHO.
Or perhaps see the recommendation to "never, ever use seq". Even though "sed -w" will automatically give you the right number of leading zeros
Your shell can do math just fine, no, you really shouldn't be forking for it. And you really shouldn't be putting leading zeros in your variables: your data should always be pure and normal. You can format it appropriately when you use it (eg. with printf).
Frankly, if you think you need bash'isms to write reliable shell scripts, you need to expand your horizons greatly
What would you recommend? Your own arguments defeat ksh for the same reason they defeat bash, which leaves only POSIX sh, and no, you cannot write resilient code in POSIX sh, unless it involves no more than simple delegation. To be resilient in POSIX sh you need to abuse positional parameters for arrays or do nasty and convoluted eval hacks to basically write your own shell features. Thanks, but no thanks.
The Bash FAQ/Guide/Sheet are indeed, and perhaps unsurprisingly, bash-specific. They do not deal as much with "Shell scripting" as they deal with "Bash scripting". I find that a good thing. You hear people talk about "shell scripting" all the time, as though all shells behave in the same way when scripted. There is a unifying feature-set among POSIX shells, but this feature-set is so limited that it can suffice for nobody in writing decent shell scripts (no, if you need to rely on word-splitting to do your lists, you can't write a decent script). Most people really don't even have a clue about any of this and put their bashisms in.sh scripts which they commonly invoke with the sh interpreter because "it works" on their system that has/bin/sh symlinked to/bin/bash. And they think they know "shell scripting". Let's not get into (t)csh, zsh et al.
There are many shells that one can choose from and use, many with less and many with more features than bash (not to say worse and better). In the end, a great many systems come with a recent version of Bash which makes it ideally suited for general use (just because sh really isn't a reliable and decent alternative). If you use bash in your hashbangs, at least you know that you can use arrays, glob pattern matching in [[ and more. With sh you don't even know if you're talking to a POSIX shell or an old Bourne-like one. And while ksh (and dare I say, zsh) may be equally good if not better alternatives at times, the fact that they're not as widely available leaves them interesting but not my first choice, and not the choice I would recommend people invest time to learn.
On the matter of "standard equivalent that works as well", when your hashbang is/bin/bash, you'd be silly to break your script's consistency and go for a "portable" solution (whose portability is broken by your hashbang) whose bash-equivalent has nothing but advantages.
On the matter of "recommending the most complex of all possible options", sometimes doing things correctly and supporting all the edge cases is indeed more complex than supporting only filenames that contain no spaces or glob characters. But you know what, a huge amount of people that read this information every single day doesn't know or think about pathname expansion or wordsplitting during unquoted expansions and all those pitfalls. You really shouldn't recommend the "simpler" solution that falls victim to bugs caused by expected input data, just because it'll make your inside voice cry when your pipeline doesn't fit on your 80 column terminal (you probably shouldn't be pipelining it then anyway). Your code should do what it's supposed to do *regardless* of what the input data is or might become (and that's the prime principle that tends to make bash code only moderately more complex, but usually not at all).
"It's not perfect" is an understatement. Firstly, it is a key learning resource for a lot of beginners and more knowledgeable users. That means it has a certain responsibility: To be correct.
Bash is a very lax interpreter, most sh's more so. As a result, they allow you to do a lot of stuff you really, *really* shouldn't be doing, and your test cases will make you think that doing it that way actually "works". Combine that with teaching sloppy practices and you naturally get bad results: People don't know what quoting really is and how crucially necessary it is. People don't pay attention to separating data from code which means most scripts are very vulnerable to arbitrary code execution, but more importantly, bugs such as receiving unexpected data can have devastatingly destructive results, and you might not even notice. Most people don't even understand what the difference is between running "bash" and running "sh" (while I'm sure more understand the similar difference between C and C++).
The ABS is very popular. A lot of people read it and learn from it. The problem is that the code in its examples have terrible practices, important key details are not explained, let alone in sufficient detail, and beginners learning from this will not notice until they shoot themselves in the foot (and will end up blaming bash for it). The resources I enumerated are actively monitored by very knowledgeable people. They are extensive, detailed, clear and useful. But above all, they are correct.
I've just had a look through the book via Amazon's Look Inside.
I simply cannot fathom how so many authors manage to get a book published on a subject they don't even master properly. "Shell scripting" is by far the worst in this category. So much that I recommend anyone to run screaming in the other direction when you see mention of "shell scripting" in any title. If it mentions "Linux", it's usually also an excellent indicator of junk. Not to take away from the beauty of the Linux kernel (which obviously has nothing at all to do with shell scripting, but let's ignore that fact).
I obviously haven't read the book, but when I skim through it and I see failure to quote parameters, failure to recognize the difference between executing a script with/bin/bash in the hashbang and running it by passing it as an argument to sh, and more, I know for a fact that I'm going to be sitting in #bash trying to re-educate poor misguided souls for as long as I can suffer it.
To those interested in the subject: Do not read this book. Do not read this "Advanced Bash Scripting Guide" mentioned in this review. You will end up writing junk. Go see Greg Wooledge's wiki, it's got an extensive FAQ of actually useful issues (http://mywiki.wooledge.org/BashFAQ), it's got a great newbie guide (http://mywiki.wooledge.org/BashGuide), it's got a great cheat sheet (http://mywiki.wooledge.org/BashSheet), and much more. Best of all: Unlike that broken ABS, they're all community supported and unlike this book, the knowledge is free.
Ignoring the copyright issues involved, you seem to think that torrent tracker and seed availability are somehow more reliable than DRM-free corporate-backed cloud solutions.
Exactly why they are putting fingerprint readers on these devices now (more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive).
Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on "drivers" asking you for a pin code on your computer.
My point was that your email address is not your password or the answer to your secret question. It is not your credit card number or the code to your safe.
It is contact information that people can find out if they want to, simply because that's the very purpose of it.
Spammer crawlers aren't going to bother with reversing the MD5 of your email address.
And if you're trying to hide your contact information from other people, you failed when you started using it for signing up at gravatar-esque services in the first place.
Email addresses are usernames. They are not secret information. If somebody can be bothered enough to find your email address through brute-forcing the MD5 hash of it; you've got bigger problems.
Far more than "10% of stackoverflow.com's users" can have their email addresses GUESSED far faster. Likely your email address is also FAR easier to establish through a simple Google search on your pseudonyms.
If you for some odd reason want your email address to be secret; for the same name as wanting a secret pseudonym or using a false name when signing up; register a fake email address instead (and set it up for forwarding). You're giving your email address in clear text to the site's owner and all the internet hops inbetween him and you ANYWAY.
It's important to learn to distinguish between what is a secret and what is not; and if you want to make things secret, at what level you should put your trust.
Sure; because we all know the web is static and never changes.
1. The web is growing at an exponential rate. 2. The existing part of the web must be rechecked every so often for updates.
The result; an ever-increasing demand for data processing. Smarter algorithms for what to crawl and how to process the resulting data is definitely a necessity to keep on top of things.
That's not nearly as much thanks to web designers and developers taking non-IE browsers into account as it is thanks to Mozilla taking IE behaviour into account and accomodating for that in their own software, AFAIK.
And in truth, web designers with a clue still need to limit their options too much in order to remain IE-compatible. As soon as IE goes below 20%, at least we can finally justify not giving a crap about what our designs look like in IE, put up a warning message saying "Get a browser that supports web standards." and be done with it.
Slashdot Mirror
It's actually not. Master Password doesn't do any encryption of passwords. It doesn't store anything. It just takes a master password, does some clever hashing seeded by a site name, and calculates a password for the site from the result. Meaning all you need to reproduce your passwords is your master password and a program that can execute the algorithm.
The biggest issue I have with all of these solutions, 1Password, LastPass, KeePass, the OS X Keychain, browsers storing passwords, et al, is that they basically just all store all of your passwords in their own custom ways, often on remote stores beyond your control, while leaving you with the mess of creating the passwords and keeping them "in-sync" between all of your devices. What if you're not behind your laptop? How do you log into your email?
Thought I'd mention Master Password which aims to address this issue by letting you remember a single master password (which you already do for each of these solutions anyway) and then calculating your password for a given site from it. The algorithm is completely offline, uses no inputs other than those remembered by the user and others documented by the algorithm, and the output will pass most any of those pesky "password policies".
It basically means all you need is a calculator and your password to get access to any of your sites. And if you loose your device, no data lost and you've got your identity back just by picking up any other device.
The actual app is currently in beta and only for iOS, but the algorithm is fully documented for anyone to reproduce and a Mac version is already planned.
That's exactly why I said "Nobody's claiming that free software will cure politicians of their idiocy or prevent it."
Free software gives you transparency and options. It doesn't force anybody else's hand (even if it's to *not* censor content).
Nobody's claiming that free software will cure politicians of their idiocy or prevent it. What the article is claiming is that under a world running exclusively on free software, or at least one with plentiful free alternatives, at least I'd be able to buy electronics that won't police me and turn me in under the strict regulations forced upon me by my government.
When you buy a knife, you know what it does and what it's capable of. When you buy a house, you can look in every nook and cranny of it, you can see how it's built and what it's built of. You can modify it however you like. When you buy software, or any non-free electronic equipment, you've bought a black box. It advertises features, but it's capable of so much more. What it really does behind the scenes is completely unknown to anyone but perhaps a security researcher.
Buying a computer is like voting for a politician: The features are as advertised, but the agenda is largely unknown to you; and they'll both do much that you didn't bargin for.
The article is trying to say: If we force free software on our electronics, we basically make them on equal standing with the house example. You can now look at the source, inspect it for all it's worth. Modify it however you like. That is Stallman's dream, and to tell you the truth: It won't kill the economy. It will just be a different economy and we'll all be better off for it.
Whether they have is largely irrelevant to the point the article is trying to make. What matters is, is it guaranteed that they won't? No, it's not. Thank the lack of a clear definition for terrorism for that. The point being that if you want to be able to trust your computers to not turn you over to your government for something you personally wouldn't see as terrorism but they might, then you need your computers to run free software so you can at least see what it's been programmed to do.
Showing chicks fondling a monitor isn't an illegal or misleading marketing practice. Misinformation is.
The first inventor would have prior art if he's actually doing something with that invention. If not, who cares?
Why do we have these CAs around? A completely decentralized system that has no system of control whatsoever. All you need is for some company to manage to somehow convince some browser venders that they have good security policies. And with that, everybody around the world is basically forced to follow in that "trust". How fucked up is that anyway.
At the same time, the whole thing is so tightly coupled with DNS already. The common name has to be the domain name. So why the heck are these CAs separate from that? At least DNS has a control body. CAs have nobody but the browser vendors; and they don't report to them.
I say dump the current CA trust model. Make all DNS root servers a CA, let them issue CA certificates to their registrars, and let the registrars issue certificates to their customers, and only for those domains that their customers have registered under them. Publish the certificates in the domain's DNS records. Make ICANN compose strict rules that all registrars must obey, just like they already do before they allow registrars to service TLDs. And punish violations by revoking the registrar's certificate. Install all DNS root certificates in all OSes, and force those OSes to keep a local OCSP cache that is no older than a few minutes at any given time.
What are we doing fucking around with trusting arbitrary companies that survive on charging exuberant amounts of money to do openssl commands, and have no form of oversight whatsoever?
You'd be a bad script writer for using #!/bin/bash. Most OSes (outside of Linux) won't have bash under /bin/. All the *BSDs will be /usr/local/bin/bash. Sadly, I haven't seen a consistent location for env (/bin or /usr/bin ?) either, so you're at best 50/50 there.
I've found env is most commonly found in /usr/bin/env and as such #!/usr/bin/env bash is a fair attempt at a constant hashbang, but as you've indicated yourself; if you really need to write a script and deploy it to random target OS'es, you'll probably want to customize the hashbang for each to point at wherever you've got or decided to put bash in it. It's not such a major undertaking.
My point in short, changing the hash bang in a script is trivial. Replacing all bash'isms is NOT. "Porting" to a system with only ksh, perhaps where bash won't compile, can be trivial, or a nightmare, all for the sake of a few features that are just as easy to use in a more compatible way, rather than the bash way...
Writing bash code by using often broken pure-POSIX equivalent solutions just because it'll mean you'll have it easier in a few years from now if you were silly enough to consider changing the language of your script to POSIX without rewriting it is going to give you bad bash code now and bad POSIX code later. If your needs require you deploying to targets where bash is really unavailable (it rarely happens that you can't even install it), then either write specific code for those targets in ksh (or heck, perl?) or suffer restricting yourself to POSIX. In the latter case, use /bin/sh as your hashbang. Changing a hashbang from bash to something else is always silly: Either you made the wrong choice of language initially and you should rewrite your code for the new language or you made the wrong choice of hashbang initially and you should never have put a bash hashbang in your POSIX-code. Writing C++ code in a C way because maybe you'll decide to switch back to C at some point is equally dim.
printf to ed, nested inside a find, awkwardly escaped, incidentally with poor performance (one file at a time)
The FAQ does its best to offer all the alternatives. This is indeed a convoluted method, but there is no portable alternative. GNU sed comes with a -i and BSD sed comes with a -i, both work differently, and neither is "standard" (and indeed, neither handle symlinked files well), ed is. I'm not sure what you're implying here, but if you were trying to make a case for sed's -i, it would utterly defeat your case for portable shell code in bash scripts. Non-interactively editing files is a difficult thing to do right, even more so if you want it to be "standard" or portable. You can't get a simple one-liner for everything. In this particular case, it would be better to iterate find's results with a while read loop and do non-escaped ed'ing inside, IMHO.
Or perhaps see the recommendation to "never, ever use seq". Even though "sed -w" will automatically give you the right number of leading zeros
Your shell can do math just fine, no, you really shouldn't be forking for it. And you really shouldn't be putting leading zeros in your variables: your data should always be pure and normal. You can format it appropriately when you use it (eg. with printf).
Frankly, if you think you need bash'isms to write reliable shell scripts, you need to expand your horizons greatly
What would you recommend? Your own arguments defeat ksh for the same reason they defeat bash, which leaves only POSIX sh, and no, you cannot write resilient code in POSIX sh, unless it involves no more than simple delegation. To be resilient in POSIX sh you need to abuse positional parameters for arrays or do nasty and convoluted eval hacks to basically write your own shell features. Thanks, but no thanks.
The Bash FAQ/Guide/Sheet are indeed, and perhaps unsurprisingly, bash-specific. They do not deal as much with "Shell scripting" as they deal with "Bash scripting". I find that a good thing. You hear people talk about "shell scripting" all the time, as though all shells behave in the same way when scripted. There is a unifying feature-set among POSIX shells, but this feature-set is so limited that it can suffice for nobody in writing decent shell scripts (no, if you need to rely on word-splitting to do your lists, you can't write a decent script). Most people really don't even have a clue about any of this and put their bashisms in .sh scripts which they commonly invoke with the sh interpreter because "it works" on their system that has /bin/sh symlinked to /bin/bash. And they think they know "shell scripting". Let's not get into (t)csh, zsh et al.
There are many shells that one can choose from and use, many with less and many with more features than bash (not to say worse and better). In the end, a great many systems come with a recent version of Bash which makes it ideally suited for general use (just because sh really isn't a reliable and decent alternative). If you use bash in your hashbangs, at least you know that you can use arrays, glob pattern matching in [[ and more. With sh you don't even know if you're talking to a POSIX shell or an old Bourne-like one. And while ksh (and dare I say, zsh) may be equally good if not better alternatives at times, the fact that they're not as widely available leaves them interesting but not my first choice, and not the choice I would recommend people invest time to learn.
On the matter of "standard equivalent that works as well", when your hashbang is /bin/bash, you'd be silly to break your script's consistency and go for a "portable" solution (whose portability is broken by your hashbang) whose bash-equivalent has nothing but advantages.
On the matter of "recommending the most complex of all possible options", sometimes doing things correctly and supporting all the edge cases is indeed more complex than supporting only filenames that contain no spaces or glob characters. But you know what, a huge amount of people that read this information every single day doesn't know or think about pathname expansion or wordsplitting during unquoted expansions and all those pitfalls. You really shouldn't recommend the "simpler" solution that falls victim to bugs caused by expected input data, just because it'll make your inside voice cry when your pipeline doesn't fit on your 80 column terminal (you probably shouldn't be pipelining it then anyway). Your code should do what it's supposed to do *regardless* of what the input data is or might become (and that's the prime principle that tends to make bash code only moderately more complex, but usually not at all).
"It's not perfect" is an understatement. Firstly, it is a key learning resource for a lot of beginners and more knowledgeable users. That means it has a certain responsibility: To be correct.
Bash is a very lax interpreter, most sh's more so. As a result, they allow you to do a lot of stuff you really, *really* shouldn't be doing, and your test cases will make you think that doing it that way actually "works". Combine that with teaching sloppy practices and you naturally get bad results: People don't know what quoting really is and how crucially necessary it is. People don't pay attention to separating data from code which means most scripts are very vulnerable to arbitrary code execution, but more importantly, bugs such as receiving unexpected data can have devastatingly destructive results, and you might not even notice. Most people don't even understand what the difference is between running "bash" and running "sh" (while I'm sure more understand the similar difference between C and C++).
The ABS is very popular. A lot of people read it and learn from it. The problem is that the code in its examples have terrible practices, important key details are not explained, let alone in sufficient detail, and beginners learning from this will not notice until they shoot themselves in the foot (and will end up blaming bash for it). The resources I enumerated are actively monitored by very knowledgeable people. They are extensive, detailed, clear and useful. But above all, they are correct.
I've just had a look through the book via Amazon's Look Inside.
I simply cannot fathom how so many authors manage to get a book published on a subject they don't even master properly. "Shell scripting" is by far the worst in this category. So much that I recommend anyone to run screaming in the other direction when you see mention of "shell scripting" in any title. If it mentions "Linux", it's usually also an excellent indicator of junk. Not to take away from the beauty of the Linux kernel (which obviously has nothing at all to do with shell scripting, but let's ignore that fact).
I obviously haven't read the book, but when I skim through it and I see failure to quote parameters, failure to recognize the difference between executing a script with /bin/bash in the hashbang and running it by passing it as an argument to sh, and more, I know for a fact that I'm going to be sitting in #bash trying to re-educate poor misguided souls for as long as I can suffer it.
To those interested in the subject: Do not read this book. Do not read this "Advanced Bash Scripting Guide" mentioned in this review. You will end up writing junk.
Go see Greg Wooledge's wiki, it's got an extensive FAQ of actually useful issues (http://mywiki.wooledge.org/BashFAQ), it's got a great newbie guide (http://mywiki.wooledge.org/BashGuide), it's got a great cheat sheet (http://mywiki.wooledge.org/BashSheet), and much more. Best of all: Unlike that broken ABS, they're all community supported and unlike this book, the knowledge is free.
Ignoring the copyright issues involved, you seem to think that torrent tracker and seed availability are somehow more reliable than DRM-free corporate-backed cloud solutions.
So how exactly do you get the judge to answer these questions? Because I'd sure like to see it.
Give parent a voice; mod up.
Exactly why they are putting fingerprint readers on these devices now (more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive).
Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on "drivers" asking you for a pin code on your computer.
My point was that your email address is not your password or the answer to your secret question.
It is not your credit card number or the code to your safe.
It is contact information that people can find out if they want to, simply because that's the very purpose of it.
Spammer crawlers aren't going to bother with reversing the MD5 of your email address.
And if you're trying to hide your contact information from other people, you failed when you started using it for signing up at gravatar-esque services in the first place.
Email addresses are usernames. They are not secret information. If somebody can be bothered enough to find your email address through brute-forcing the MD5 hash of it; you've got bigger problems.
Far more than "10% of stackoverflow.com's users" can have their email addresses GUESSED far faster. Likely your email address is also FAR easier to establish through a simple Google search on your pseudonyms.
If you for some odd reason want your email address to be secret; for the same name as wanting a secret pseudonym or using a false name when signing up; register a fake email address instead (and set it up for forwarding). You're giving your email address in clear text to the site's owner and all the internet hops inbetween him and you ANYWAY.
It's important to learn to distinguish between what is a secret and what is not; and if you want to make things secret, at what level you should put your trust.
RFID tags are not security devices, they are hyped barcodes. They do not provide any authentication.
If you're worrying about your RFID tags being cloned for a malicious purpose, you are using them for the wrong thing.
http://en.wiktionary.org/wiki/American
Get off of your high horse.
Sure; because we all know the web is static and never changes.
1. The web is growing at an exponential rate.
2. The existing part of the web must be rechecked every so often for updates.
The result; an ever-increasing demand for data processing. Smarter algorithms for what to crawl and how to process the resulting data is definitely a necessity to keep on top of things.
Almost as never ending as the flow of programmers that don't bother to learn the intricacies of their language.
That's not nearly as much thanks to web designers and developers taking non-IE browsers into account as it is thanks to Mozilla taking IE behaviour into account and accomodating for that in their own software, AFAIK.
And in truth, web designers with a clue still need to limit their options too much in order to remain IE-compatible. As soon as IE goes below 20%, at least we can finally justify not giving a crap about what our designs look like in IE, put up a warning message saying "Get a browser that supports web standards." and be done with it.
http://wooledge.org:8000/FtpMustDie