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

[Ian Paterson]

Hi,

I just posted on this subject to the Standards-JIG list because IMHO we
need new JEPs.

- Ian


> -----Original Message-----
> From: jdev-bounces at jabber.org 
> [mailto:jdev-bounces at jabber.org] On Behalf Of Ian Paterson
> Sent: 28 August 2005 11:40
> To: 'Jabber software development list'
> Subject: [jdev] [Standards-JIG] anti-spim techniques
> 
> 
> Ensuring SPIM will not be worthwhile, even with a network of 
> 'zombie' client or server machines, clearly needs multiple 
> measures. IMHO we need to move forward ASAP with some of the 
> good ideas that Tijl, Sander and others were putting forward 
> on the JDEV list yesterday. (I've tried to summarise them here.)
> 
> 
> Has Sander (or anyone else), got some time to write a first 
> draft of a new generally-useful 'Bot-Proof Challenges' JEP? 
> This could include inband delivery of images and CPU 
> challenges (e.g. find a string where the least significant 
> bits of the hash have a specific value).
> 
> The first application of that new 'building block' protocol 
> could be another new JEP that either extends or replaces 
> JEP-0077 (In-Band Registration).
> 
> I'd also like to see a procedure and protocol JEP that allows 
> a client to complain about the SPIM it is receiving (both to 
> its own server and to the sending server). This JEP might 
> also make use of the Bot-Proof Challenges to exonerate people 
> and to create a barrier against malicious multiple reporting.
> 
> If despite our other efforts we find people are still 
> bothered by SPIM, then clients could use the Bot-Proof 
> Challenges (with JEP-0155?) to verify each new correspondant, 
> who is not on the roster, is human.
> 
> 
> Server Implementors and Administrators have a lot more weapons against
> SPIM:
> - Dialback
> - Karma
> - Invite-only and/or out-of-band registration
> - Outgoing message filtering?
> - IP blocking
> (If admins don't use some or all of these approaches then I 
> agree they should be accountable for any SPIM their users send.)
> 
> Once enough clients implement e2e encryption then people 
> could insist that all correspondants use it, making SPIM far 
> more CPU-expensive.
> 
> 
> As I am confident we will be able to mitigate the SPIM 
> problem to the extent that:
> 
> 1. People do not need to block all messages from people not 
> on their rosters. 2. All public servers are free to 
> interconnect (as long as they have a domain cert from a JSF 
> approved authority and do not appear on the authority's black list).
> 
> As Sander mentioned, the JSF-approved certificate agreement 
> should legally disallow SPIM and provide tough penalty 
> clauses for clear abuses. (These agreements would probably 
> need to be drawn up under the laws of countries that are not 
> friendly to spammers.)
> 
> 
> > what will happen if a CA gets blacklisted?
> 
> Any certs it issues after the blacklisting are invalid. Certs 
> issued before *may* become invalid later if their owners 
> abuse (another CA could be appointed to handle that).
> 
> > providers even might want to send email over XMPP... ;-)
> 
> Seriously, I do expect email SPAM will motivate most people 
> to switch from email to offline IM delivery within the next 
> few years (as long as we minimise SPIM and improve our 
> offline message handling implementations).
> 
> > The call to Google to open their network now, today, is not very 
> > realistic, because we have a lot of work to do first.
> 
> Yes.
> 
> - Ian
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mail.jabber.org/mailman/listinfo/jdev
>