Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Begins Blocking Third-Party Jabber Invites

Posted by Soulskill on from the you-don't-want-to-talk-to-those-people-anyway dept.

New submitter kxra writes "Do you have a federated jabber instant messaging account that never gets responses from Google accounts anymore? Or do you have a Gmail account that a friend has been unable to invite from their 3rd party Jabber account? The Free Software Foundation reports, 'Google users can still send subscription requests to contacts whose accounts are hosted elsewhere. But they cannot accept incoming requests. This change is akin to Google no longer accepting incoming e-mail for @gmail.com addresses from non-Google domains.' This sounds like something Facebook would try in order to gain even tighter control over the network, but they never even federated their Jabber service to begin with. According to a public mailing list conversation, Google is doing this as a lazy way to handle a spam problem."

14 of 92 comments (clear)

  1. Just wait... by daitengu · · Score: 3, Insightful

    Countdown to those with bad reading comprehension wondering why the story isn't about Google not accepting e-mail from non-@gmail.com accounts.

    1. Re:Just wait... by Hatta · · Score: 4, Insightful

      What's the significant difference? Isn't refusing jabber messages from non-google account just as bad, and bad for the same reasons, as refusing email from non-google accounts?

      --
      Give me Classic Slashdot or give me death!
    2. Re:Just wait... by Hatta · · Score: 4, Insightful

      The significant difference between blocking email and blocking jabber requests is that when you find that your jabber request is blocked, you can ask the person on the Google side to send you a request from their end, and from then on you can communicate with them.

      What happens if everyone implements this policy of denying all foreign requests?

      --
      Give me Classic Slashdot or give me death!
  2. Google has been quite evil this week by Meditato · · Score: 5, Interesting

    1. Banning ad-blocker apps from the Google Play App store

    2. Banning jabber invites

    3. Killing Google Reader

    They're too big to need to play nice with anyone.

    1. Re:Google has been quite evil this week by recoiledsnake · · Score: 5, Informative

      You forgot them killing the open standard CalDAV support and replacing with their proprietary Calendar API.

      http://www.zdnet.com/google-do-what-you-want-with-reader-but-dont-kill-caldav-7000012628/

      --
      This space for rent.
    2. Re:Google has been quite evil this week by LordLimecat · · Score: 5, Insightful

      Apparently, its evil to decide that its no longer worth providing a free service that youve provided for years, and giving your users several months to take an export of their data.

      Likewise, apparently its evil to stop allowing users to host apps which undermine your core businesses on your freely provided marketplace.

      Of course, given that you never offered a free RSS reader or marketplace to begin with, wouldnt that make you more evil than Google?

    3. Re:Google has been quite evil this week by LordLimecat · · Score: 4, Insightful

      1) As they dont pay for Google Reader or Play market, thats irrelevant.
      2) So once someone offers a free service, you demand that they offer it forever? Sounds reasonable.
      3) Yes, I was remarking on how you can go to www.dataliberation.org in the next several MONTHS and get your data out. Have you ever tried getting your data out of AOL or Hotmail or someone else's systems? It tends to be a royal PITA. Never with Google, they always have at LEAST a CSV export.

      But if you want to be both a beggar AND a chooser, dont let me stop you.

  3. TFS last sentence untrue by DragonWriter · · Score: 5, Insightful

    According to a public mailing list conversation, Google is doing this as a lazy way to handle a spam problem.

    Nothing in that conversation says that Google is doing this (not actually blocking all foreign invites, but sharply limiting the number from each foreign domain) as a lazy way to handle a spam problem; that conversation points to an extremely large spam invite problem, and discusses potentially needing to do it if the operators of the federated domains from which the spam is originating cannot address the problem. It also addresses some of the steps taken by operators of those domains to address the problem (as of the most recent message I can find, it also seems like those methods have not yet been dealt with the problem.)

    It very much sounds like the goal is to deal with the problem with the other service operators, but to take immediate steps to stem the flow of spam until an acceptable resolution is attained. The author of TFS may think this is "lazy", but it is not accurate to attribute that description to the email thread.

    1. Re:TFS last sentence untrue by Anonymous Coward · · Score: 5, Interesting

      Posting AC for obvious reasons.

      I run the helpdesk for a medium-sized email service (~350,000 users) that also provides federated XMPP service. We've had users complaining for several days that they while they can IM users at Google Talk, they can't request presence notifications (e.g. requesting to see if a buddy is online, away, etc.). They're able to chat with Google Talk users but can't see if they're online or not, which is a major issue. We've been really annoyed as we thought it was an issue on our end and assumed that Google knew what it was doing when it came to operating large-scale XMPP service.

      It's wasted a lot of our admin time and resulted in frustrated users.

      It's one thing to do a temporary ban of servers that are emitting gobs of spam or spammy invites, but it's a different thing to start blocking basic XMPP functions like requesting authorization for presence notifications. It's even more of an entirely different thing to block auth requests from the entire internet.

    2. Re:TFS last sentence untrue by johnsu01 · · Score: 5, Informative

      I know it says rate-limiting, but from our logs, the accepted rate appears to be 0. We don't have that many users; certainly not enough to trigger a rate limit in the scope of the kind of rate they would be worried about. And while we did not say "lazy" in the original article, but rather expressed our sympathies for having to grapple with the spam problem, this is not an acceptable solution. As other commenters are pointing out, this is essentially shifting the burden to much smaller entities, who now have to respond to their users' complaints. If Google would publicly describe the problem, and the scope of it, and publicly explain what they are *actually* doing, then the rest of us could help find a solution. Right now, this definitely looks like "easiest way out for us, broader principle of federation and workloads of other entities be damned."

  4. Re:No Subject by asavage · · Score: 4, Insightful

    Yeah this is good news. I had to disable google talk invitation notifications on my phone as I was getting spam notifications daily.

  5. CAPTCHA by ensignyu · · Score: 5, Interesting

    Maybe instead of silently dropping invitation requests, Google should send a rejection notice (regardless of whether the target Gmail account exists, to prevent probing) with a link to a CAPTCHA; completing the captcha would allow retrying the request.

    Given their track record, I'd be surprised if Google bothers to implement this kind of non-lazy approach to re-enable interoperability, though.

    1. Re:CAPTCHA by ensignyu · · Score: 5, Insightful

      Just to be clear, I'm sure the engineers at Google are trying to do what they can do deal with the spam problem, as quickly as they can.

      I'm just feeling cynical about Google's motives and actions after what they've done with Google Reader, CalDAV, etc. Yeah, they're a for-profit corporation, but it's disappointing how they seem to be moving away from open standards.

      At this point, it seems like they're looking around and saying: "Hey, we have a proprietary solution, and an open solution, but it costs extra to maintain both. If we shut down the open solution, we save money and get extra lock-in too. It's win-win! -- for us, at least."

      So I'm slightly worried that when a situation like this comes up, the managers at Google (or managers' managers, or wherever the directive is coming down from) are just going to say "do the minimum amount of work and get back to that other project we have you working on", where implementing solution that's good for the users is not a priority.

  6. Re:Just Run Your Own XMPP Server by Hatta · · Score: 2

    And what if you wish to speak with someone who uses Google's XMPP service?

    --
    Give me Classic Slashdot or give me death!