R: R: R: [jdev] about spim techniques

[Tijl Houtbeckers]

On Sun, 28 Aug 2005 20:06:05 +0200, Peter Saint-Andre <stpeter at jabber.org>  
wrote:

> So then the key moment becomes this: when someone sends me a
> subscription request. We know it is possible for some person (or bot) to
> barrage me with multiple subscription requests, but my client should
> block all but the first of those (in fact my server shouldn't send me
> anything but the first one until I log in again, since the subscription
> state hasn't changed at all). So now I am faced with a momentous
> decision: should I add this "person" (could be a nasty bot) to my
> roster? From what I've seen, most IM client's don't do a good job of
> helping me make this decision. Several things would help:
>
> 1. Automatic vCard lookup (who *is* this person?)

SPIM in the Vcard (common technique on ICQ actually)

> 2. Google the JID (perhaps it is on some nice person's blog etc.)

SPIM in the Google search (results).

> 3. Enable me to exchange some messages with the person -- "who are
> you?", "do I know you?", "do we know someone in common?", etc.

SPIM in the answer to those questions, or am I missing something?

Everything you say here seem to come down to what you say later:
"I don't think it's my server or my client that does this -- it's me. Who  
better to figure out if the other person is
human than me? I don't think that automated bot-detection methods  
(client-based or server-based) are nearly as
effective as human-to-human communication."

Of course it's very easy for a user to spot a spimmmer.. but isn't is  
usually already too late then?


These I like better...

> Other possibilities:
>
> 4. Look the JID up in key servers or other repositories
> 5. Look the JID up in some yet-to-be-defined reputation system
> 6. Ask people in my roster whether they know this person (could be
> automated)
> 7. You ask someone whom we both know to send me a roster item exchange
> message (JEP-0144) and that person vouches for your identity to some
> extent (like an old-fashioned "letter of introduction")
> 8. You get someone whom we both know to sign your subscription request
> with his key (not very different from #5)

.. because they boil down to the same thing I said early. Automatically  
trying to establish if there is a previous trust relationship between me  
and the user trying to contact me.

I think from a technical point of view it shouldn't be too hard to define  
the mechanism for this. The logical place for a user trying to contact  
another user is to put any information about (like a link to a keystore or  
reputation server) it as an extention in the subscription or message  
packet in which it tries to do so. This will (of course) first enter the  
server which will process it. If any of the information supplied *can* be  
processed the server it will do so, then depending on it's findings and  
configuration it can either:

- accept the packet and simply forward it to the user.
- hold the packet and request more credentials from the user the message  
came from, or send a challenge, etc.
- flag the packet as suspicious and forward it to the user.
- drop the packet. (potentially send back an error, but I'm personally a  
fan of doing this silent to frustrate spimmers).

When the client receives a suspicious packet, it should first try and  
process it without the user noticing anything. If it still fails to reach  
a conclusion, it could (depending on user settings) try and involve the  
user, ideally without giving the spimmer any chance to display custom  
information.

The only "generic" protocol addition we would need is something to flag a  
packet as suspicious, and describe this procedure a little better. Maybe  
also describe some good practises that would work in the existing network  
structure (if I try to add you, and you try to add me, then it's unlikely  
one of us is a spimmer).

All suggestions made on here that could be used to do the actual verifying  
in this system can be defined seperate.