[Standards] spim, spam, spit, splogs

[Peter Saint-Andre]

It seems to me that the lack of spam on the XMPP network is not a 
testament to how smart we are, but mostly a matter of luck. (Well, it's 
a bit harder to thoroughly spam the Jabber network than the email 
network, but it's not impossible.) The scourge of spam is on its way, 
and we need to be prepared. Therefore I recently reviewed the following 
specs:

XEP-0158: Robot Challenges
           <http://www.xmpp.org/extensions/xep-0158.html>

XEP-0159: SPIM-Blocking Control
           <http://www.xmpp.org/extensions/xep-0159.html>

XEP-0161: SPIM Reporting
           <http://www.xmpp.org/extensions/xep-0161.html>

I think that wide deployment of these technologies would help us further 
discourage spam. I think they need to be supplemented by additional 
practices (see below), but I think they would help quite a bit. Here are 
some comments on the specs:

1. XEP-0158: Robot Challenges

Perhaps we could make a clearer distinction here between spam generated 
by rogue clients and rogue servers. (Rogue servers are probably easier 
to deal with, since a legitimate server could block all traffic from a 
rogue server.) I suppose there may also be a distinction between 
completely rogue accounts (created solely for the purpose of spamming) 
and legitimate accounts (or specific clients) that have been compromised 
by malware.

The terminology is a bit confusing to me in places. Instead of using the 
terms "entity" (sometimes "person") and "client", I would prefer to 
consistently use the terms "challenger" and "sender".

The security considerations need to say something about presence leaks.

The use of data forms gives us quite a bit of flexibility regarding 
challenge techniques, which is good. Perhaps we need to clearly label at 
least one technique as mandatory to implement?

2. XEP-0159: SPIM-Blocking Control

Now that privacy lists are specified in XEP-0016 again, we can work to 
integrate SPIM-blocking control and privacy lists (needs to be discussed 
but seems worthwhile). The fact that SPIM-blocking control plays well 
with privacy lists is another reason why it may not be advisable to 
proceed with block lists (see my last email).

3. XEP-0161: SPIM Reporting

I recently released a new version of this spec, but the changes were 
minor. It needs more examples to show how two (or more) servers might 
use it to coordinate responses to a spim outbreak. Given that we have a 
real-time communication technology, we should be able to "heal" from 
such an outbreak more quickly than, say, the email network can. However, 
that probably assumes the existence of some best practices and 
infrastructure regarding the self-healing mechanisms.

In particular, we may be able to use our growing network of TLS-enabled 
deployments (via the xmpp.net ICA and perhaps other ICAs) to build trust 
among server deployments and the admins thereof (the existence of 
digital certificates does not magically introduce trust where none 
existed before, but it may be one input to determining trust levels, 
plus of course it makes it harder for spammers to eavesdrop on the 
communication between those servers, which might include communication 
about which other servers are rogue servers etc.).

Ideally, server implementations would also provide ways for server 
administrators to manage which other server deployments they trust for 
sharing information about rogue servers, clients, IP addresses, etc. I 
think we need good communication about threats to our network in order 
to succeed, but we don't want a single point of failure for that 
communication (e.g., no one spammer list, but instead flexible 
communication among server deployments and admins to heal more 
dynamically -- perhaps we'd have "cells" of trusted servers that 
communicate amongst themselves).

It's not just about server developers and admins. For example, client 
developers need to give their users appropriate controls and warnings as 
well (don't accept file transfers from people not in your roster, show 
the complete URL in XHTML-IM content and warn if there seems to be a 
phishing attack involved, enable the user to turn off images, etc.).

Further, spam is not limited to one-to-one IM. Right now it's fairly 
easy to spam a MUC room (and if the conversation is archived to a web 
page, so much the better!), and we haven't addressed that yet at all. We 
need ways for MUC participants to report spam to the room or service 
(via XEP-0161?) and for the MUC service to report that spam on up the 
line as well as ban users or domains across the entire service. 
(Service-level administration is explicitly out of scope for XEP-0045 
but some kind of service-level control is needed.) Probably it's also 
possible to spam via pubsub (think splog feeds via Atom over XMPP) but I 
haven't given that much attention yet. Then there's file transfer spam 
(need server-side virus checking, XEP-0129 may help) and Jingle spam and 
who knows what else. It's a never-ending battle.

These are just some preliminary thoughts. I'm no expert on spam and 
there may be attacks I haven't thought of. But I think we need to 
develop some defenses against what I see as the inevitable outbreak of 
unwanted communication on our network. So let's get busy. :-)

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070131/b08ed4da/smime-0001.bin