4 ms·

There is a qualitative difference between having your staff communicate with each over Slack, and having your staff communicate with each other over email or lo

There is a qualitative difference between having your staff communicate with each over Slack, and having your staff communicate with each other over email or local chat within the firewall. For one thing, if you run applications on servers you own, you and only you will get the subpoena for that information. You and only you will know if that information is breached or exfiltrated. Under 3rd party doctrine, Slack does not need your permission to provide your data to law enforcement, nor are they under any obligation to tell you that they did. And while I haven't read the Slack legal agreement for a while, I would be surprised if there is an ironclad SLA around their duty to notify you if they are breached, or to provide all details about who got what when. The alternative to Slack is not always Gmail and Gchat, in every institution. Running licensed applications on owned hardware is still a thing that many organizations do for the reasons I list above, and others including document retention policies. And yes, employees with mobile devices can certainly be encouraged to chat over WhatsApp, iMessage, or even Signal instead of Slack. Or at least they can be empowered with an understanding of why they might want to put certain sensitive information there instead of in Slack.

danenania 9y ago
I think the key is to make sure that developers and other employees understand the tradeoffs. This applies not just to Slack, but also to email, Github, cloud storage tools, and even browser extensions. Apart from easy setup and good ux, these tools provide ideal integration points for third party plugins that can do all kinds of amazing things for productivity, sales, business processes, code intelligence, etc. etc. In my view, this is all well and good, and we shouldn't be looking to axe these benefits by demanding self-hosting or end-to-end encryption for everything. Instead, people need to understand what they are and aren't appropriate for. If your browser has 20 extensions installed with access to every page's data... that's cool--I'm sure they all do useful things, but would you sign in to your bank's website with 20 strangers looking over your shoulder? Same deal with Gmail, Slack, and Github. They all have their place, but they were not designed to store e.g. application secrets securely--especially if you're also using third party integrations (which, why wouldn't you?--it's a big part of the value they offer). None of this is a problem if you just draw the line in the right place. Quick plug: this issue is exactly why I started EnvKey[1], a 1Password-like service that keeps application secrets securely in sync across development and server environments so that developers aren't tempted to share them over third party channels in plain text. If your secrets management strategy involves exposure to any third party, you should probably re-evaluate what you're doing. EnvKey offers a very quick, hosted, end-to-end encrypted approach to getting you on the right track. 1 - https://www.envkey.com https://www.envkey.com

danenania 9y ago

I think the key is to make sure that developers and other employees understand the tradeoffs. This applies not just to Slack, but also to email, Github, cloud storage tools, and even browser extensions. Apart from easy setup and good ux, these tools provide ideal integration points for third party plugins that can do all kinds of amazing things for productivity, sales, business processes, code intelligence, etc. etc. In my view, this is all well and good, and we shouldn't be looking to axe these benefits by demanding self-hosting or end-to-end encryption for everything. Instead, people need to understand what they are and aren't appropriate for. If your browser has 20 extensions installed with access to every page's data... that's cool--I'm sure they all do useful things, but would you sign in to your bank's website with 20 strangers looking over your shoulder? Same deal with Gmail, Slack, and Github. They all have their place, but they were not designed to store e.g. application secrets securely--especially if you're also using third party integrations (which, why wouldn't you?--it's a big part of the value they offer). None of this is a problem if you just draw the line in the right place. Quick plug: this issue is exactly why I started EnvKey[1], a 1Password-like service that keeps application secrets securely in sync across development and server environments so that developers aren't tempted to share them over third party channels in plain text. If your secrets management strategy involves exposure to any third party, you should probably re-evaluate what you're doing. EnvKey offers a very quick, hosted, end-to-end encrypted approach to getting you on the right track. 1 - https://www.envkey.com https://www.envkey.com