Re: properties of FV

[Andrew Lowenstern <andrew_loewenstern@il.us.swissbank.com>]

>  >  That would make this counterparty pseudonymity, not anonymity.
>  >  The merchant, while not knowing the true identity of his clients,
>  >  is still able to correlate the transactions of individual accounts
>  >  (and must be able to under FV's policies).  A malicious merchant,
>  >  for instance, could recognize that a particular account is more
>  >  interested in certain types of information and charge accordingly.
>
>  Good point.  I stand corrected, at least as far as the terminology
>  is concerned.   However, as far as the particular malicious-merchant
>  scenario is concerned, I must say I'd be skeptical about any merchant
>  who didn't tell me the price up front, *before* he asked me for my
>  account-id...  -- Nathaniel

Of course, but what if you bought something from a Web server, revealing your  
account-id to the server.  A smart server could adjust the prices on pages  
that haven't been retrieved yet.  I don't know if this is necessarily  
possible with hhtp (i.e. does your client always use the same return port  
number for requests during a given instance of the client? <bear with me, I  
don't know the real details of http>), but you get the idea.  Worse,  
linkability of transactions also allows the merchant to do 'payment traffic  
analysis' in an attempt to determine the real identities of it's clients.   
Many merchants can get together and compare transaction logs as well...

These 'attacks' are a feature of any payment system that has only counter  
party pseudonymity (as opposed to anonymity), not just First Virtual...


andrew