Fwd: [Google Wave APIs] Re: spam

[David Fuelling]

---------- Forwarded message ----------
From: David Fuelling <sapp...@gmail.com>
Date: Fri, Jun 5, 2009 at 4:30 PM
Subject: Re: [Google Wave APIs] Re: spam
To: google-...@googlegroups.com

Very timely post. 

I recently posted a very-draft-spec that formalizes something very close to your idea.  It's called OInvite (http://oinvite.net), and it provides a protocol for sending and receiving spam-free, cross-domain "friend requests". 

Basically, in a social-network-like system (like Wave), message spam is less of an issue because of the friend-list, which provides each user with the ability to "mute" a friend, or stop being friends with someone, thus eliminating the notion of spam (because we all "elect" to receive messages or waves from the people we receive them from, due to the friend list).

All that to say, there is still a serious spam threat at the point of "first-contact", which is where somebody you've never heard of wants to send/receive waves with you.  This is where the Hashcash idea, and Proof-of-Work (POW) in general, can be very powerful in preventing "friend request" spam.

That said, Google's own Ben Laurie has co-published a very provocative paper called "Proof of Work Proves not to Work" (http://oinvite.googlecode.com/files/ProofofWorkNoWork.pdf).  In it, the authors make a very persuasive case that POW mechanisms are not feasible in a general messaging system (like email) because in order to be effective, they harm legitimate user's ability to send/receive messages.

However, a follow-up paper (by different authors) outlines how Proof-of-Work could actually work if the "postage" was variable -- i.e., the first time a particular sender is encountered, postage is high, and later, as the sender proves his "un-spammy-ness", postage for him goes down (very similar to the idea suggested below, except postage calculation is more automatic based on your "reputation").  See here for that paper: http://oinvite.googlecode.com/files/ProofofWorkCanWorks.pdf.

Oinvite defines a way for invitation requests (i.e., friend requests) to contain a hash-cash compatible (though extended) token indicating a certain amount of postage.  I'm also working on a spec (an extension to OInvite code) that defines a way for individual user's to advertise the minimum "postage" required before they will even accept an OInvite from a user not on their friend list.

With these two pieces in place, the next step would be to setup some sort of economics system to make the OInvite Minimum Postage a variable number, based on the amount of spam a user is receiving.  If a user sets his "postage" at 20 bits, and is receiving Invitation spam, then a computer could automatically increase that user's advertised postage until the spam stops (measured by how many messages get flagged as spam).  In tandem, the computer could be updating that user's friends with increased advertised postage rates to help automatically reduce their spam, too.

All in all, the minimum postage required to get a "friend request" in front of my eyes should be controlled by me (the recipient).

Lastly, POW may not be the most effective mechanism to prevent "first-contact" spam.  So, OInvite allows for a pluggable "verification mechanism", so the community can decide what the best mechanism is.

I'd appreciate any input and participation!  The whole idea was released on Google Code about 3 days ago (ironic):  http://oinvite.net (forwards to google code).

Thanks!

David

On Fri, Jun 5, 2009 at 9:54 AM, dion <dren.dk@gmail.com> wrote:

You are absolutely correct that it's impossible to prevent every
single spam wave from hitting a victim, but the point of spam is that
it's easy and cheap to hit millions of victims, so even with a very
low conversion rate you can make a profit.

With wave you have to keep the originating server on-line and off
blacklists for the entire lifetime of the wave and it's very hard to
spoof someone, so I'd argue that spamming will be much less of a
problem to begin with, however it's entirely possible that someone
takes over a client machine via a trojan of some sort and starts
abusing that users account, so spamming could still happen.

The hijacking of a legitimate account is a real problem, but by nature
spam needs to be sent to a very large number of victims to have any
chance of turning a profit, so all that's needed to get around this
hole is to make it slightly more expensive for someone to send a wave
to someone if they have never communicated before.

I think the best solution would be to build a hashcash payment system
into the protocol and have the recipient charge the sender a fee of
say 100 ms or so of CPU time if the sender isn't already in the
recipients whitelist, that would mean that the spammer would need to
peg a CPU for an entire day to spam just 1 M people.

The best part is that all of this would be completely transparent and
unobtrusive to the user, except when they first wave someone and they
have to heat their CPU for a 0.1 second while it churns out a hashcash
payment in the background.

It should be up to the recipient how much postage to charge the
sender, that way the postage can be cranked up in sync with faster
CPUs from Intel and new releases of V8.

Please have a peek at http://www.hashcash.org/