No free spam
Ben Laurie
>
> Ben responded to me thus:
>
> > > This takes care reasonably well of peer to peer e-mail (I think), and
> can be
> > > easily deployed (any volunteers? I'll be very glad to provide our system
> for
> > > this !).
> >
> > Sure. Is it something I can actually deploy (without everyone else in
> > the world also deploying it)?
>
> You can certainly deploy our system, as well as several others, e.g. one
> response mentioned correctly MojoNation (of course there are plenty of
> reasons to choose ours :-).
>
> I was puzzled by your saying `without everyone else in the world also
> deploying it`. I thought you meant that you are concerned that others will
> use it, making your deployment redundant or not commercial etc. Now when
> writing this to you I realize I stupidly misunderstood you. What you meant,
> I'm quite sure now, if that you are concerned that if you implement such a
> payment solutions others will not be able to mail you since they don't have
> it. Now that's a very valid concern and I also thought for a long time it
> may be a show stopper.
Actually, I was more concerned with the other side of the coin: that
insufficient people will adopt it to make it worth doing, and that it is
hard to find ways to give people an incentive to start using it.
> But now I actually think it could work. Let me explain how. The key is the
> belief that micropayment systems MUST emerge - and be interoperable. That is
> a payer with account at one Payment Service Provider (PSP) should be able to
> pay anybody with account at any PSP. That's certainly our goal - our system
> has this property and we plan to work closely with any other vendor which
> will want to have this property to ensure interoperability.
>
> Assuming this, the problem is only the bootstapping phase, before everybody
> has accounts in interoperable PSPs. But in that phase when the system is not
> yet so widely used, it will be sufficient to force the sender to simply do
> some manual process - such as enter a web site to open a demo account and
> pay. That's clearly something achievable with our system or others. If it
> becomes popular, spammers may develop automated tools to do so as well, but
> that will buy them very little as at that point the system will be popular
> enough to move to real payments.
>
> BTW, I've been thinking of payments as the answer to spamming already for
> many years, and in fact it was one of my motivations for working on
> micropayments (from which our broader
> payment platform emerged). There are others who thought of it long ago, in
> particular Kevin Mccurly (see
> http://www.almaden.ibm.com/cs/k53/pmail/tsld001.htm).
I actually favour Adam Back's hashcash scheme for this particular
problem, even though I'm as keen as you are to see micropayments succeed
for other things.
This is particularly related to the incentive problem - I think it will
be difficult to persuade people to voluntarily adopt a system that is
likely to make what is now free cost money. Hashcash has the advantage
that it costs nothing (in practice) but still has the property of making
spam uneconomic (which, when you think about it, is a very cool trick).
In fact, in a conversation just now with Russ Nelson, I came up with
what I think is probably the best idea I've had yet on how to get this
scheme off the ground - what we do is get people to run hashcash on
their mail servers, and prioritise mail that arrives properly paid for -
also, autorespond periodically (in the style of vacation) to those who
do _not_ use hashcash urging them to start and pointing them at the
appropriate patches for the major mailer apps (of course, the endgame is
to get the major apps to include the patches by default). When it gets
popular enough, we just throw the switch and start bouncing mail that
has no hashcash. I even thought of a name for this scheme - CAMRAM (the
CAMpaign for ReAl Mail[1]).
I really think this could work, so I'm prepared to spend time on it -
who's in? (mail me privately)
> Another BTW, the other application I really want micropayments for (and was
> my first motivation to this if I recall correctly) is also crypto-related...
> it is to motivate people to produce reviews of products, services, and esp.
> other reviewers - creating a huge `web` (or directed graph) of credentials.
> If these are signed, and identify the reviewed entity by its public key,
> these credentials are certificates. Using such a collection of many
> credentials is what I believe will be the ultimate solution to public key
> infrastructure - and this is another area I'm very interested in (and worked
> on).
I hear what you are saying, but I really don't see how this produces the
ultimate solution to PKI - unless you envisage the huge web boiling down
to a few very large players that I subcontract my ID requirements to. In
which case, I'm not keen.
Cheers,
Ben.
[1] That's a joke, based on CAMRA, the CAMpaign for Real Ale.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
jam...@echeque.com
Amir Herzberg wrote:
> > Another BTW, the other application I really want
> > micropayments for (and was my first motivation to this if I
> > recall correctly) is also crypto-related... it is to motivate
> > people to produce reviews of products, services, and esp.
> > other reviewers - creating a huge `web` (or directed graph)
> > of credentials. If these are signed, and identify the
> > reviewed entity by its public key, these credentials are
> > certificates. Using such a collection of many credentials is
> > what I believe will be the ultimate solution to public key
> > infrastructure - and this is another area I'm very interested
> > in (and worked on).
On 15 May 2001, at 11:18, Ben Laurie wrote:
> I hear what you are saying, but I really don't see how this
> produces the ultimate solution to PKI - unless you envisage the
> huge web boiling down to a few very large players that I
> subcontract my ID requirements to.
I interpreted Amir' Herzberg's plan as the Crypto Kong approach to
credentials (www.echeque.com/Kong). If you have a bunch of
readily accessible signed documents floating around on the web,
you can determine the authenticity of any signed instrument by
comparing the signature on one document to other signatures by
that person, in those few cases where you actually are concerned
about authenticity.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
FSh3JsxGO/ISZ/OiAkn29Erti6+7wKjzboho0gmn
4p6Fw8yJjYaxm3NyY3I9XTqMFfzo19cCT2d5j6MVg
Steve Schear
> > my first motivation to this if I recall correctly) is also
> crypto-related...
> > it is to motivate people to produce reviews of products, services, and esp.
> > other reviewers - creating a huge `web` (or directed graph) of credentials.
> > If these are signed, and identify the reviewed entity by its public key,
> > these credentials are certificates. Using such a collection of many
> > credentials is what I believe will be the ultimate solution to public key
> > infrastructure - and this is another area I'm very interested in (and
> worked
> > on).
>
>ultimate solution to PKI - unless you envisage the huge web boiling down
>which case, I'm not keen.
>
>Cheers,
>
>Ben.
>
>[1] That's a joke, based on CAMRA, the CAMpaign for Real Ale.
Many, including myself, have beaten the HashCash drum as a solution to
spam. I'm still a believer and would like to help kickstart something.
Wouter Slegers
> I actually favour Adam Back's hashcash scheme for this particular
> problem, even though I'm as keen as you are to see micropayments succeed
> for other things.
CAMRAM-"protocol" (as hashcash is vendor neutral and has no other "cost"
then CPU-cycles) and allow additional payment methods to be defined.
I see no reason why we should exclude micropayment systems such as
NewGenPay's or Mojonation's et al or even payments in CPU for say
SETI@HOME ("to deliver this message promptly, you need to see aliens").
> I even thought of a name for this scheme - CAMRAM (the CAMpaign for
> ReAl Mail[1]).
> I really think this could work, so I'm prepared to spend time on it -
> who's in? (mail me privately)
I'm in. Feel free to mail me off-list.
> > Another BTW, the other application I really want micropayments for (and was
> > my first motivation to this if I recall correctly) is also crypto-related...
> > it is to motivate people to produce reviews of products, services, and esp.
> > other reviewers - creating a huge `web` (or directed graph) of credentials.
> > If these are signed, and identify the reviewed entity by its public key,
> > these credentials are certificates. Using such a collection of many
> > credentials is what I believe will be the ultimate solution to public key
> > infrastructure - and this is another area I'm very interested in (and worked
> > on).
Sounds awfully like an application for KeyNote BTW.
> I hear what you are saying, but I really don't see how this produces the
> ultimate solution to PKI - unless you envisage the huge web boiling down
> to a few very large players that I subcontract my ID requirements to. In
> which case, I'm not keen.
As I see it, the reason the current PKI-market is dominated by a few
heavy hitters is for the largest part because their root keys are
already included with the applications, so the users have zero effort in
using them (and a non-zero effort for adding others). Therefor all paths
of trust start at these root keys and their owners.
If you set up a new `web of credentials` and want to prevent this, you
should make sure that the users are pushed to making an explicit choice
in their starting point for the path of trust. One way would be to make
the default that all trust starts at the user's (or his companies) key.
In any case it should be made very clear that the starting point of your
trust is crucial in security and that outsourcing this to a big company
is in no way needed (if you want, you can always certify them) and
always gives you less control.
With kind regards,
Wouter Slegers
Your Creative Solutions