OK, so...
Maybe I missed something. Didn't I read that Google is blacklisting
*all* invites from *all* external XMPP services? What you said
indicates that they are only blocking invites from some services.
Which is correct?
Google might have a perception problem ...
It appears that the technologists at Google are still apparently
committed to reimplementing XMPP federation and CalDAV client support
(another topic). But the public statements offered by Google corporate
are indicating that Google is starting to do exactly what every other
company does with open standards. They use open standards only when it
is advantageous to their bottom line. What's going on? I suggest that
the Google techs fix the public corporate statements if they aren't
accurate. Google has a credibility issue with the internet community
here.
Specifically on the spammy invite issue...
In the email world, "open relays" exist; and email administrators
solved the problem by creating various blacklists that identify open
relays and other types of "spammy" reputations. Every email service
today uses various levels of reputation to stop spam. IP reputation is
still a primary method for identifying email spam. I really don't
understand why blacklists aren't the solution for identifying and
blocking "open" XMPP services. XMPP service providers won't start
putting hurdles on account creation until after they get blacklisted.
Frankly, I wouldn't be aware if a public XMPP blacklist already exists,
since our university doesn't have the problem of XMPP spam. It seems
that the spammers are only targeting certain services, such as Google.
This might explain why Google feels that the XMPP community isn't
supportive in dealing with their spam problem (e.g. by means of
maintaining public blacklists). Are my thoughts on this correct?
Now, maybe I'm not understanding the problem Google is dealing with...
Are these spammy invites coming from XMPP services that are otherwise
restricted to authorized users? We certainly deal with end-user
credential getting compromised for purposes of sending email spam, so
it is logical that the spammers might also use these credentials to
send XMPP spam. I think that this is an interesting problem that needs
new clever solutions; both for email and chat.
Can I suggest an option for Google? It might not be feasible. How
about automatically whitelisting the invite initiator if the Google
user has had an email correspondence with that recipient? e.g. If
[email protected] has sent an email message to
[email protected], then you can be relatively certain that
an XMPP invite from [email protected] to [email protected] is
legit. I know that this technique only works if the JID is the same as
the mail address, but it might be a partial solution.
Jesse
On Wednesday, March 20, 2013 11:15:09 AM, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 3/20/13 8:47 AM, Per Gustafsson wrote:
Quick update: restricting federated invites has significantly
reduced the spam problem for our users. We continue to work on this
problem and expect to roll out a solution next week that does not
require whitelisting.
Hi Per, thanks for the update!
While I realize that Google needs to do what is best for itself and
its users, I also encourage everyone here to think about and work on
solutions that will enable us to maintain federated communication in
the long term. Among other things, that might mean shutting down open
(non-CAPTCHA-controlled) registration on public XMPP servers. We might
also reconsider some of the technologies we've been working on over
time, such as automated incident handling (XEP-0268), server / user
reputation (XEP-0275), and the blocking command (XEP-0191). Federation
is very important, and we can't allow some script kiddies to make us
stop communicating.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRSeCMAAoJEOoGpJErxa2pgcgP/1Txu0WJ8Ky+uMepqwOQ4sJp
sdz1U0C3t+by7nhWeD8lWW3sayL6sE+jotKRMgjHj3fLtY1i3x9aLAMrIkUX4UGh
EVOsNtmWS/CqL9AkF7IIq4H1qDSMhKFt929tEBAvX8jb5LGDHET7LEtv3ersI2Tn
SFKKFd0RGcC29uqUUxSmKegeWW5098Z3SxEPHzJPSxTDTL5C0xXTYOkc3PsPTs96
vGcB4Pv2/D5ihie/jb2f3RmsTWI5z/8UYZ+zlie7l0HSGTj5BsnQsdLxXeWSTm8v
JlsABk9w0WNBNTjk58xco+58gDHv4gUinjVn2+8P6Cvyr5MV+XRyRow9EHCriPiW
efcsDx1bGjiPuhkYBHo1O3PZJB6UlViCTwQxf8+GzdOhfbNqJalbBkxFZMxDVG/E
6IcQGgBvEjXD1lOk/qF4rfoVAM7ByEC/cYFqpNjn2/2f36SUrmEn3XmpyHdaCiQ+
lFkQWB/twAbt34rB39athl/8vkPtFaFFFmF7t0Np/+FM08+YY82NQDbR70hZP7wt
KXBWd8wDIeRTQBwT+KFp12kTdEyCl/tK2ZmKOxFoSiYOD7N656iEYu5ERPQgj93d
huYaVEy/sXy301m/RHHHQjVZCNdBIUa8hAmBQNh4oIvLMn5Zb/U5kTtUAJfHpAmD
VzsdD8zjpi7Ry8dYJayF
=+XrO
-----END PGP SIGNATURE-----
