How Slack Stays Secure During Hyper Growth(heavybit.com)
heavybit.com
How Slack Stays Secure During Hyper Growth
https://www.heavybit.com/library/podcasts/the-secure-developer/ep-14-how-slack-stays-secure-during-hyper-growth/
116 comments
Slack is not an excellent product. When I'm using 3g tethered connection Slack experience is unbearable. It constantly loses connection. Why is simple text chat is so bandwidth hungry. I'm surw it's due to bad engineering. IRC was much more reliable on much worse connections.
People often confuse engineering and design. Slack has a very good design team, the UX is far above IRC or competing solutions and everything flows and works in a way that most users expect. The engineering itself is not the strong point, that's for sure. Slow, bandwidth hungry, memory intensive, strange syncing problems, security issues, etc.
It's certainly pretty. It reminds me of that quote by Joel Spolsky - "people ridiculously overvalue aesthetics and beauty when evaluating products. It's one of the reasons iPods, and, for that matter, Keanu Reeves, are so successful."
I don't think usability-wise it's all that great though. If you have multiple chatrooms in multiple slack organizations, it's a PITA checking on them all, for instance.
I don't think usability-wise it's all that great though. If you have multiple chatrooms in multiple slack organizations, it's a PITA checking on them all, for instance.
On Spolsky's quote, wouldn't that mean people undervalue aesthetics and beauty?
Engineers undervalue it, users overvalue it compared to other criteria. Mostly because users are not engineers and so have no way to look at why a product is engineeringly superior; they can only look at how easy/simple it is to use.
I really would disagree. IRC didn't have a lot going on, you had channels and PMs and that was kind of it. It was very easy to learn how to use because there was very little to learn.
Not to mention, in most clients, it took significantly less than ten seconds for the text to appear on the screen after you started typing.
Not to mention, in most clients, it took significantly less than ten seconds for the text to appear on the screen after you started typing.
There is a lot more to IRC than just channels and PMs - it's just that not many people have purpose to find out about anything else because channels and PMs work so damn well for their purpose.... communication.
While I agree and personally prefer IRC, people using slack use far more features than just channels and PMs. That's because slack is more discoverable and the features are generally conceptually simpler and more obvious for the average user than complicated IRC features. That's the UX I was talking about above - it allows more users to use more features and feel more comfortable that they know what is going on. The same really can't be said for IRC - most average users will request the help of an 'IRC master' if they need something they don't know how to do. That's probably not a good sign of accessible UX.
I am with you. Totally. I would only add one thing. Why does the (Mac) desktop client have to reauthorize while I am writing stuff and loosing what I typed up until then. Or even while being in a voice call.
Is 3g usable in your area? My experience with multiple carriers has shown anything less than 4g/lte is near unusable even on simple webpages. This is both in metro areas in the bay area and northeast cities. My speeds go down to what I would have expected from 56k days, those simple webpages (text w/pics, no video) taking 2-5min to load.
Yes, 3g is usable, I can browse any site without noticeable delays. But Slack experience is extremely poor. It require a really fast and low-latency connection. And just for a text chat - there're tons of other solutions that has no problem with the latency and bandwidth of 3G or even Edge. But I'm forced to use Slack. :(
I'm getting used to Heavybit producing crappy podcasts, for example they claimed my website had 100k users when it had around half that amount:
https://twitter.com/WakaTime/status/954541663463948289
https://twitter.com/WakaTime/status/954541663463948289
Honest question, do you think a 2x factor of error is all that significant? Maybe it's just my EE background (where everything is measured in logs) but anything within an order of magnitude seems accurate enough for me.
Are you being serious? Saying you have 100k users when you actually have 50k is not fine, no matter your background. Hell, is it fine if I take an appliance that works on 110V and plug it into a 220V outlet? I'm also an electrical engineer and measuring everything in log scales doesn't excuse lying.
It's not about how significant the error, but that they don't care about their quality. When they interview someone without verifying that person actually works for a company, it shows they don't care about their quality.
They could fix it afterwards, but they don't even do that.
They could fix it afterwards, but they don't even do that.
50k and 100k strictly speaking are an order of magnitude different so what's your point exactly?
It's 2x not an order of magnitude.
2x is an order of magnitude in binary scales, which is what you should probably be using if you're working with computers.
2^16, 2^32, and 2^64 are a lot easier to understand than 6.5 * 10^3, 4.2 * 10^9, and 1.8 * 10^19
2^16, 2^32, and 2^64 are a lot easier to understand than 6.5 * 10^3, 4.2 * 10^9, and 1.8 * 10^19
Slack ruins all my laptops from $3000+ latest Macbooks to my HP Pavillion - it eats up memory like Crazy. Using Slack for 2 years now and they still havent fixed it.
Maybe not an option for you, but I don't leave it running on my desktop and instead rely on the mobile app for notifications and then pop into the desktop app if I need to engage extensively.
Sadly it’s the future, now electron apps are mainstream. Im not sure what they are doing with all their billions
>Slack is an excellent product
I used to think maybe it could have been before I was required to use it last year, but no, it's not. It is the worst chat application I have ever used (maybe tinder is worse heh, but at least the keyboard latency is below a second.) It's almost comical how bad it is.
I used to think maybe it could have been before I was required to use it last year, but no, it's not. It is the worst chat application I have ever used (maybe tinder is worse heh, but at least the keyboard latency is below a second.) It's almost comical how bad it is.
Slack was described to me as IRC + tmux for people too stupid to figure out irc & tmux.
In my (limited) experience this seems true to me.
In my (limited) experience this seems true to me.
Could your view be slightly tinged by being required to use it at work?
I've used Slack for a couple years in purely open source / social / educational settings and can't really fathom how it could be described as comically bad. There are aspects I dislike, but overall it feels like it solves pretty well the problem it set out to address.
A lot of the hate seems to be around the the fact that it gives employers yet another method of disturbing work flow and creating accountability around meaningless metrics (response time or participation in pointless chats).
Instead of increasing productivity, it turns the entire workday into a meeting, with all the downsides of a traditional meeting.
But, again, those are all complaints about the setting and expectations surrounding the product, not the product itself. Slack is quite good at what it does, by any reasonable measure in my view.
I've used Slack for a couple years in purely open source / social / educational settings and can't really fathom how it could be described as comically bad. There are aspects I dislike, but overall it feels like it solves pretty well the problem it set out to address.
A lot of the hate seems to be around the the fact that it gives employers yet another method of disturbing work flow and creating accountability around meaningless metrics (response time or participation in pointless chats).
Instead of increasing productivity, it turns the entire workday into a meeting, with all the downsides of a traditional meeting.
But, again, those are all complaints about the setting and expectations surrounding the product, not the product itself. Slack is quite good at what it does, by any reasonable measure in my view.
If they had a top notch engineering team somebody should have tested their product on a non stable internet connection. Living out the country now and I now dream of going back to IRC just for the ability to read messages while offline.
These breaches were before Geoff (the interviewee) left Palantir and started at Slack, so it's possible things are in a better place now.
The idea that anyone could think of Slack as a "secure" communications platform is laughable. There's security and then there's security theatre.
Reasonably secure against crimes of opportunity, perhaps. Secure? Highly doubtful.
Reasonably secure against crimes of opportunity, perhaps. Secure? Highly doubtful.
Are there any known security vulnerabilities or incidents you can elaborate?
We tried out Slack recently. I was reticent to replace our existing XMPP server with an external service for security reasons. When I started the Electron-based desktop app, it tried to connect to lots of third-party services. That was enough to scare me away: https://twitter.com/mcculley/status/941728005617078272
I recently had a quick look at mattermost, zulip, matrix and rocket.chat. Of them, rocket.chat was the only one I could get up in 5 minutes, just from a docker-compose file. I assume they're all similar for a full production set-up - but for a dev test, rocket-chat came out far ahead.
Mattermost actually have a dockerized setup - but it didn't work without more fiddling than I cared to do for a test run.
I'm not all that happy about rocket being a meteor/mongodb app - but if you for some reason want to move away from a working xmpp setup (why?) to something slack-like, you might want to take rocket for a spin.
I've seen people complaining that the clients for rocket are bloated - but afaik they're not as bad as slack (I've just used the Web front-end and Android client).
A curious fact: from the wording on the doc page, you might think this needs a lot of twiddling ("Create docker-compose.yml based on our example..."). But it's clearly commented, and someone apparently verified that it actually works :)
https://rocket.chat/docs/installation/docker-containers/dock...
Mattermost actually have a dockerized setup - but it didn't work without more fiddling than I cared to do for a test run.
I'm not all that happy about rocket being a meteor/mongodb app - but if you for some reason want to move away from a working xmpp setup (why?) to something slack-like, you might want to take rocket for a spin.
I've seen people complaining that the clients for rocket are bloated - but afaik they're not as bad as slack (I've just used the Web front-end and Android client).
A curious fact: from the wording on the doc page, you might think this needs a lot of twiddling ("Create docker-compose.yml based on our example..."). But it's clearly commented, and someone apparently verified that it actually works :)
https://rocket.chat/docs/installation/docker-containers/dock...
Slack gets hacked in 3... 2... 1...
In all seriousness, and as much as I'm willing to assume that they've a good team, the title is cringeworthy.
In all seriousness, and as much as I'm willing to assume that they've a good team, the title is cringeworthy.
Slack has been hacked before. Previous discussion on HN:
https://news.ycombinator.com/item?id=9277370 (March 2015)
https://news.ycombinator.com/item?id=9277370 (March 2015)
More like "How Slack Thinks It Stays Secure..."
A sophisticated attack against Slack would be for the purpose of maintaining long-term access to chat data. There's no reason to believe Slack would ever be able to detect someone exfiltrating chat logs. They might catch some attacks but customers can not rightly expect that that their privacy is being maintained. Data being stolen is more likely than not.
Slack chat should be treated like semi-public communication, with the expectation that it will all end up in a torrent file at some point.
The idea that you can "secure" unencrypted text chats using a Security Team with Executive Leadership is pure theater. If Slack took security seriously it would utilize end-to-end encryption.
A sophisticated attack against Slack would be for the purpose of maintaining long-term access to chat data. There's no reason to believe Slack would ever be able to detect someone exfiltrating chat logs. They might catch some attacks but customers can not rightly expect that that their privacy is being maintained. Data being stolen is more likely than not.
Slack chat should be treated like semi-public communication, with the expectation that it will all end up in a torrent file at some point.
The idea that you can "secure" unencrypted text chats using a Security Team with Executive Leadership is pure theater. If Slack took security seriously it would utilize end-to-end encryption.
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.
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.
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.
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.
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
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
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.
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.
> 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?
So you’re opposed to Gmail and Outlook as well? Do you run your own mail server? Does your organization?
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...
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.
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.
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.
> 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
that's not unreasonable at all
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
God forbid our 7 billion transistor 20 core Xeon CPUs actually search through a few MB of text efficiently! </facepalm>
[deleted]
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.
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.
Especially not if I just want to quickly check my messages from a web browser.
Okay, show me an end to end platform I can grep through.
[deleted]
You do want and have E2E encryption in Slack in transit. And the case can be made that wanting it at rest is just as important as authorities change over time.
[deleted]
I’m having trouble fully understanding your argument. Is your argument that all non e2e communication is insecure, or that slack is incompetent? If it’s the former, should I consider tools like Gmail, and the google security infrastructure as security theater? If it’s the latter, then why?
The idea that I should expect all my gmail messages to end up in a torrent somewhere is a pretty audacious claim. I don’t pretend to believe that it won’t happen, but if it does, I can’t pretend I would have been more prepared than google when it comes to hosting my own email.
The idea that I should expect all my gmail messages to end up in a torrent somewhere is a pretty audacious claim. I don’t pretend to believe that it won’t happen, but if it does, I can’t pretend I would have been more prepared than google when it comes to hosting my own email.
> Is your argument that all non e2e communication is insecure
I think this. (In the context of a company, communications where the company doesn't hold all the keys.) Insecure modes aren't useless. But they certainly shouldn't be used to share sensitive information.
I think this. (In the context of a company, communications where the company doesn't hold all the keys.) Insecure modes aren't useless. But they certainly shouldn't be used to share sensitive information.
E2E encryption fails on a large number of subjects when it comes to a chat application such as Slack.
One of the simplest issues I can see is the search functionality, something I use daily in Slack and would sorely miss not having. Elasticsearch requires access to the contents of a message to index it (basic requirement).
Another thing that would become difficult would be adding people to a group, although my technical knowledge in this area is perhaps not massive, my thoughts are that if a user can join a group with another key, surely a Slack attacker would also be able to add their own key?
I'm sure there are many other things that ensure Slack cannot be E2E encrypted since it stops a significant amount of the logic they can do (they would become a dumb proxy), similar to why Google hasn't gone E2E.
One of the simplest issues I can see is the search functionality, something I use daily in Slack and would sorely miss not having. Elasticsearch requires access to the contents of a message to index it (basic requirement).
Another thing that would become difficult would be adding people to a group, although my technical knowledge in this area is perhaps not massive, my thoughts are that if a user can join a group with another key, surely a Slack attacker would also be able to add their own key?
I'm sure there are many other things that ensure Slack cannot be E2E encrypted since it stops a significant amount of the logic they can do (they would become a dumb proxy), similar to why Google hasn't gone E2E.
> E2E encryption fails on a large number of subjects when it comes to a chat application such as Slack
As I said, not every communication mode must be secure. Slack trades off security for other features, and that is okay.
It's odd for Slack to be beating their chest, however, about staying secure when security is not a feature they optimize for.
As I said, not every communication mode must be secure. Slack trades off security for other features, and that is okay.
It's odd for Slack to be beating their chest, however, about staying secure when security is not a feature they optimize for.
> If it’s the former, should I consider tools like Gmail, and the google security infrastructure as security theater?
Isn't that obviously true? It's clear that your data can be taken from you and sent to whoever they want at any time, all without your knowlede. Either by Google themselves, or a malicious actor who has access to Google's data.
How is this not the very definition of insecure?
Don't get me wrong, securing your own server isnt for everyone, but Google is an already known compromised system.
Isn't that obviously true? It's clear that your data can be taken from you and sent to whoever they want at any time, all without your knowlede. Either by Google themselves, or a malicious actor who has access to Google's data.
How is this not the very definition of insecure?
Don't get me wrong, securing your own server isnt for everyone, but Google is an already known compromised system.
A fun dinner conversation is to ask people how we know what the crime rate is. "Crime is down." they say. Is it?
The crime rate is hinged on when a crime is detected. If I'm forgetful and you snag one of my power bricks I might just think I misplaced it or it got thrown away. If you've been embezzling and I can't tell yet I can't report it.
Crimes are being committed whether they get reported or not. We count on them having personality flaws like poor judgement and thrill seeking assuming they will eventually be caught. But if there are people who can go into a casino once a year and spend exactly $100, why can't there be criminals who steal $100 once a year and never get caught?
The crime rate is hinged on when a crime is detected. If I'm forgetful and you snag one of my power bricks I might just think I misplaced it or it got thrown away. If you've been embezzling and I can't tell yet I can't report it.
Crimes are being committed whether they get reported or not. We count on them having personality flaws like poor judgement and thrill seeking assuming they will eventually be caught. But if there are people who can go into a casino once a year and spend exactly $100, why can't there be criminals who steal $100 once a year and never get caught?
Off topic, but you get around this problem by surveying people's experience of crime, rather than look at police reports.
In the UK the survey is called the British Crime Survey and it's pretty robust in it's methodology (although not without criticisim). https://en.wikipedia.org/wiki/Crime_Survey_for_England_and_W...
In the UK the survey is called the British Crime Survey and it's pretty robust in it's methodology (although not without criticisim). https://en.wikipedia.org/wiki/Crime_Survey_for_England_and_W...
It's so off topic that you're not even talking about the same problem when you say "you get around this problem"
What a confusing post.
What a confusing post.
I really don't see this as anything other than a gotcha argument and I feel bad for anyone you tried to use it on who couldn't defend themselves in the heat of the moment.
The crime rate is a known political tool that is actively manipulated for political gain (stop and frisk anyone?). Everyone knows that being "tough on crime" is moral statement not a statement of fact. Outside of crime averages that operate on a continuum the crime rate is so subjective as to almost be useless.
I would say "the crime rate is down" as an argument is roughly equivalent to believing that any given president has an impact on the DJIA. Look at the cover of the NYPOST yesterday[0]. Attributing a president who has been in office for a year with anything having to do with the economy is almost always untrue [1]. In fact, if anything it's more likely that Trump is benefiting from the policies of his predecessor.
So in conclusion the "crime rate" is never up or down, it's just one tool in the political handbook to try and manipulate people with fear, uncertainty and doubt. As a basis of establishing policy it's almost always rhetoric. To further elaborate on your comment, it has less to do with when a crime is "detected" and more to do with what is a crime.
[0] https://i.imgur.com/uifDjWI.png
[1] https://fivethirtyeight.com/features/a-presidents-economic-d...
The crime rate is a known political tool that is actively manipulated for political gain (stop and frisk anyone?). Everyone knows that being "tough on crime" is moral statement not a statement of fact. Outside of crime averages that operate on a continuum the crime rate is so subjective as to almost be useless.
I would say "the crime rate is down" as an argument is roughly equivalent to believing that any given president has an impact on the DJIA. Look at the cover of the NYPOST yesterday[0]. Attributing a president who has been in office for a year with anything having to do with the economy is almost always untrue [1]. In fact, if anything it's more likely that Trump is benefiting from the policies of his predecessor.
So in conclusion the "crime rate" is never up or down, it's just one tool in the political handbook to try and manipulate people with fear, uncertainty and doubt. As a basis of establishing policy it's almost always rhetoric. To further elaborate on your comment, it has less to do with when a crime is "detected" and more to do with what is a crime.
[0] https://i.imgur.com/uifDjWI.png
[1] https://fivethirtyeight.com/features/a-presidents-economic-d...
Don't be intentionally obtuse. The point of the comparison was to highlight that lower detection of something doesn't mean less of it.
It is a poor comparison. If I'm being intentionally obtuse then the parent is being willfully disingenuous.
Lower detection of crime doesn't mean less crime and higher detection of crime doesn't mean more crime.
The point is the crime rate as a tool to understand the effectiveness of law enforcement is useless.
This is a common problem I see all the time in "fact based" circles. People care more about the fact that the needle is moving rather than questioning if they're even measuring what they think they're measuring.
Lower detection of crime doesn't mean less crime and higher detection of crime doesn't mean more crime.
The point is the crime rate as a tool to understand the effectiveness of law enforcement is useless.
This is a common problem I see all the time in "fact based" circles. People care more about the fact that the needle is moving rather than questioning if they're even measuring what they think they're measuring.
Context is everything.
How about
There's no reason to believe Slack would ever be able to detect someone exfiltrating chat logs.
How about
Crimes are being committed whether they get [identified] or not
It's basically advocating a conspiracy theory.
"Well, we can't PROVE someone isn't exfiltrating chat logs, therefore slack can't really be secure"
What is the value of this statement? How is it an indictment of slack's security?
From the podcast :
"Geoff also concludes that companies should encourage basic security hygiene rather than seek a silver bullet that does not exist."
So despite good law enforcement people get away with crimes. What exactly is the insight there? What is the actionable information for both slack and law enforcement of these "unknown unknowns?"
"Well, we can't PROVE someone isn't exfiltrating chat logs, therefore slack can't really be secure"
What is the value of this statement? How is it an indictment of slack's security?
From the podcast :
"Geoff also concludes that companies should encourage basic security hygiene rather than seek a silver bullet that does not exist."
So despite good law enforcement people get away with crimes. What exactly is the insight there? What is the actionable information for both slack and law enforcement of these "unknown unknowns?"
No, it's not advocating a conspiracy theory.
It's pointing out that you aren't very secure when you are operating in a model where it's even possible to leak all of your client records without even noticing.
Compare slack to something with actual end-to-end encryption and you'll start to see the difference.
It's pointing out that you aren't very secure when you are operating in a model where it's even possible to leak all of your client records without even noticing.
Compare slack to something with actual end-to-end encryption and you'll start to see the difference.
> If you've been embezzling and I can't tell yet I can't report it
This is why murders are a gold standard for crime statistics. Most people agree murders are bad. And the rate at which murders become disappearances tends to be stable across time in a given society (but not between societies).
This is why murders are a gold standard for crime statistics. Most people agree murders are bad. And the rate at which murders become disappearances tends to be stable across time in a given society (but not between societies).
This is almost exactly the same philosophical discussion as "if a tree falls in the woods and no one is around to hear it, does it make a sound?", except with politics mixed in for extra spice.
If your tree-death metric depended on the number of people who claimed to have heard a tree fall, tree deaths would appear to increase with greater numbers of hikers. Statistical polution is far from a purely philosophical issue...
It’s somewhat harder to be a Searchable Log of All (Company|Current) Knowledge if you utilize end-to-end encryption. Where are the ends?
This is my biggest objection to Slack. Give me an application/container/whatever I can run on our network instead. I do not trust them with my entire company chat history stored in plaintext on the same cluster as every other company.
I feel like more often than not, organizations apply this logic to SaaSes that offers on-prem installations, and choose the on-prem over the hosted solution...
only to leave the installation out of date with critical vulnerabilities and missing features that the hosted installation would be on top of.
only to leave the installation out of date with critical vulnerabilities and missing features that the hosted installation would be on top of.
There is nothing stopping an on-prem appliance from being able to automatically update. Of course, once you do that, you are again putting trust back into the third party, so you lose some of what you gained.
I don't think I've ever seen an on-prem application that self updated without manual intervention. I'm sure it exists, but it doesn't seem common.
Probably because in general self-updating goes against the control on-prem is supposed to give enterprises, especially when they're afraid of breaking critical workflows.
Probably because in general self-updating goes against the control on-prem is supposed to give enterprises, especially when they're afraid of breaking critical workflows.
If it's not exposed to the internet, an out of date on-prem is still better than everything on a massive centralized public vendor server that 5 nation states are hacked into.
GitLab had a permission escalation issue that I saw unpatched on an on-Prem install. Contractors accessing it via VPN (and even local employees) would have been able to access repos and actions they didn’t have permission to access.
And it’s not like nation states can’t attack companies directly.
And it’s not like nation states can’t attack companies directly.
Nation states only attack companies they care about. That's the point. Once you have your info on slack, you share the fate with the million other companies that nation states might care about.
If 5 nation states hacked into the centralized public vendor they'll find a way to get into someone's on-prem version of the same, especially if they are the type to let it go very out of date.
Nowadays there are excellent self-hosted alternatives (Zulip, Mattermost, Rocket Chat...).
That being said: A company-wide Discourse forum works much better for knowledge sharing and discussions.
That being said: A company-wide Discourse forum works much better for knowledge sharing and discussions.
Has anybody ever merged chat and forums? At least integrate them so tightly that switching back and forth is fluid.
That's not what they are ever going to provide, like the parent comment indicated because it isn't their goal. Companies or individuals which need your requirement should/are already using a competitor that does allow you to do so, with all the limitations that the extra security gets you (search, integrations, etc), e.g. mattermost or rocket.
Would allowing organizations to manage their own key(s) suffice? If all of the stored data was encrypted by the users (even if it was a single key for a client organization), that would do a lot. You would have to compromise the private key(s) for the organization as well as Slacks (now useless) data.
> Would allowing organizations to manage their own key(s) suffice?
No. Slack does not implement searching logic on the client. If the key is only known to the client, and the search logic is only known to the server, you can't search anything.
End-to-end encryption is fundamentally incompatible with server-side search, because it mandates that the secret key can never leave the client. You can't reconcile these two features without efficient homomorphic encryption (which does not exist yet, and will not exist for the foreseeable future in any practical sense).
No. Slack does not implement searching logic on the client. If the key is only known to the client, and the search logic is only known to the server, you can't search anything.
End-to-end encryption is fundamentally incompatible with server-side search, because it mandates that the secret key can never leave the client. You can't reconcile these two features without efficient homomorphic encryption (which does not exist yet, and will not exist for the foreseeable future in any practical sense).
It could be compatible with hosted server-side search, no? (Requiring a certain amount of trust that it doesn't phone home, but that's true for a search-less encrypted client as well.)
The move to 3rd party hosting for super-sensitive internal stuff like this baffles me.
The move to 3rd party hosting for super-sensitive internal stuff like this baffles me.
Yes, that would be fine and is fully realizable. In the client-server model of end-to-end encryption, a server self-hosted by the user is isomorphic with a user's client. They're effectively the same thing.
The tricky part here is defining who the user is. If you're implementing end-to-end encryption for data on a per-employee basis, you're back to square one with a self-hosted server. But if you're implementing end-to-end encryption for data on a per-organization basis, and the organization has a self-hosted instance it controls, then yes, end-to-end encryption is compatible with organization-wide message search.
The tricky part here is defining who the user is. If you're implementing end-to-end encryption for data on a per-employee basis, you're back to square one with a self-hosted server. But if you're implementing end-to-end encryption for data on a per-organization basis, and the organization has a self-hosted instance it controls, then yes, end-to-end encryption is compatible with organization-wide message search.
Could work for limited search. For example each term in search index encrypted by the company key. Client passes is also encrypted search term.
Actual content of the messages could be encrypted separately. Client would send separately the selected terms for indexing and the content for each message.
Actual content of the messages could be encrypted separately. Client would send separately the selected terms for indexing and the content for each message.
How does Slack provide a search service if the data is encrypted by keys they do not control?
The client incrementally builds a search index, encrypts it using an appropriate random access encryption primitive, and writes it to the cloud encrypted. At search time it reads as necessary from the encrypted index. (This allows some light traffic analysis; if you can't tolerate that the client can store a copy of the entire index)
What search implements this?
run the tokenizer on the client side, client submits encrypted tokens to the search index.
or don't provide a search service, have client have its own local index.
or don't provide a search service, have client have its own local index.
> run the tokenizer on the client side, client submits encrypted tokens to the search index.
That would be an incredibly insecure method of encryption.
> or don't provide a search service, have client have its own local index.
Yep, I would prefer an on-prem solution.
That would be an incredibly insecure method of encryption.
> or don't provide a search service, have client have its own local index.
Yep, I would prefer an on-prem solution.
I see your point. Is it possible to achieve that type of functionality with a reasonable expectation of security?
Well, if you want slack to be able to search chats history, it needs to be able to access it in some way.
So if your 'resonable expectation of security' involves slack not being able to read your chat history, you are going to have to give up search.
Otherwise, the reasonable expectation of security will have to rely on trusting slack to properly secure their side of things.
So if your 'resonable expectation of security' involves slack not being able to read your chat history, you are going to have to give up search.
Otherwise, the reasonable expectation of security will have to rely on trusting slack to properly secure their side of things.
[deleted]
It seems like being a searchable log of all company knowledge would make it super important to have encrypted.
End-to-end encryption with full search and chat history is pretty hard to do.
How hard would it be for the Russian or Chinese governments to install one of their top programmers into a high-value target like Google, Facebook, Slack, etc and have them introduce subtle bugs that could be used to crack into the private data? If they're not doing this right now I would be shocked.
I think that’s an extreme position that priorities some platonic ideal over form, function and utility.
It’s certainly reasonable to expect a platform owner to be able to control access and integrity of customer data without encryption, for many use cases.
It’s certainly reasonable to expect a platform owner to be able to control access and integrity of customer data without encryption, for many use cases.
The day Slack is compromised will be a fun one...
It's such a high-value target that it's almost inevitable.
It's such a high-value target that it's almost inevitable.
I thought it has been: https://www.wired.com/2017/03/hack-brief-slack-bug-everyones...
I would be shocked if there aren’t 2 or 3 intelligence services in there already.
The Windows client is buggy as hell. It makes me wonder how many security flaws there are in there...
Don't poke the bear
If you use slack:
1) create a slack channel name not related to you or your company. EG. channel name 'foobarindustryyys'
2) require all users to use anonymous emails
3) delete the channel once a month
EG. If you run on eagames.slack.com you will get owned. Horribly.
1) create a slack channel name not related to you or your company. EG. channel name 'foobarindustryyys'
2) require all users to use anonymous emails
3) delete the channel once a month
EG. If you run on eagames.slack.com you will get owned. Horribly.
Again, no hate for Slack -- growing as fast as they have is an incredible feat. But heavybit is, um, pushing the definition of "secure" with that title. LOL.
* https://slackhq.com/march-2015-security-incident-and-the-lau... * https://www.wired.com/2017/03/hack-brief-slack-bug-everyones...