On Sun, 28 Aug 2005 20:06:05 +0200, Peter Saint-Andre <[EMAIL PROTECTED]>
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.
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
