NODE be0e02b3microcurrency: Netscape vs. Microsoft
"Vladimir Z. Nuri" <vznuri@netcom.com>Sat, 18 Jan 1997 13:05:22 -0800 (PST)
it seems that microcurrency has still not hit the "big time"
yet. or perhaps some people see otherwise. what is the evidence
for how far it has penetrated ala DigiCash etc? I haven't seen
much myself.
I predict that microcurrency will not catch on in a big way
until it is integrated with browsers, and when it is, it
will be adopted in an insanely large rush like the way
the web itself caught on with the GUI (and was mostly comatose
before it).
I'd like to have seen microcurrency catch on like a brushfire
at this point, and was trying to figure out why it hadn't,
and focused on the above key aspect.
hence, I wonder:
WHO WILL BE THE FIRST TO INCORPORATE A MICROCURRENCY
FEATURE IN THEIR BROWSER, MICROSOFT OR NETSCAPE?
why am I shouting? because I hope that we can create
a buzz around this question, to the point that both
manufacturers begin to realize how much is at stake
in this single little feature. I'd like to see speculation
and articles about it in the trade press. let it turn
into a hot topic of conversation..
do either MS or Netsacpe have plans to
do so right now? I suspect the future of the browser
wars will belong to he who does the microcurrency feature.
here's how it might work: the browser has an internal
piggyback that can be filled up with cash. it has various
features that prohibit a charge of greater than some
fixed limit of being made, per time, per site etc... also
in no case can more money than is currently in the piggy
bank be charged. once the charge hits, there is no
contesting allowed, because the charge is so low. a little
bar on the user interface could indicate how much cash
is left.
the idea would also be to invent some new html tags that
indicate the charge on a link. the charge is incurred when
1/2 of the page is sent (there would be all kinds of hacks
in which people could retrieve only part of a page to avoid
the charge, hence this limit or some variation thereof).
so when I move my mouse over a link in the browser, I see
not only its address as with Netscape's, but also some
charge that will incur when I hit it. there could be color
coding and little graphics for costs also.
notice how much crypto really caught on when Netscape
incorporated it, and how this action alone did more for
the proliferation of crypto in cyberspace, almost, than
all prior efforts combined. I think that microcurrency
will be unleashed in a very similar way.
the system I describe above can be built up pretty easily
from existing technology such as DigiCash. pretty much
all the major ingredients are available.. it's just a matter
of time before some enterprising programmers plug it all
together in an easy to use way. (as far as I know the
Digicash software is not easily integrated with any browser,
am I correct?)
by framing the question as I have above, the question is
no longer "how should microcurrency be implemented", or
"should it be", but "who will be the first to do it?",
a nice competitive incentive to the key companies involved.
so, Netscape, Microsoft, are either of you listening? do you
have any idea how much is riding on this option? are you
working on it right now? if not, are you prepared to face
the consequences? has anyone heard any rumors about their
intention to implement microcurrency?
I've long predicted some pretty revolutionary strides
in cyberspace that will make all development up to now
look pretty sickly and pale, when microcurrency is invented
and brought into a trivial-to-use GUI. in a sense it is the
the economic system that the whole industry (or even the
whole world) has been waiting for ever since its beginning.
it will unleash a torrent of frenzied innovation and reorganization
beyond what anyone has ever seen or thought possible.
p.s. has anyone done a plugin that handles cash in the way
I am referring to? this may be a really neat way for
third-party developers to cash in on this, but I suspect
that it's so crucial that the browser manufacturers will
eventually incorporate it themselves.
NODE 917e287bRe: microcurrency: Netscape vs. Microsoft
Alan <alano@teleport.com>Sat, 18 Jan 1997 15:04:02 -0800 (PST)
On Sat, 18 Jan 1997, Vladimir Z. Nuri wrote:
> it seems that microcurrency has still not hit the "big time"
> yet. or perhaps some people see otherwise. what is the evidence
> for how far it has penetrated ala DigiCash etc? I haven't seen
> much myself.
>
> I predict that microcurrency will not catch on in a big way
> until it is integrated with browsers, and when it is, it
> will be adopted in an insanely large rush like the way
> the web itself caught on with the GUI (and was mostly comatose
> before it).
It will also not catch on until there are better standards involving
microcurrency transactions amongst the vendors. It would also help if
there was a single interface (or "helper app") for whatever vendor you
decided to go with.
Currently every vendor of payment schemes has made it proprietary in some
way. (At least the ones I have seen.) This means that if the user visits
three different web pages, each using a payment scheme from a different
vendor, that user has to be signed up with all of those vendors. (Or at
least have their helper apps.)
I will not even go into the hastles of trying to set it up from the server
side. (The last payment scheme I installed (cybercash) was not very well
documented. The documentation on the web site contradicted the software
with the tar file. (And both were wrong at some point.)) Until these
payment schemes are easier to deal with for the web page provider, they
will not catch on. (There will also need to be more support for Internet
service providers with multiple vendors all on different payment schemes.)
Until there is a single standard hammered out, micropayments will still be
few and far between.
NODE 65495bc7Re: microcurrency: Netscape vs. Microsoft
"Vladimir Z. Nuri" <vznuri@netcom.com>Mon, 20 Jan 1997 11:48:15 -0800 (PST)
[microcurrency]
>It will also not catch on until there are better standards involving
>microcurrency transactions amongst the vendors. It would also help if
>there was a single interface (or "helper app") for whatever vendor you
>decided to go with.
as I see it, I think there are a few key standards that need
to be devised:
1. an html tag that indicates how much a link costs, probably in
the <a href="" cost=xx> type syntax
2. modification of http to support a payment mechanism, by sending
a token.
3. browser "piggy bank".
there are other standards, such as how a person might get
cash into their piggy bank etc., but most would be related to
the above items.
notice that we don't really need a good interoperable standard
to begin with. often Netscape and MS invent tags that are not
interoperable between them, and later standardization arrives
at a consensus / convergence. as I see it, I think the browser
manufacturers should just pick their favorite digital cash
scheme (cybercash, digicash, whatever) that is easiest to
implement, and do so, with the intention of integrating other
schemes at a later date.
>Currently every vendor of payment schemes has made it proprietary in some
>way. (At least the ones I have seen.) This means that if the user visits
>three different web pages, each using a payment scheme from a different
>vendor, that user has to be signed up with all of those vendors. (Or at
>least have their helper apps.)
hence, a good opportunity for the browser manufacturer to remove
all these additional complications and make it point-and-click
simple. I agree, this is not going to be a total nonbrainer. but
better the browser manufacturer do it for their software, allowing
everyone who uses it to benefit, than every single cash user
in cyberspace trying to replicate the same difficult series of
steps to get their cash going.
>I will not even go into the hastles of trying to set it up from the server
>side. (The last payment scheme I installed (cybercash) was not very well
>documented. The documentation on the web site contradicted the software
>with the tar file. (And both were wrong at some point.)) Until these
>payment schemes are easier to deal with for the web page provider, they
>will not catch on. (There will also need to be more support for Internet
>service providers with multiple vendors all on different payment schemes.)
>
>Until there is a single standard hammered out, micropayments will still be
>few and far between.
generally, that's what I'm calling for, some ad hoc standards being
put into place immediately by the browser manufacturers, in the
same way new tags are always being invented. standardization generally
results *after* an initial, minimally constrained innovation phase, imho.
NODE 5655d385Re: microcurrency: Netscape vs. Microsoft
Bill Stewart <stewarts@ix.netcom.com>Sun, 26 Jan 1997 11:54:12 -0800 (PST)
At 01:05 PM 1/18/97 -0800, Vladimir Z. Nuri wrote:
>I predict that microcurrency will not catch on in a big way
>until it is integrated with browsers, and when it is, it
.....
>the idea would also be to invent some new html tags that
>indicate the charge on a link. the charge is incurred when
.....
>of time before some enterprising programmers plug it all
>together in an easy to use way. (as far as I know the
>Digicash software is not easily integrated with any browser,
>am I correct?)
The Digicash software wasn't terribly easy to integrate with _anything_,
but folks like Lucky Green have been banging on them to define and
release their interface specs, and there's a library called -lucre
that will do the Digicash functions. A few months ago, Ian
demonstrated a Digicash-compatible plugin at one of our Bay Area
cypherpunks meetings (with blinding removed for patent reasons.)
I don't know about BorgBrowser, but with Netscape, you can implement
non-built-in features as either a plug-in or as a helper application;
no need to mess with the HTML spec in yet another browser-specific manner.
You can also wedge things in using cookies (though their are non-cookie-aware
browsers and people who turn their browsers off) which could work well for
lower-security microcurrencies. For instance, connecting to
http://newspaper.com/cookie-store.html could take your credit card with SSL
and give you a cookie with 100 or 1000 credits using some S/Key-like
mechanism,
and each time you read a news page it would decrement by one. To avoid
fraud (people resetting their cookie files) the newspaper would have to
track cookie use, but they may be tracking who's reading what anyway.
# Thanks; Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
# (If this is a mailing list, please Cc: me on replies. Thanks.)