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

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Aug 29 19:58:35 UTC 2005

On Mon, 29 Aug 2005 20:54:27 +0200, Peter Saint-Andre <stpeter at jabber.org>  

> Tijl Houtbeckers wrote:
>> About
>> 80%  of all SPIM I ever received was in either one of these
>> (subscription  request or profile information).
> Interesting. The only spim I've ever received was through the ICQ
> gateway back when I used it (circa 2000). So I don't have enough
> first-hand experience of the problem.

Well, I occasionally still use ICQ when I need to send a file to someone  
(better NAT support I'm afraid). The reason you get the spim (a few every  
hour) in subscription requests and fake profiles is because ICQ blocks  
messages from people outside your contactlist (it can pop up a message box  
if you want to receive it if you change a setting). Some different types  
of SPIM encountered on ICQ:

- subscription request with and "advertisment" and URL in it. Not very  
effective, since you have to copy paste the URL. It's still as much a  
nuisance to the user though as any other spim.
- "normal looking" subscription request, with spim in the profile. Some  
spim is not even very obvious, just some normal data with a link for the  
"homepage" they hope you click.
- "normal looking" subscription request, with a normal profile with no  
direct or indirect spim in it.. either waits a bit and sends a message  
(hopeing the user will accept it when a popup comes), but normally waits  
for you to either accept or send a message (which means they can message  
back on ICQ) and then often, actually tries to make a "conversation" with  
you (usually just a series of messages with a delay inbetween, though more  
intelligent bots exist).
- using the "random chat friend" function. If you list yourself in the  
random chat directory, and people find you through it, they can send you a  
normal message (no blocking).
- (this is an older one I know of) Whitepages poisoning with fake  
profiles. Trying to catch searches for "normal" keywords, and no doubt the  
"naughty" keywords too.

> Perhaps it would be valuable for us to study real-life spim before we
> start jumping to conclusions and designing protocols or changing RFCs.
> I've been assuming that spim would come in <message/> stanzas from
> people outside my roster (since that is what I experienced through the
> ICQ gateway), but your experience is quite different.

Well if "spimmers" attacked today, I'm sure they'd just send messages. But  
basically when privacy lists get implemented (or a client side equavalent)  
that just blocks messages from people not in your roster (I'm sure there's  
Jabber client out there with a checkbox for this already), spimmers will  
use different tactics. They will take any chance they have to bug you, no  
matter how silly it seems.

>> It seems a lot more logical to me that the server, and then the client,
>> try to weed out spimmers without bothering the user. When it comes to
>> this  scenario, it's already too late, so it's pretty much irrelevant to
>> talk  about this in the context of of trying to prevent spim.
> If most spim comes in subscription requests and profiles, then what does
>   a server need to do in order to identify spimmers? I suppose it could
> look for malicious content in vCards / profiles. Not sure how to handle
> the subscription requests, though.

By using the techniques discussed in this thread by me and others. My  
prefered model is this.

1. A subscription request (with potential extentions that could help it)  
arrives at the server.

2. Server asseses the probability that the request is SPIM. There can be  
many ways of doing this, that are left undefined for now, besides the  
obvious (is it in the roster or whitelisted in the privacy list). These  
could include looking at the server it came from (is it trusted, does it  
have a good reputation, is it blacklisted by some etc), looking at who the  
user is (eg. is the user in the roster of any other users on this server,  
including in that of users who are in the roster of the target user, user  
reputation system, etc.), and possible sending a challenge or registration  
request etc. to sender.

3. If the "suspicion level" is over a certain threshold (configered in the  
server, and optionally per user), the request is not honoured, wether an  
error message is send back depends on wether you're a fan of silent fail  
or fast fail I suppose. If it's not, the request is forwared to the user,  
including a stanza with the "suspicion level" and maybe extentions with  
the results of tests already done.

4. the client then, preferably as transparant to the user as possible,  
runs any additional tests (did I whitelist this user, is this user in my  
email address book, is it in my keystore, is it a FOAF, (external)  
reputation system, etc.) it has that could lower the "suspicion level". If  
it's below what the client is configured for, it's shown to the user, else  
it's not shown.


- 3 is an important step. I think typically the threshold for discaring a  
request by the server should be very high (eg it's on a spimmer  
blacklist). The client after all, can have better checks (even just a  
simple whitelist!) than the server. Since the results of the work the  
server did are send along, a client can still reject a request easily.  
However there are special cases, when a server knows it's clients well  
enough to know they won't be able to do much (eg if you're running a  
server just for webclients) that the server can be more strict.

- When a server OR a client rejects a request, it should, under normal  
conditions, not discard it immidiatly or completly. There is chance the  
"suspicion level" could change over time, for example when you try and add  
me first, and I then try and add you. So at least it should keep a list of  
users that have tried to add me for a certain time period.

- I used subscription requests here, however I think the same could apply  
to messages or even IQs from contacts not in my roster. replace  
(subscription) request with "Stanza" where you like.

- The trickiest thing is how to define a "suspicion level" in a generic  
way that all clients can understand.

- Though not discussed here, what would help many of the potential  
techniques used to detect someone is a "spimmer" is a generic form of  
reporting something (that did make it through all this) is spim to your  
server or some other service. it seems logical to use XMPP for that too of  

More information about the Standards mailing list