kinda sad they didn't plan for spam better, since they bill wave as the second coming of email/jesus
if it takes off, spam will happen. gmail's spam filtering is really good (can't remember the last spam message that made it through to my inbox), so maybe they can borrow that from gmail.
There's a nice big spam button on each wave in the sandbox. I imagine they'll be able to handle it in a similar way that Gmail handles it, with perhaps some added functionality to handle spam at the wavelet level, control for public vs private waves, etc, etc. I don't think it's a deal killer, but it's also pretty funny to see "DON'T ADD BOTS" in huge, bold, red print in some waves.
I can understand why spam might be low (although it is interesting it has not gotten more visibility especially on the protocol group).
The Wave team has been trying to just get it work. They are not too sure of all the usecases for wave so they're in more of a discovery mode. The priorities for them is probably to get a minimum product out to users and developers then worry about spam.
From my distant view, it appears Wave mostly uses the 'buddy list' model -- you are only messaged by declared friends, or friends-of-friends (referrals via various invite/add-participant operations).
The only opportunity for spam is unwanted invitations to become a friend -- which can be a problem, but is a smaller problem than an open inbox that accepts messages from any principal.
That was my understanding as well; that it would effectively work just like GChat (where spam certainly exists, but is a trivial problem).
TFAuthor dismissed that as a non-option, because it would make Wave unsuitable for collecting unsolicited feedback and sales contacts.
But it seems to me that a single Wave account that auto-whitelisted contact attempts would solve that problem at the cost of reintroducing some capacity to spam, but at a vastly reduced level.
Simply applying existing tools and leveraging the other benefits of Wave over SMTP would seem to seriously marginalize spam as a concern.
If you have to accept me as a buddy before I can send you a wave, this will prevent spam but make it harder for wave to replace email. Incidentally, this is also why "solve this turing puzzle before I accept email from you" type of anti-spam solutions are not widely accepted.
Agreed. One way to prevent spam within Wave will be to limit its use. That could be done by explicit whitelisting and an out of band communication to get whitelisted (such as using email). Or just by limiting Wave use to people I actually know.
All unsolicited communications could come via email instead of my Wave.
One thing that works in Wave's favor is that waves are stored on the server that sent them, not the server that received them. This means that when a server (or user on a server) is disconnected for spamming, the waves they originated disappear from everyone's inbox.
How individual servers deal with malicious users and the disconnection/deletion process remains to be seen.
Also to be determined is what happens when spam content is added to a legitimate public wave. Presumably anyone else with access to that wave would have the ability to remove it (thus affecting everyone else on the wave as well) - this could be done by a bot.
I think handling spam would be pretty easy with wave, since it's ACL is deny by default (whitelist) instead of email, which is at best case a blacklist. The most I could see someone doing is flooding a user with "buddy" requests, which would be pointless because it would not actually sell anything.
For example, let's say you sign up to a website that uses wave to confirm you. You would just login, accept the request for that site to add you (thus allowing it to send future communications without this step), and that would probably be it, you shouldn't even really have to click a link or anything, since the site would be notified that you accepted it.
The solution to spam is known and implemented on every social network: it's the "add as contact" request.
Before the user can send you any information, they must send you a request containing a standardized block of information that gives you a clue to their identity. You can accept or deny the request, and only then can they contact you.
Obviously, even that block of information can itself be considered "spam", but there is only one of them and the social network has safeguards to prevent the creation of millions of accounts and millions of requests.
The way to translate that "account creation" safeguard is to whitelist not individual email addresses, but hosts -- either you trust gmail.com to have adequate safeguards that initial contact requests are unlikely to be spam, or you do (and of course, you need to build authentication to the sending address into the protocol).
It's complex to be sure, but not unapproachable, and lots of solutions already exist in the form of in-network messaging at all the various social nets.
The situation is slightly different within a social network (such as Facebook) where a single entity controls the entire experience.
Facebook controls who can sign up, the removal of users, the rate at which messages are sent, who is visible to who, etc. This is not the case for a decentralized system like Google Wave.
There's nothing stopping me from creating my own Wave server and starting to communicate with the other servers in the network. This is analogous to the situation with SMTP today where anyone can run an SMTP server and communicate with anyone else.
You can certainly whitelist known hosts such as gmail.com, but unless you are willing to ignore all non-whitelisted hosts then you will still have a problem as spammers bring on Wave servers on their botnets.
I believe the solution to the spam problem was announced at some point. Basically, to send waves you must have an SSL certificate for your wave server. I'm not sure whether these can be self-signed, but if not this surely would be a great solution to the problem that spam has become. (I love self-signed certificates for websites as a lower-level security mechanism, but non-self-signed certs are nearly flawless for identifying who an individual is and who is accountable for that site, or in this case wave.)
15 comments
[ 2.6 ms ] story [ 53.1 ms ] threadif it takes off, spam will happen. gmail's spam filtering is really good (can't remember the last spam message that made it through to my inbox), so maybe they can borrow that from gmail.
The Wave team has been trying to just get it work. They are not too sure of all the usecases for wave so they're in more of a discovery mode. The priorities for them is probably to get a minimum product out to users and developers then worry about spam.
The only opportunity for spam is unwanted invitations to become a friend -- which can be a problem, but is a smaller problem than an open inbox that accepts messages from any principal.
Am I way wrong?
TFAuthor dismissed that as a non-option, because it would make Wave unsuitable for collecting unsolicited feedback and sales contacts.
But it seems to me that a single Wave account that auto-whitelisted contact attempts would solve that problem at the cost of reintroducing some capacity to spam, but at a vastly reduced level.
Simply applying existing tools and leveraging the other benefits of Wave over SMTP would seem to seriously marginalize spam as a concern.
All unsolicited communications could come via email instead of my Wave.
How individual servers deal with malicious users and the disconnection/deletion process remains to be seen.
Also to be determined is what happens when spam content is added to a legitimate public wave. Presumably anyone else with access to that wave would have the ability to remove it (thus affecting everyone else on the wave as well) - this could be done by a bot.
For example, let's say you sign up to a website that uses wave to confirm you. You would just login, accept the request for that site to add you (thus allowing it to send future communications without this step), and that would probably be it, you shouldn't even really have to click a link or anything, since the site would be notified that you accepted it.
Before the user can send you any information, they must send you a request containing a standardized block of information that gives you a clue to their identity. You can accept or deny the request, and only then can they contact you.
Obviously, even that block of information can itself be considered "spam", but there is only one of them and the social network has safeguards to prevent the creation of millions of accounts and millions of requests.
The way to translate that "account creation" safeguard is to whitelist not individual email addresses, but hosts -- either you trust gmail.com to have adequate safeguards that initial contact requests are unlikely to be spam, or you do (and of course, you need to build authentication to the sending address into the protocol).
It's complex to be sure, but not unapproachable, and lots of solutions already exist in the form of in-network messaging at all the various social nets.
Facebook controls who can sign up, the removal of users, the rate at which messages are sent, who is visible to who, etc. This is not the case for a decentralized system like Google Wave.
There's nothing stopping me from creating my own Wave server and starting to communicate with the other servers in the network. This is analogous to the situation with SMTP today where anyone can run an SMTP server and communicate with anyone else.
You can certainly whitelist known hosts such as gmail.com, but unless you are willing to ignore all non-whitelisted hosts then you will still have a problem as spammers bring on Wave servers on their botnets.