Re: Brands excluded from digicash beta

[Nathaniel Borenstein <nsb@nsb.fv.com>]

I'm sorry that it took me so long to reply to this thread.  I've been
travelling and came back to a backlog of over 3000 messages.  (The 100
messages/day reported by the Digicash folks sounds really *pleasant* to
me right now -- I'm averaging around 350!  :-) )

Excerpts from fv: 2-Dec-94 Re: Brands excluded from di.. db@Tadpole.COM (2508*)

> 2) A group of us went over the First Virtual stuff in detail
>    last night over fajitas, and were practically rolling on 
   the floor with laughter.

I'm delighted to hear that you're so easily amused.  I hope your
merriment wasn't too disruptive to the other diners, who might have
drawn the mistaken conclusion that you were either rude, foolish, or
both.

>  Basically they have an attitude 
>    of "Crypto is too hard, people won't want to use it." So
>    instead, each transaction consists of an e-mail exchange
>    which is converted ultimately into credit card transactions

Wrong.  A First Virtual transaction takes place as a single step via
mail, FTP, or WWW.  *After* the transaction there is an email exchange
to confirm the purchase, and although this exchange works as-is with
virtually any mail reader in the world, it can be largely automated by
an FV-enhanced mail reader.  Ultimately, using such a tool you'll be
able click on a single button to confirm ALL of your recent
transactions, assuming they're all ones you want to authorize.

>    The exposure time for the merchant is on the order of _90 
>    days_. All fraud, etc., is on the head of the merchant.

You're right about the 90 days for now;  as I have stated many times,
this is an inevitable consequence of our extending the credit card
merchant system to unknown and untrusted sellers anywhere on the
Internet.  You can become an FV seller with no credit checks, and indeed
with no human intervention, so the 90 days protects us (and by extension
the community of legitimate buyers and sellers) against abusive sellers.
 As I have also stated, however, we are working on a system whereby
legitimate sellers can go through a qualification process after which
the 90 day holding period will be completely waived.  We cannot yet
announce a definite availability date for this facility, but it isn't
very far away.

>    The bottom line here is that FV has a system which is
>    much more sluggish than the DigiCash system, even though
>    it doesn't use "hard" crypto. 

Well, it doesn't use "any" crypto, hard or soft.  As to "sluggish" -- I
would point out that you can set yourself up with an account in minutes,
without human intervention, which contrasts pretty well with some of the
experiences reported on this list with other systems.  And purchases are
instantaneous.  What's sluggish?  Have you actually tried using our
system?

It is far from anonymous, 

This depends on your definition of anonymity.  In our system, a buyer
and a seller can meet and conduct business without EVER knowing each
other's identities unless they choose to reveal them.  This is trivial,
and indeed it already happens all the time on our Infohaus.  However,
First Virtual knows the real identities (or, at least, we know the real
underlying credit card, from which the real identity can be ultimately
traced), and can be forced to provide it to the government under court
order.  We will otherwise keep all such information completely private. 
I think this meets most practical standards for anonymity, and it is
certainly far more anonymous than most real-world commerce mechanisms
such as credit cards, where they buyer & seller names both appear on the
charge slip.

> and the transactions are trivially reversible. This is actually
>    a _design goal_ in their "Soylent Green", er, "Simple Green"
   proposed standard. 

I'm not sure what you're referring to here, but if you mean that it's
possible to refund someone's money, that's certainly true.  All our
accounts are in principle bidirectional, although people can choose to
have buyer-only or seller-only accounts.

Just out of curiousity, if I think of a silly name to call someone
else's commerce mechanism, will that prove anything of interest?

> It is completely inappropriate for hard
>    goods of significant value, 

As we have made clear, this was an explicit design decision.  Our terms
and conditions, which you don't seem to have read, actually FORBID the
use of our commerce engine for hard goods.  So you really don't need to
work too hard to convince us on this point.

> and its minimum transaction cost
>    is high enough to rule out its applicability for very small
>    transactions. 

Wrong again.  We explicitly permit seller-based accumulation, so there's
nothing to stop you from building a service that charges, say, a tenth
of a penny for each bit of information; however, you have to accumulate
the charges on your end until they pass our 30 cent threshhold, that's
all.  If someone buys less than 30 cents worth of stuff from you, you
have to take it as a "free sample" loss.

> Even if used for purely informational goods,
>    if an undercapitalized info service becomes popular, it will
>    sink beneath the waves while waiting for payment.

This is amazingly wrong.  First of all, consider what it means for an
info service to become popular:  It means that their server and net
connection are more highly utilized.  Neither of these is typically a
metered resource, which means the incremental costs are zero.  There's
an incremental cost involved in upgrading either of them, but if your
service is so wildly successful that you have this problem, how hard do
you think it will be for you to get a bank loan to cover an upgrade to
your computing facilities or Internet connection, which are the ONLY
incremental costs of this kind of runaway success?

It is also worth noting that in the existing credit card system, new
merchants who have only recently qualified for Visa/MC merchant status
often have a similar holding period imposed upon them by their banks. 
It's Standard Operating Procedure, that's all.  If you're setting up an
information service based on our mechanism, the cost of operation for
the first 90 days should be factored into your startup expenses, just
the way you would have to factor in the cost of inventory for a
hard-goods business.  (Indeed, for most hard goods businesses, the
inventory cost would be higher  than 90 days operating expenses.)

