[jdev] [Standards-JIG] anti-spim techniques

[Ian Paterson]

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