-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 5/22/13 2:40 PM, Jesse Thompson wrote:
> On 5/22/2013 10:02 AM, Peter Saint-Andre wrote: On 5/22/13 8:52 AM,
> Jesse Thompson wrote:
>>>> Google failed to note the correlation of the drop in
>>>> federated XMPP connections with the fact that Google Apps
>>>> (which internally federates its hosted domains) and Office
>>>> 365 (which doesn't support XMPP federation) are gobbling up
>>>> the market as organizations move to the cloud.
>>>>
>>>> Oh well ... it always troubled me that people trusted
>>>> Google's support for open protocols as somehow permanent to
>>>> the nature of the company.
>
> Yes, it seems to have been a marriage of convenience (since
> they're also dropping RSS via Google Reader, also cf. the SPDY work
> to supersede HTTP, etc.).
>
> On the other hand, not needing to interoperate with Google Talk
> might free us to more aggressively work on network security
> improvements. I say let's take this as an opportunity rather than a
> disappointment.
>
>> The one technical reason cited for the largest XMPP service
>> operator to exit the XMPP community is that there is a spam
>> problem; not a network security problem.
>
>> Improving network security doesn't improve the spam problem;
I am speaking of network security in the broad sense: e.g., things
like incident reporting and entity reputation and JID blocking in
addition to authentication and encryption. It might be true that some
of those don't directly help with spam resistance (I don't say spam
prevention because nothing can fully prevent it), but now that we've
been deploying these technologies since 1999 you might think that at
least we could authenticate and encrypt our server-to-server
connections (which at least might raise the bar for certain forms of
attack).
>> otherwise Google would have tried it.
Given the vast resources at Google's disposal, they could easily have
contributed even a few comments to the standardization efforts at the
XSF regarding spam resistance and network security, not to mention
code patches for popular XMPP servers or even fixes to their own
service -- but they never got involved except for a few lonely and
very occasional souls on this list.
>> (As a comparison, the various email domain authentication and
>> encryption schemes hasn't put a dent on email spam.)
And how widely is SMTP authentication enabled? Not very.
The best (least-worst) solutions to email spam seem to be based on
statistical analysis of message content (Bayesian filtering and such).
In fact gmail does a pretty good job of blocking spam, so I wonder if
the folks at Google ever thought about turning that same technology
against IM traffic. We'll probably never know.
>> If there is any chance to woo Google (and the thousands of
>> domains they host) back into the fold, then the spam problem
>> needs to be the prime focus.
I don't think it's a question of wooing -- it seems to me that they
made their decision for business reasons ("don't be open") and the
technical rationalizations were just air cover.
Having said all that, I agree with you, Jesse, that we need to come up
with solutions here.
A number of related specifications have been proposed over the years.
Why don't we start there, figure out which ones have promise, and
start implementing and improving them?
Examples beyond the core of XMPP (e.g., authentication and encryption)
include:
XEP-0158: CAPTCHA Forms (as applied to in-band registration, chatroom
joins, etc.)
XEP-0159: Spim-Blocking Control
XEP-0191: Blocking Command
XEP-0205: Best Practices to Discourage Denial of Service Attacks
XEP-0219: Hop Check
XEP-0268: Incident Handling
XEP-0287: Spim Markers and Reports
draft-ietf-xmpp-dna: Domain Name Associations (DNA) in XMPP
draft-miller-xmpp-posh-prooftype: Using PKIX over Secure HTTP (POSH)
as a Prooftype for XMPP Domain Name Associations
draft-ietf-dane-srv: Using DNS-Based Authentication of Named Entities
(DANE) TLSA records with SRV and MX records
We might also think seriously about doing away with in-band
registration (although CAPTCHA "protected" web registration doesn't
seem to be all that successful at discouraging spammers from
registering accounts, either).
Other suggestions are welcome.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRnVPsAAoJEOoGpJErxa2pLIYP/RCIT13KdnHPHE6tPywUiICv
SknoAzl67izG+asYN5hHShVlWp4BwgMJdrXoTnlOlBQ5AjdfRHSwdLylV19DffpS
o59sVNGIRDqR6ovuJ8mpq7RdLxtamzeW3KJpukj8jmJ3QOfGW5kxngo2bWBBKhd3
9IQo4/omgzK28kR/V8aVDISvqmaWNzScuuePEXBIaUDFDTq8JXpppYGLJyee8NmG
fViqQ550dDOC1qqLVKsJcgiJeJzolwyOy8Y7Fu10xmm6W67qHcdQVfYjIYw85wkK
u7PdXIZWYYapHYGeNqv4VgJNdCwkmEoLxuIzvaiRaMRuYcXs1am7EENLm3z/dFSt
NrNvNvJpDsGov390JtROcTrGqVEJ8UpOYMpMtU9br5D/kwATV9cF3qpO+O+1946U
NEkOGuy8n+Ob/DuRspKWLSPHYy/pKePIVBMJmqJP+us9X5QkuJ1Bx/rRy35mRmlL
exbYxBS7Haq7HCfmv+XtqYqy/2yBDmXm+sOzkvmdUC0WeDKfA4OdD/NgtBekkOkd
vdk9wbBGndfzXnDJi2tGF8QDyEUPewXWoYZokXLfRMglnLUBYwMeEC/gLQL8Z7n+
PTjD/mrgzc4jKXHiWtOvXv70G9WknxPJ/DFaXgeBibsCa4aZBNSF6K5nKpps7fXX
UG4cayTw7epD39ubwLln
=GQpE
-----END PGP SIGNATURE-----
