[messaging] payment as spam deterrence [Re: Spam-resistance of different systems]

[Daniel Kahn Gillmor]

On 09/23/2014 04:15 PM, Trevor Perrin wrote:
>  Pay-per-message seems complicated, and would add
> tremendous overhead and change the UX of email (2).

I'm not sure it's worth taking pay-per-message off the table entirely,
though i'm wary of connecting it with the global monetary system, which
already has pretty strong biases about who gets to communicate with whom.

I do agree that it sounds complicated, but this is a complicated problem
space.


I think the aspects of a spam-combatting pay-per-mail system would be:

 A) some sort of time-limited micropayment system ("this check is good
for K days")

 B) widely-known default: sender-pays-receiver (no middleman) some small
amount

 C) easy way to configure the "paymail" client to accept mail from a
given peer without requiring payment.

 D) clear mechanism to indicate to sender "rejected for lack of payment"

This provides for a few sensible workflows:

 0) meetup in person -- both people exchange info to autoconfig their
clients to permit future communications without payment

 1) introduction e-mails -- like the "polite" approach, this just says
"here's a nickel for you in the hopes you'll read my message".  The
recipient can keep the nickel no matter what, but if they want to keep
corresponding, they can also return the nickel directly with a note
"i've just permitted you to send me mail gratis".  No one ends up poorer
than before, but the initiator risks the nickel.

 2) mailing list signups have a couple of interesting options for this,
depending on whether messages that come through the mailing list are
just relayed or re-written to come from the list itself. -- people who
want to receive mail from a particular sender can agree to do so, and
can also drop their subscription client-side just by rejecting mails for
lack of payment.

The main issues here are the same as the issues around global
reputation: privacy concerns.  If the payment scheme is something
bitcoin-like, you're essentially publishing the social graph of who has
initiated conversation with who, and whose e-mail addresses are the most
active.  Maybe zerocash [0] would help avoid this kind of leakage?

We can't just say "every new paymail account starts with N payments"
because then spammers would just create tons of new accounts.  but maybe
a mail service that started up could do some initial investment to grant
to their users when they sign up, which their users could repay to the
service's pool as they received spammy invitations.


There are UX changes here, of course, but I'm not convinced that they're
particularly large -- the user would need to know how much payment
they'd attach to an outbound e-mail and how much an incoming e-mail
carried.  they'd need to be able to easily take some of the standard
actions ("keep payment", "return payment", "allow sender gratis
delivery"), but these could be bound to actions like "add to addressbook".


anyway, this isn't anything close to a solved problem, and i'm not even
sure i like the result.  but i'm not sure that throwing out payment as a
mechanism makes sense if the goal is to come up with a spam-deterring
system.

	--dkg

[0] http://zerocash-project.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140923/d24ddd4e/attachment.sig>