What If All Your Slack Chats Were Leaked?

From the guidelines:

>> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

I don't know if it is generally discouraged on HN, but let me just say that I find link-only answers discouraging (similar to lmgtfy) and of little value if you don't highlight the important bit. Additionally, your link is about a particular hashing scheme. Someone with no clue what hashing is will not be helped by a link to a particular hashing scheme. The first link in the article, however, gets you to a page that explains everything, and might have been a much better text to cite and link:

> Password verification commonly relies on cryptographic hashes. Storing all user passwords as cleartext can result in a massive security breach if the password file is compromised. One way to reduce this danger is to only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. A password reset method is required when password hashing is performed; original passwords cannot be recalculated from the stored hash value.

https://en.wikipedia.org/wiki/Cryptographic_hash_function#Pa...

> What if all your search history were leaked? What if all your text messages were leaked? What if all your emails were leaked?

But I can directly go into all those things and delete at least my copies of them. Even with as many problems as Google and Facebook have, it's relatively straightforward to see the entire history of what I have on their sites and delete it.

> As usual, it's not that serious, and there isn't a problem here.

Quoth the article,

> Everything beyond that 10,000-message limit remains on Slack’s servers. So while those messages might seem out of sight and out of mind, they are all still indefinitely available to Slack, law enforcement and third-party hackers.

So I can't go back and check those on any free Slack server I post on.

And if someone decides to pay Slack for one of those servers, blam, any convo that got heated but that I forgot about is now visible to anyone with an axe to grind.

We've seen 10 year old tweets dredged up to go after people of all stripes, so this is certainly a thing that happens.

This may be a taboo take on systems like Slack and I know this will not be popular given the number of developers here, but I had to explain this to HR and it was not easy to convey these concepts in plain terms.

Slack itself is just a chat system. Ok, what's the risk? By design, people (the user base, or admins, up to each company) can integrate third party applications. The permissions system allows chat data to flow to these third parties without any logging or visibility by the Slack business customer. So in effect, each employee (depending on perms) may on behalf of their company, relay all chat messages to third parties that their company does not have a legally binding agreement and NDA with. This is the actual risk with Slack (the product, not the company).

So by design, employees can leak all the chats for all of the #public channels they are a member of and they won't even see it happening. Some companies choose to have admins review the third party applications and integration. "But they are #public, right?". People in a company don't assume that the public channels are really public in the sense that third parties outside of their company can see these messages. Employees may discuss very sensitive topics about their own customers that may not be appropriate to relay to extended parties that their company does not have mutually binding agreements and NDA's with.

When you run your own servers such as IRC, Mattermost, etc.., the chat admins know what third party servers (if any) they are linking to. This does not preclude an employee from relaying their own data through their workstation, but that can be addressed by edge DLP devices for monitoring or mitigation. Even then, the employee knows exactly what they are relaying.

When the chat system itself is a third party, and that third party allows relaying of user data, chat data to fourth parties, then by design, the system will always leak data. Slack does not alert members in a channel which bots are reading their messages real time and where that data is being stored and who is reading it and for what purpose. This also becomes a problem for data retention policies. The parties external to Slack may retain and use the data for as long as they wish, even if Slack purge data from a channel after a period of time. I see this as a legal quagmire.

In terms of leaking private messages, those are also stored so that an admin in a company may review them by request. This is only an issue if Slack's servers were compromised. That risk applies to both self hosted and third party chat servers, though Slack becomes a much more juicy target by having the private chats of many companies. This is similar to the risk of routing non-static content through Akamai. Akamai had employees caught selling sensitive data to other nations which highlights the risk of aggregating private data through one transit provider that can decrypt your data or see your data in plain text. This risk could be mitigated by having short data retention policies, however that is the opposite of what users expect. They expect their messages to be around forever.

No, you absolutely can't delete your search history, which Google stores in perpetuity, and you can't delete the copies of your SMS messages that sit on some server somewhere, probably forever. All you can do is make it inaccessible in the app or web page you as the user can view it from.