The Problem with Slack


Don’t ever say anything on Slack you don’t want read aloud in front of a 72 year old Alabama judge in federal court.

Collaboration software is great, but it’s also great for getting penis pictures into public court records. People are comfortable on Slack, which is what makes it so effective, and so very dangerous, especially for news teams. We are shit-talking motherfuckers, with the occasional penis jokes (I mean who doesn’t love a good penis joke). There’s the one kind of trouble being overheard at a bar, and then there’s persistent logging of everything we say on remote servers. This isn’t an esoteric, theoretical threat. This is how Gawker died, after their Campfire chats were subpoenaed and entered into court records. Fusion wrote about this at the time: in an article where they also talked about using Slack. Because, presumably, bad things only happen to other journalists. Bonus dipshit points to journalists who took to Slack to complain about Thiel, Hogan, or bemoaned the fate of Gawker as a threat to us all, (which it is) and didn’t bother to think about the forum in which they were complaining.

If you want to continue using Slack in your news org, my recommendations are: don’t publish anything controversial or anything that might upset someone. If that isn’t your news brief, it’s time to care about this, because caring about this later won’t be effective.

The important problems with Slack are(1):

  • You don’t know if they comply with your document retention policy, and could expose you to far more legal jeopardy than you expect, unless you check. You can explore this by looking through chat room histories, searching sensitives terms, and scrolling back on various interfaces. (If it offers access to more logs with a higher level of service, that’s not good, they’re saving stuff on their side.) 
     It’s a good idea with any policy with any technology to verify that the reality of your configurations, and the behavior of the software, matches policy. Finding out you’re collecting less data than you expect can be frustrating, finding out you have more can be financially and legally ruinous.
  • Under the Third Party Doctrine in the US, Slack doesn’t have either the legal tools or the level of motivation you do to protect your chats. In some conditions, you might not ever know that your logs have been turned over, either under a domestic subpoena/warrant, or via MLATs warrants.
  • Slack has good, thoughtful people working for it, the kind of people who are going to put in real work on their security. They’re not going to be an easy or cheap hack. But as the variety of teams join Slack, and get used to it, their value as a target increases. General computer and network security in the early 21st century simply isn’t good enough, categorically, to trust logged, unencrypted communication touching the net to remain safe over time. Slack will get hacked, over and over. (I know Slack uses encryption at rest, but if Slack can access your data, so can a sufficiently motivated actor)

As Slack continues, likely years into the future, it will be hacked by people engaging in corporate espionage, governmental actors, and talented amateurs. Some of these will be discovered quickly, others will never be discovered at all. Like every other computer system, Slack’s employees, no matter how diligent, will never have an easy way to ensure that they aren’t compromised. Given enough time, everyone is compromised. Given enough interest, it doesn’t take much time.

Alternatives to Slack

Slack is based on IRC, which is how I wasted most of my youth. It’s possible to host a local, encrypted IRC server, but it requires a lot of work and thought. If you’re just now thinking Slack might be a problem, going old skool is not for you.

Most security-conscious versions of Slack are not anywhere near as mature or stable. SpiderOak is the standout — they are specifically trying to solve this problem with a zero-knowledge system. The URL for their Semaphor group chat product is:

I haven’t used Semaphor yet, but I’ve used other SpiderOak products, and they are serious about security. I wasn’t able to find anything specific about message retention, but it’s likely to be handled somewhere.

Right now, I’d rather most teams were using Whatsapp or Signal groups, which have both mobil and desktop/web clients. This is much like the end-to-end hosted solution, and document retention is still difficult, and may just require disappearing messages or a day where everyone deletes history. But hackers attacking either Whatapp or Signal only get ciphertext without forcing a key change, which both clients will alert you of. (You have choose that setting in Whatsapp, which you should if you haven’t, right now.) Even doing this Man-In-The-Middle attack would only give the attacker access to future chats, and be easily caught with number verification.

Metadata is still available for Whataspp especially, and theoretically from Signal, which is why I don’t recommend them for source protection. But if all you can learn from subpoenaing Whataspp is that newsroom chat with each other, have fun with that.

What could Slack do to make it safe(r) for newsrooms?

Slack could offer a local version of its software, with strong encryption and and easy to understand, easy to check retention features. These chats would never leave the local network, and and remote connection would require a VPN. This doesn’t mitigate the problem of hackers, in fact it’s probably worse to use your security team instead of Slack’s in most cases, but it does mean Thiel can’t use your trashtalk to destroy your news org. For the problem of hacking, updating diligently and deleting or airgapping sensitive content as fast as possible is the best defense.

Slack could offer an end-to-end encrypted hosted version, with far fewer features. Using end-to-end means Slack itself can’t be compelled to turn over anything more than ciphertext and metadata, (or be able to recover your content for you if you lose your decryption key) but it also means it can’t search or index on Slack’s side, and punching things like your giphy reactions or bot functions into your end-to-end chat might make it a little less secure.

(1) This goes for all the other stuff people are using, Hipchat, Campfire, etc..