[Standards-JIG] privacy2 anti-SPIM proto-JEP

Ian Paterson ian.paterson at clientside.co.uk
Wed Aug 31 03:57:38 UTC 2005

> For one is that we're bothering the user with a problem
> of the system, the (sending) users has to do more effort
> so we can detriment spammers.

People are only bothered, at most, the very first time they send a
message to a correspondent. I expect this will be much less than once
per day for Aunt Tillie (most people).

> Google (which has spurred the sudden development of 
> anti-spam proposals) isn't really helped with a 
> challenge/response system. They don't need the JSF
> for that, they can implement this on their own if they
> want. They'll need no help whatsoever from the rest of the 
> Jabber network if they want to reduce spam in this way.

If we want clients to be compatible with servers then it is better that
we standardize, don't you think? ;)

> I don't have the idea that we need to design and implement
> an anti-SPIM system in 2 weeks time to please Google.

We're not doing this for Google. If we don't put a good standard in
place soon then, as you pointed out, Google will probably invent
something themselves (or worse, opt for a closed federation). Then, even
if the proprietary protocol is bad and does harm, we will probably all
end up implementing it (e.g. Apple's vCard avatars).

IMHO the collective experience of the JSF community paying attention to
the wider issues is likely to produce better protocols. We need to
encourage the talented engineers at Google, Apple et al to join in. :)

> It's annoying when you want to add some kind of bot.

I don't think there is an issue here. The proposed measures should not
affect 'solicited' bots at all. Adding a bot typically involves sending
it a message or subscribing to its presence. So the bot is one of your
'correspondents' and will never be challenged.

> It doesn't work (well) with blind people and not all
> clients can show images. Text challenges can be 
> confusing and they have severe l18n issues.

The proposed bot challenges protocol offers people/clients an extensible
choice of methods:

> Before closing down the XMPP network in such a
> rigorous way...

I think we've got to keep this measure in perspective. The proposal is
far less constraining than others we have been discussing (e.g.
preventing people sending messages unless they are on the receiver's

Nobody on your roster, or hosted by servers you trust, will *ever* have
to respond to a challenge to send a message to you.

Individuals will be in complete control. If this will be as intrusive as
you fear, then it would be considered anti-social to require bot
challenges, and the clients will default to switching bot challenges
off. In fact, since SPIM is not a real problem on the XMPP network
today, I sincerely hope clients disable bot challenges by default (i.e.
don't add them to their privacy lists). Perhaps for a while at least,
the mere existence of 'bot challenge' implementations will act as a
deterrent to SPIMers, and we won't need to actually use them?

SPIM has the potential to interrupt people's lives far more than SPAM
does. So, once XMPP SPIM does emerge, IMHO responding to a challenge
once per day will be a minor price to pay for such an *effective*
anti-SPIM measure.

> please, let's think this through properly and see what
> other options we have available

I completely agree with you. The two proposed JEPs should go a long way
to discouraging SPIM. But other interesting techniques have been
suggested and are worth pursuing in parallel, especially since they
typically *complement* the existing proposals. :)

- Ian

More information about the Standards mailing list