[Standards] XEP-0045: direct invitations

Peter Saint-Andre stpeter at jabber.org
Fri Jul 20 16:24:52 UTC 2007


Ian Paterson wrote:

> *Maybe* we need to consider addressing the valid reasons that Google
> Talk feels it needs this policy, rather than handling the symptoms of
> the policy? Can we solve the real problem? i.e. can we create enough
> anti-spim protocols and/or infrastructure to make Google (and everyone
> else) confident enough to relax this policy?

Yes, let's look at the root causes. https://stpeter.im/?p=1989 talks
about this a bit.

Basically, it is quite easy to repeatedly join a chatroom and spam the
room. You can even do this with a normal client, no need to automate the
process. Spam the room until you get banned. Either move on to another
room or create a new account and go back to spamming the room. We've
seen this on some of the open MUC services already.

I think we need a way to identify MUC joiners/occupants by IP address.
But RFC 3920 forbids leaking of IP addresses (quite rightly). So we need
a way to anonymize/obscure IP addresses. We could use HMAC-SHA256 but
each Jabber server would have its own secret, so that would not guard
against people/bots who create accounts on multiple domains. A better
approach might be cryptopan:

http://www.cc.gatech.edu/computing/Networking/projects/cryptopan/

I may write up a proposal along these lines soon.

This does not necessarily address the concern that Google Talk has (I'm
not sure what that is), but it would solve some of the problems we're
seeing. And it would implemented server-side, so doesn't depend on
updates to millions of clients (which couldn't be trusted anyway).

Thoughts?

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070720/3941f0ed/attachment.bin>


More information about the Standards mailing list