>    As near as I can tell, FV's technology was developed by people
>    who wanted to implement their pet philosophy about Internet 
>    commerce (customer should examine info first, then commit to 
>    paying, all transactions reversible, cryptography and anonymity 
>    are bad, secure transactions are not possible on the net, etc.),
>    rather than anything bordering on an Internet cash-like system.

Wrong again.  FV's technology was developed by people who wanted to sell
information products on the Internet.  That's the ONLY reason we did it.
 We didn't (and still don't) see any other commerce mechanism that would
meet our needs, so we built one.  We expect to make our money on
information products, not on the commerce engine.

We also don't think cryptography and anonymity are bad.  If you would
just read our materials, you will see that we think that cryptography is
problematic and that anonymity is good.  We've strived for the maximum
possible anonymity without the problems we perceive in using
cryptography.  (And FYI, we know whereof we speak: we use cryptography
heavily internally, and we are extremely aware both of its power and
utility AND of the practical difficulties in its use.)

>    So, I ask, First Virtual is looking better and better for doing
>    _what_?  Until they deal with the interface problem (get a decent
>    client, rather than relying exclusively on e-mail), I think 
>    they're not even going to be adequate for getting shareware-scale
>    proceeds from putting up a cool Web page.

Please check out our Web pages before you make any more comments like
this one.  You can buy stuff today from our Infohaus, using Web or FTP
access, or email if you prefer, so it's pretty silly to say that we rely
exclusively on email.  (Actually, the email interface is the LEAST
usable.)  The people selling things on our Infohaus -- who are NOT
associated with FV in any way other than as our customers -- get paid in
REAL MONEY.  Tell *them* that the system isn't adequate.  Or tell it to
my in-laws, who are now getting monthly loan repayments (real money)
from me via a cron job that I set up on my own machine at home  (Setting
up such a job requires no special FV intervention -- anyone who knows
how to set up a cron job can do it, it's that easy.  This stuff really
works, check it out!)

> FV may be more operational, although I'm curious if any transactions 
have managed to fully settle yet... 

We haven't been up for 90 days yet, so no funds have passed the aging
period.  I'll suggest to our PR people that they make a big deal about
the first settlement to sellers, which should happen in January...

> The two systems are worlds apart in terms of where the risk is placed.
> FV places the risk entirely on the vendor; DigiCash places the risk
> entirely on the e-cash holder. Note that lots of people walk around with
> credit cards, bills _and_ coins in their wallets, and use them for different 
> things throughout the day. I don't think that things are going to be
> that different on the net.

Hey, we agree on something!  Different mechanisms for different purposes
makes perfect sense.  This is why you won't, in general, find us
bad-mouthing any of the other systems -- we think there's room for
several payment mechanisms on the net, and don't see any purpose being
served by "taking the low road".  I'm happy to note that the folks
behind the other systems seem to be taking a similar approach.  I hope
we can all keep it up.

> I think that if people want try before you buy, it can be done
> (easily) without building it into the payment protocol. I'm 
> all for shareware, giving freebies so folks get hooked, and
> so forth, but it seems odd to build a unconditional rejection into
> the payment system, especially for products that can't be
> returned in any meaningful sense.

Of course it can be done without bundling it into the payment protocol. 
You've missed a critical point:   By "bundling" it into the payment
protocol, we have been able to achieve a vast SIMPLIFICATION of the
payment protocol.  It is not a coincidence that we are the first (and so
far, still the only) system that is operational with real money.  It's
because we set out to implement that subset of commerce that was
amenable to rapid deployment.  Try-before-you-buy permits a vastly
simplified commerce system, but nobody should be surprised if that
commerce system is ONLY useful in situations where try-before-you-buy is
acceptable!

> don't get me wrong here! I _have_ read the web pages, and I
> note that you still have to pop into your e-mail to approve the
> purchase. This is an inherent flaw to the protocol, that there 
> will be 2-3 user-side software components, instead of 1-2 with
> DigiCash:

You've read them, but you don't appear to have understood them, which is
probably our fault, not yours.  The email confirmation is indeed a bit
cumbersome if it gets invoked very often and your mail system isn't
FV-smartened.  But if you use an FV-smart mail tool -- and note that
Z-code recently became the first vendor to publicly announce and
demonstrate support for our protocols -- you can get this down to where
a single mouse click authorizes a dozen or so purchases.  Not a big
deal.  You could even have an intelligent agent do the authorization for
you in some cases, although this requires some real caution!

> I'm assuming that over time, the TCP/IP payment methods will be
> integrated into browsing software, but FV will always be hampered
> by the need to have something separate to handle the back-channel,
> since they are religiously opposed to using signatures for 
> validation (although you suggest some progress in this area).

You can already browse by Web or FTP, so "over time" == "now".

Once again, we're not OPPOSED (religiously or otherwise) to using
digital signatures, we're just opposed to making electronic commerce
wait for the widespread deployment of signature technologies.  When such
technologies are widely deployed, we'll probably use them (though this
is not a promise, it will depend on the situation at the time).

Sorry for the length of this message -- I hope it clears up a few
misconceptions.  -- Nathaniel

PS -- Doug, please tell the folks at Tadpole that your mailer is not
doing a very good job generating Message-ID headers.  In particular, it
isn't getting the domain right in the Message-ID, which can be a problem
for Message-ID uniqueness.  Specifically, instead of
<9412021548.AA17294@tadpole> it should really be
<9412021548.AA17294@tadpole.com>  It's just a nit, but these little
details do matter, and if you tell me what mail tool you're using, I
might be able to tell you how to fix it.  -- NB