1. 35
  1.  

  2. 12

    I agree that the concentration of data at Slack makes them a very valuable target. But I’m wondering if self-hosting is really safer than using Slack:

    • If everyone switches from Slack to Mattermost, this would make Mattermost a valuable target too, and then hackers will target Mattermost instances like they target Wordpress instances.
    • System administration is hard. I would guess that Slack does a better job than most in-house teams at securing their system.
    • For better or worse, most organizations don’t host on their own hardware anymore. They rent virtual machines (AWS, Google Cloud, Digital Ocean, etc.) or physical machines (OVH, Hetzner, etc.). This makes the hosting provider an extremely valuable target too.

    What is your opinion on this?

    1. 11

      I agree, but there’s many reasons beyond those to run your own service, such as policy reasons.

      My main complaint about Slack for FOSS projects for example is that Slack is policy-wise built around being a corporate chat (which has implications to privacy policy etc.).

      1. 10

        I very much agree about Slack not being a good fit for FOSS projects.

        1. 1

          Is there a service that works much like Slack but with a default-public design intent? Is Gitter the go-to for this kind of thing?

          1. 8

            Gitter has become better in that regard (especially with moderation tooling).

            Discord, Matrix and (almost) Zulip are options, but all with different drawbacks. Zulip has the drawback that moderation features are currently not in the hosted offering. Discord seems to lead the pack when it comes to moderation. I’m obviously not a full-time user of all of them.

            As much as I dislike IRC, IRC as practiced has a very good model for FOSS: many channels, optional logging and clients geared towards being “AFK by default”.

            Sadly, there’s almost no chat software built around the needs for open communities.

            1. 2

              We’ve used Gitter and Slack for various OSS projects (both ours and others). Gitter’s great because it’s so easy for people to join. However, it doesn’t scale well as more people join a channel, because the search is really bad, no threading, scrolling through history is really cumbersome, etc. Also, the mobile app is terrible at notifications.

              Slack definitely feels like a closed ecosystem. The workflow of getting an invite, then signing into the Slack client, etc. adds a lot more friction to the process. Plus, switching between Slack chats on the Mac client is SLOW.

              1. 1

                the search is really bad, no threading, scrolling through history is really cumbersome, etc.

                It feels to me you’re looking for email, not a chat.

                1. 2

                  That’s a simple statement to make, but the difference between email and chat is none of these properties.

                  1. 3

                    It’s time for forums to make a comeback.

                    1. 3

                      They have? Everyone and their dog has a discourse now.

                    2. 1

                      I agree, but how would you characterize the difference between email and chat?

                      1. 1

                        Temporal and conversational characteristics. Chat is built around real-time exchange of short messages, mail is built around slower discussion with larger, self-contained messages.

                    3. 1

                      Not really. We want real-time conversation with people. For example, someone may download Telepresence (one of our OSS projects) and struggle to get it working. Telepresence under the hood does a bunch of networking stuff: deploys a proxy in Kubernetes, sets up a VPN tunnel via kubectl port-forward, etc. So being able to talk to someone with problems in real-time (versus filing a GitHub issue, or email) is extremely helpful to accelerate the debug process.

                      And then, it would be nice to search through and say oh yes, so so had an issue with Mac OS X and kube 1.7 that was like this … but you can’t really.

                  2. 1

                    YES this! I don’t hear this being talked about nearly enough, but I seriously dislike the whole model where individual communities are shuffled off to their own ‘teams’ or ‘rooms’ or whatever. IRC’s channels offer an invitation to collaboration and discovery - NONE of these services offer that, and I don’t understand why so many people are willing to throw the baby out with the bath water like this.

              2. 3

                That address only the question of external attackers. But can you trust Slack to keep your data private? I think many people are also worried about this.

                1. 4

                  I also feel like we should definitely model “attackers” and “state actors” differently. Withing the law of the state Slack is in, the state can just walk in and ask and get things. No amount of anti-intrusion measures can counter that.

                  (In Germany, that’s the same, but at least everything happens in the territory I have my lawyers in :) )

                  1. 2

                    I agree. It’s a very legitimate concern. For example, if I was working for a defense company, I would definitely not use Slack.

                    1. 1

                      We treat slack internally as open to the internet (or assumed to be). No passwords in slack, no secrets of any kind. If the contents of our conversations leaked, it’d maybe be bad, but you have to assume someone will be reading them at some point regardless for potential compliance reasons.

                    2. 3

                      Sure, but you have to know a lot more things. WP is easy to spam, because it’s pretty easy to find. Even if 60% of companies started using mattermost, you’d have to find their instance (is it chat.example.com or is it mattermost.example.com or… ?). Plus it’s not that difficult to fend off wide script-kiddie attacks like this. IP rate limiting, regular patches, etc. That’s not very difficult to do with WP or mattermost. The upside is Mattermost being a Go application has a much smaller footprint of attack surface, plus they take security fairly seriously, and release often. WP started with a negative security outlook and PHP only helped the problem.. PHP is like the opposite of safe and sane(it’s getting better, but still).

                      System Admin is hard, but if you aren’t investing in good people, then chat data is probably the least of your worries.. see Equifax, etc.

                      I’m quite sure Slack also rents virtual instances, so it’s the same issue.

                      1. 2

                        I agree that if a company already self-hosts some services, then it makes sense to also self-host a service like Mattermost, which is easy to install and administrate.

                        Good point about Slack also renting virtual instances.

                      2. 2

                        I know you are not addressing me, but: when you host yourself you can (easily) add additional layers of security. For example put the services behind a VPN.

                        1. 6

                          True, but I don’t believe that perimeter security is very useful with the open networks we have nowadays (see BeyondCorp).

                      3. 7

                        I’ve seen argument a couple of times, and I don’t entirely disagree with it. It always seems to based around two primary points which seems to always be way off mark.

                        What if Slack was hacked.

                        Slack was hacked. But that’s kind of a moot point. You should treat any communication like email; insecure, and possibly a phishing attack. If you need to send secrets, do it out of bounds.

                        Everyone should host our own Mattermost/Rocket.chat/Hipchat.

                        Most certainly everyone should self not host. If its going on a server in some back closet which will ultimately be forgotten about until there is an issue you should not host it. Ops is hard, and its worst setting up one of these poorly or insecurely then not migrating.

                        There are roughly 48,000 public mongodb servers, and 4,500 public hadoop instances. And systems infrastructure doesn’t die, there are still machines infected with code read that are scanning the net. Offloading the responsibility for part of your infrastructure is not a bad thing.

                        1. 4

                          The author mentions that Slack may be hacked in the future, exposing sensitive communication of your team, and proposes Mattermost and Rocket.Chat as alternatives.

                          I’d like to point out that Mattermost and Rocket.Chat have the same problem — centralized servers that may be hacked (or may already have been).

                          Keybase.io has recently announced [1] support for team communication. They’re still behind in team-features compared to Slack, but Keybase is end-to-end-encrypted, making a server hack a bit less scary.

                          [1] https://keybase.io/blog/introducing-keybase-teams

                          1. 3

                            I’d like to point out that Mattermost and Rocket.Chat have the same problem — centralized servers that may be hacked (or may already have been).

                            From the article:

                            As we demonstrated above, companies need to find an alternative solution to Slack, one they can host themselves to reduce data leaks and industrial espionage and dependency on the Internet connection.

                            The author specifically aims at the self-hosted variants of both. They can still be hacked, but it must be done one server at a time. They are kind of centralised, but not in the sense that Slack is.

                            Yes, these are centralised, but there’s several reasons a company needs a centralised point of authority for their internal chat app - for example, compliance reasons.

                          2. 3

                            someone recently mentioned Delta Chat - an instant messenger based on Push-IMAP. That would eliminate even the “central servers can be hacked” commenters’ argument (if you deem your email server secure, which you probably do).

                            1. 3

                              Another thing not mentioned in the article, I imagine a single Slack employee could easily make a killing by using internal messages of companies in Slack and the stock market. Sure it’s illegal, but a long, wide and shallow, or alternatively a single big stock buy, and you would probably get away with it.

                              I’m sure there are tons of other ways one could use this information to make money/cause havoc.

                              1. 1

                                Go for an alternative on your servers e.g. https://www.totaljs.com/messenger/