From: Nathaniel Borenstein <nsb@nsb.fv.com>
"If and When" is Yes and Today. Anybody who can autosign their outgoing mail can participate in this kind of transaction already.
However, I have the impression you missed the phrase "deployed widely enough to have penetrated a meaningful portion of our market". The argument I see here is like this: "Not very many people have it, so we can't use it." Under this rule, FV shouldn't worry about support for smart front ends, because most people don't have them already. FV shouldn't try to deploy mechant software, because most people don't have it already. Now I know that you're not claiming any of these ridiculous things, that is, outside of cryptography. What I am suggesting is that FV _allow_, not require, the use of encryption. Your main concern with cryptography, it seemed, was theft of secret keys. As you agree, that concern can be disposed of. Now the reason not to use crypto rests on paucity of existing sites which use it. If FV were to _require_ crypto, there would be grounds for concern. Yet neither of us think that a crypto requirement is appropriate for the current FV mechanism. So why, then, will not FV lead for crypto rather than follow? It must not be the software integration. PGP-encrypted mail can be recognized by a regular expression and filtered if you want to preserve a single address, or even easier make another address. Raph Levien's premail will automatically encrypt mail for outgoing users, transparently. It must not be the licensing. Perfectly legal PGP can be had from Viacrypt, even for server applications as FV would need. It must not be for marketing. Offering merchants a system where the customers can undertake an effort to lower the merchants's fraud rates seems like nothing but a win. It might be for saving face. Having argued against crypto so publicly, changing positions so rapidly might be seen to look bad. So, I'm confused. What _is_ still the problem? Eric