[Standards-JIG] anti-spim techniques
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
>>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
> 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...
>>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"
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
Jabber Software Foundation
More information about the Standards