[jdev] Re: [Standards-JIG] anti-spim techniques

Sander Devrieze s.devrieze at pandora.be
Sun Aug 28 07:44:45 CDT 2005


Op zondag 28 augustus 2005 12:46, schreef Ian Paterson:
<snip>

> 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.

> This could include 
> inband delivery of images

This might have accessibility problems as noted by someone.

> and CPU challenges (e.g. find a string where 
> the least significant bits of the hash have a specific value).

Maybe also the possibility to ask a random question (the server admin then can 
fill a database with multiple-choice questions) during in-band registration?

> The first application of that new 'building block' protocol could be
> another new JEP that either extends or replaces JEP-0077 (In-Band
> Registration).

<snip>

> Once enough clients implement e2e encryption then people could insist
> that all correspondants use it, 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.

<snip>

> As Sander mentioned, the JSF-approved certificate agreement should
> legally disallow SPIM and provide tough penalty clauses for clear
> abuses. (These agreements would probably need to be drawn up under the
> laws of countries that are not friendly to spammers.)

The agreement should also mean that the server admin is obliged to take 
actions when his server is used to send spim. A few things he can do:
* contacting the spimmer(s) on his server,
* blocking that spimmer(s),
* spim filtering for all outgoing trafic on s2s,
* disable registration and/or s2s connections until he fixed the problem,
* take legal actions against the spimmer on his server,
* ask advice from the Jabber community to solve the problem,
* report a leak in one of the protocols if that is causing the problem,
* etc.

So, in short, the server admin is responsible for all trafic to the public 
Jabber network coming from his server. If he ignores the agreement, he risks 
to loose his "vignette" (the certificate) to drive on the public Jabber 
network.

<snip>

-- 
Mvg, Sander Devrieze.

xmpp:sander at devrieze.dyndns.org ( http://jabber.tk/ )



More information about the JDev mailing list