[Standards-JIG] privacy2 anti-SPIM proto-JEP
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:
>> 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