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

[Ian Paterson]

> > So you see my server generating the challenge and validating the 
> > response?
> > 
> > I think servers should operate the same rules for subscription 
> > requests and messages. i.e. I shouldn't even see the subscription 
> > request until the other user has passed my server's Bot-Proof 
> > Challenge.
> 
> 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?

Are you saying that message triggered challenges should be handled by
the server, but subscription request challenges should be handled by the
user?

If so, then SPIM bots will concentrate on sending subscription requests
instead of messages. Of course users won't want to be bothered with
these bot requests. So why not allow the server to filter out the bots -
and then allow the user to filter out the unwanted humans using the
techniques you described? (Especially since the server will already have
the challenge functionality in place.)

> I don't think that automated bot-detection methods
> (client-based or server-based) are nearly as effective
> as human-to-human communication.

Yes. But the point is that humans don't want the job of filtering out
bots themselves. Most people hate manually filtering out the SPAM from
their email inbox.

The cost to users of responding to an occasional Bot-Proof Challenge is
small, and perfectly acceptable, when they compare it to the countless
bot-generated messages/requests they would otherwise have to filter
every day.


> > My server should remember which users have passed my anti-SPIM test 
> > *and which users I have sent stanzas to*.
>
> Well, my client could simply update my privacy lists once I click the 
> big "allow communications with this person until further notice"
button.

Yes, but, simple clients etc.


> > RFC 3921 Privacy lists aren't really designed to block presence 
> > stanzas that are subscription requests (and allow all other
presence 
> > stanzas through).
> 
> RFC 3921 enables you to block all communication from another JID, so 
> your first sentence is not accurate.

I'm not sure you understood what I was trying to say. I meant that RFC
3921 cannot, for example, be used to block <presence type='subscribe'/>
while allowing through <presence type='subscribed'/> from the same user.


> Sure thing, we've talked about that before on one of these 
> lists. I'll work on a proto-JEP for that soon.

Thank you :)

- Ian