[Standards] spim, spam, spit, splogs
stpeter at jabber.org
Wed Jan 31 22:57:39 UTC 2007
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
XEP-0158: Robot Challenges
XEP-0159: SPIM-Blocking Control
XEP-0161: SPIM Reporting
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
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. :-)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards