6 ms·

Taking your criticism to its logical conclusion, are you asking for end-to-end encryption on every online mode of communication in order to consider it secure?

by dsacco 9y ago

Taking your criticism to its logical conclusion, are you asking for end-to-end encryption on every online mode of communication in order to consider it secure? When security engineers and cryptographers analyze an application, they frame their analysis in the context of security goals, threat models and categories of risk. They don't begin from the perspective that application security is a boolean property - i.e. that the software is either secure under the most strenuous of requirements or simply insecure. That's not how any of this works. All security analysis exists on a continuum between safety and usability. Not all messaging software needs to be secure enough that it could be used as an anti-censorship platform or to facilitate secure communication from journalists in totalitarian regimes. For most companies it's enough that their data is protected through strong application security mechanisms, and Slack devotes significant resources to that task. In addition, customers choose to use Slack for its features. As others have pointed out, some of these features (like message search, or an audit log for direct messages between team members) cannot exist under an end-to-end encrypted model. If you want to use Slack, that means you want to use Slack's features. It's pointless to demand Slack to become something it's fundamentally incompatible with. If you want confidentiality assurance at the highest echelons of computational security, just use something else.

intelhearts 9y ago
> are you asking for end-to-end encryption on every online mode of communication in order to consider it secure? that's not unreasonable at all
- EpicEng 9y ago
  It absolutely is. I niether need nor want end to end encryption in slack. Yesterday I searched for a months old message which would not have been possible if everything we're encrypted all of the way through. We're not the CIA and slack is secure enough for us.
  - deleted 9y ago
    [deleted]
  - voidmain 9y ago
    End to end encryption isn't incompatible with full text search. More to the point, end to end encryption is necessary (but far from sufficient!) to keep communication secure. If you don't need your communication to be secure, that's fine. The thing about the modern, networked world, is that you don't have to be the CIA to face a sophisticated, global threat model.
    - hamandcheese 9y ago
      I’d love to know of an existing end to end encrypted chat platform with a search experience comparable to Slack. The only way that’s obvious to me is searching locally on your device. This will not be a happy experience for any moderately sized organization.
      - deleted 9y ago
        [deleted]
      - icebraining 9y ago
        grep can trawl through gigs of files in a few seconds (and that's without indexes), so I don't see why would be an unhappy experience. In any case, there are alternatives; one would be to "recruit" a few other clients of the same organization for a distributed parallel search.
        codefined 9y ago
        The issue comes from the fact that I don't really want to have to download gigabytes of data over my network. Especially not if I just want to quickly check my messages from a web browser.
        hamandcheese 9y ago
        Okay, show me an end to end platform I can grep through.
maxaf 9y ago
You're absolutely right. The commenter you replied to seems to implicitly assume that strong encryption is needed everywhere, but this simply isn't the case. Slack is "good enough" for many use cases, and that's fine. The ability to recognize when a given tool is no longer fit for the task at hand is a fine and valuable skill. "Let's take this to Signal" is an appropriate thing to post on Slack when the conversation warrants it.
snowwrestler 9y ago
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
hueving 9y ago
The big part you're missing in this comparison is one slack compromise gets the attacker every slack conversation for everyone that uses it. If someone gets into an email server, they only get the mailboxes on that server. By centralizing slack, they've made it the ultimate target worthy of people with 0-days.
- dsacco 9y ago
  > If someone gets into an email server, they only get the mailboxes on that server. By centralizing slack, they've made it the ultimate target worthy of people with 0-days. So you’re opposed to Gmail and Outlook as well? Do you run your own mail server? Does your organization?
  - UncleEntity 9y ago
    Don't see that as a valid argument, in the lead up to the elections they got a couple email dumps as opposed to the whole chat history of the political organization -- which I think would've been very bad, definitely very, very bad...
    - dsacco 9y ago
      It’s an argument attacking the probable inconsistency of the parent’s argument. More generally speaking, it’s an argument that reiterates my original point - security is a context-specific discipline, and it is fully legitimate for people and companies to decide they would rather have various features than maximal security. Security has diminishing returns of efficiency with respect to how much safety it adds at the cost of removing some usability. I stand by my point: in practice, end-to-end encryption is not desirable for many applications, and that’s completely fine. We have entire fields like application security precisely because it’s inappropriate and untenable to lean on maximal computational security for all of our confidentiality, authentication and authorization requirements.

voidmain 9y ago

I guess I need to add this to the long list of companies I should start, then? It doesn't seem very hard; I explained how to do it downthread. The cost to the client should be reasonable.

andkon 9y ago
If you can find a way to get a three-year-old Android phone to do full text search on an entire company's years of Slack chat logs, then you definitely should start a company.
- rdl 9y ago
  There are lots of ways to do this in normal corporate environments more safely than Slack but with decent user experience. Some data can always be locally stored on the device and searched (maybe anything I've typed myself, or particular forums I search frequently). Some data could be downloadable on demand (if I want to search all of my DMs with a given person, it's reasonable even on a phone to download that entire 5MB chat log locally to do the search). Another way is to trust an archive/search server temporarily with the decryption; if you trust it right now, you can decrypt your logs on that server, do the search, then wipe it. That's a lot safer than all of those logs sitting around forever for anyone who pops the server at any point in the future. Another option is an enterprise chat server (e.g. Mattermost), or having some kind of chat log server run by the enterprise which is for searching, but use a hypothetical end to end encrypted Slack for routine communications. Making this all happen as transparently as possible and as efficiently as possible, with clear user security expectations, is what the "company" level stuff would be.
  - jlardinois 9y ago
    Today I had to search for Slack messages that were sent long before I was hired to solve a problem at work. In an end-to-end model, you're only going to have logs as far back as you were there to receive.
    - rdl 9y ago
      Not necessarily (depends on how you define e2e). One could handle group messaging in a way where membership gives you full historical access vs. only when you were subscribed. In a corp environment you might even require that some groups remain server-side so you can instantly revoke access. Allowing different security models for different groups would make sense, as long as you could communicate the security models to users and admins somehow. e2e for direct user to user makes sense.
      - jlardinois 9y ago
        > e2e for direct user to user makes sense. I disagree, corporate chats still have plenty of reason to want access to historical user-to-user chats. Ignoring the cynical reasons, institutional memory isn't confined to channel chats.