[Standards-JIG] anti-spim techniques

Peter Saint-Andre stpeter at jabber.org
Sun Aug 28 17:28:13 UTC 2005

Ian Paterson wrote:
> Sander wrote:
>>>Has Sander (or anyone else), got some time to write a first 
>>>draft of a new generally-useful 'Bot-Proof Challenges' JEP?
>>I am afraid I need to finish exams first. I also have no 
>>experience with 
>>writing JEPs. But if I have time again and someone wants to 
>>assist me with writing the JEP, I am happy to help.
> St Peter is usually a wonderful help. :)

I'm always happy to draft another proto-JEP. I've already written three 
others so far this weekend. ;-)

>>>This could include CPU challenges and
>>>inband delivery of images
>>This might have accessibility problems as noted by someone.
> Yes. I was thinking clients could be offered a choice of challenges. For
> example, the CPU challenge would not be appropriate for Web clients.

I still see value in either a web registration technique (quite a few 
new users are thrown off by in-band registration anyway) and/or using an 
identity system like Passel <http://www.passel.org/>.

>>Maybe also the possibility to ask a random question
> I like the efficiency of this idea, but I'm not sure how practical it
> would be.
> 1. It would require a lot of questions, especially in multi-language
> cases.
> 2. Open source lists of questions would be easy for spimmers to access.
> So admins would either have to invent hundreds of their own questions,
> or somehow find a list that the professional spimmers hadn't found
> before them.

I too like the idea of questions but I think it needs to be explored 

>>>e2e encryption making SPIM far more CPU-expensive.
>>CPU time is not so expensive, and I guess the price will go 
>>down more in the future. So I am afraid this is not enough.
> Yes, this does not solve the problem. But, as you mentioned, every
> partial barrier helps to make SPIM less profitable. [And if I were a
> spimmer I would concentrate on the cheapest targets.]

They usually do.

>>The agreement should also mean that the server admin is 
>>obliged to take actions when his server is used to send spim...
> [snip]
>>So, in short, the server admin is responsible for all traffic 
>>to the public Jabber network coming from his server.
>>If he ignores the agreement, he risks loosing his "vignette"
> Yes.

My sense from public statements made by Google is that they are working 
to ensure that Google Talk is clean before connecting to the broader 
network. So it might be helpful to look at two separate problems:

1. Preventing SPIM on a standalone IM service
2. Preventing SPIM on an interconnected IM network


Peter Saint-Andre
Jabber Software Foundation

More information about the Standards mailing list