[Operators] The Google issue

[Solomon Peachy]

On Thu, Nov 21, 2013 at 07:26:58PM +0000, Matthew Wild wrote:
> We are going to affect a lot of users across the network on 4th
> January as we effectively disable federation with Google. Some will
> inevitably be outraged, as they are unable to speak with their friends
> and family members. Some will herald it as a step forward in
> transitioning people away from servers with poor communication
> security.

I have mixed feelings about this, because I'm the only user on my 
server, and only two folks on my roster aren't google-hosted.  Frankly, 
without Google federation I might as well not bother.

> Technically, as a server developer, it would be possible to continue
> to allow Google domains as an exception (this isn't possible with a
> simple white/blacklist because of Google Apps hosted domains). Would
> this be a positive or negative step to take?

As a server operator, I see this a PITA in the best of situations.  
However, as a *user* of an XMPP service, losing the ability to 
communicate with all Google users would render said service pretty much 
worthless due to network effects.

Remember, Google is more than just the 800lb gorilla in the room; they 
are larger than everyone else combined, even with this Hangouts mess.

I wish we could get some sort of indication out of Google what they 
intend to do with their Federated XMPP stuff; for the time being they 
seem to be content to keep the Hangouts and Talk network running 
simultaneously, although I'm sure the number of users on the latter 
are slowly decreasing.

Google's new-found love for internal encryption (Howdy, NSAcritters!) is 
sure to affect this too, though it could go either way -- Add TLS to 
Federated XMPP, or just accelerate existing plans to can federated XMPP 
entirely?

Sigh.  Meanwhile.  What's the ultimate goal of this?

We're not going to improve XMPP's popularity by dumping Google before 
they dump us first (out of sheer apathy); indeed just from a network 
effect/utility perspective, this is perhaps the worst thing (as server 
operators) we can do.

The presence of *mandatory* S2S communication isn't going to win us any 
new users -- Those that care about such things already have it enabled.  
We already have strong crypto protecting message contents, and even if 
we encrypt the S2S streams we can't hide the presence of those S2S 
streams.

Take my employer.  I've been trying to get them to move to 
XMPP-on-our-domain-name instead of an adhoc Skype arrangement.  Google's 
half-assed abandonment of federation has really hurt my case, but the 
same applies to clients and vendors that use XMPP-based systems.  Will 
all (or any) of those commit to enabling/fixing TLS?  (Those of us who 
have ever dealt with any mid-largeish business already know the answer 
to that one...)  So even if we move to federated XMPP, we will probably 
never require encryption on S2S links.

That isn't to say that TLS interopability days aren't a damn good idea 
(we need to make sure things actually work!) but as long as the 800lb 
gorillas out there (eg Google or $random_corp's_internal_im) don't 
commit to supporting TLS, IMO we're just going to end up with a "cool 
kid's darknet" that you'll need to abandon in order to communicate with 
your colleagues, clients/vendors, and/or your mother.

Anyway.

 - Solomon [Man of many hats]
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131121/34bf7335/attachment.pgp>