To be fair, it's not a "truly free market" that requires perfect knowledge, but closer to an efficient market requirement (strict form).

I've been cultivating the idea that it's not "free markets" that we need now as much as "competitive markets". Free markets seem good for personal freedom, and can lead to competitive markets. Competitive markets, on the other hand, are what drive an economy to grow. In the US, we seem to have a good amount of "free markets", and need to focus more on the "competitive" aspects.

In terms of what's best for an individual country, we want to pursue institutions that that strengthen "free" or "competitive". Arguments that are against regulations because they are "anti-free" need to also take into account the competition-advocating parts.

Thanks for the link and information; it's good to know that they're doing throttling in a more intelligent manner. You originally said that Comcast's throttling caused them to "get their hand slapped". Were you trying to get across that this "hand slapping" was done during the TCP RST injection era, or during the QoS modification era?

I was under the impression they were injecting TCP RST packets, not throttling. Big difference.

UN resolutions made clear the onus was on Iraq to prove they got rid of their weapons.

You don't have to trust the client-side hashing function, as ordinarily you're not expecting it to be implemented on top of ordinary security. It's simply a bonus level of security a site can provide, even in the case of SSL transport, in case the receiver is compromised. In other words, it's possible that one component of the authentication process that handles the client-side-generated string (either a hash or cleartext password) is compromised, but not the authentication prompter itself. In this sort of case, there are clear benefits to client-side hashing.

I should note that I'm not limiting my discussion to webpage-style authentication. If the protocol enforces hashing on the client-side before sending, you don't have to worry about trusting the client-side or javascript being disabled.

What you say is true, but one benefit of doing an MD5 before it's sent is that one can't infer other passwords from a MD5 hash. A person might use passwords that follow a similar pattern that can be deduced by looking at cleartext, but not from hashes. For example, passwords a person might use could be "mypassword@slashdot", and "mypassword@sourceforge", one could probably guess their Facebook password.

Added salt helps even further.

The conclusion is that the authenticator should never receive the client's plaintext password in any form; it should always be one-way transformed before it leaves the client.

Are there automatic safety mechanisms that could be designed to limit damage? Just using my imagination, but a model could be designed to automatically halt the propeller (or do something else) when too close to the ground unless the plane was specifically in takeoff or landing mode.

And why do you think it needs to be a bigger part of your life ?

This is what you are asking for when you demand taxes be raised.

Increasing tax revenue so we can pay down debt does not imply a larger government. Don't make ridiculous implications; it embarrasses us other Americans.

Could be they're using a high-quality ROT13 password-mangler and just reversing the operation for the customer service staff. That way they get the benefit of both worlds, no cleartext passwords and the ability to help customers recover their passwords.

I think one easy way to address these problems is to stop talking about absolute levels of income, but rather percentiles of income. Everyone could get a mailing from the IRS describing where they are on the income scale, and knowledge of this may help create more productive conversations.