> I guess there's also the problem of how to let a new joiner view previous messages. Can that be done with e2e encryption?
Of course. Share the key with a new joiner. Probably should be an option for admin, whether he wants to share (share the key) or does not want to share (generate new key and use it since that moment, old clients still remember old keys and can decrypt things).
Granted, I don't know much about encryption, end-to-end messaging, or otherwise, but it seems like a Very Hard Problem to solve for something like Slack.
> it seems like a Very Hard Problem to solve for something like Slack.
There are plenty of messengers with E2E encryption and group chats with working search. Sure, it's not a straightforward task and server-side handling of search and other functions makes everything much easier, but I don't think that it's impossible task.
Though I'm not sure if demand is big enough. I would think that just self-hosting slack would be preferable for many organizations.
Honest question - how does this work across thousands of employees, some of which are almost guaranteed to be bad-actors at one point? Or is that just not a problem that's trying to be solved? What are the impacts if someone leaks that?
> There are plenty of messengers with E2E encryption and group chats with working search.
I don't know - are they on the (user) scale of Slack? How many people can you add to a group in WhatsApp or iMessage? (I honestly don't know, but I would suspect Slack lets you have more people in a 'group' than them).
Again, I have only a very cursory knowledge of how iMessage does E2E encryption. Obviously Slack would need to choose a different approach, but I wouldn't look at other messaging apps for examples.
Yes, that could be done with e2e encryption. Typically a setup would use one secret key for crypting one (set of) message(s) and that key would be encrypted in a way that all authorized users can decrypt it. A new user then only needs access to the group key, which can be done cheaply (by anybody with access to the group key and all user's public keys)
Unless the channels you’re on amount to at least one Bible-length document per day and you’re trying to index multiple years of content, the storage requirements for an index aren’t going to be a problem.
So, is each web client going to download the full history so it can build an index? I like being able to login from anywhere, but building a local index could take some time, and I definitely don't want that to happen when I first open slack in the browser.
They could, but I don't think it would really add much benefit. One of the main features of Slack vs IRC is that Slack has persistent and consistent chat history. If you look at apps like Signal, when you log on from a new device your history isn't available, because of the end to end encryption used to store the messages. To view the history you would have to be able to decrypt it, but that means there has to be some mechanism for users joining a channel for the first time to decrypt the history of that channel (unless you want to break that functionality). Unless there is some really neat cryptography trick I'm not aware of, that would mean you can't have end to end encryption where each user's data is encrypted in a way that is opaque to everyone except user(s) in the chat like Signal or Telegram.
Now I guess you could set up some kind of broker system and have like a different encryption key per channel or per conversation or something, which would at least mean some hacker has to get both the archived chats as well as the keys. This would make stealing chat histories more complicated, but not less possible.
In iMessage this was possible but all combinations of pairs of your devices had their own keys. When a new device was added you needed to allow it from a device already registered and they would then sync messages device-to-device. This has resulted in quite a lot of mangled histories.
Now with iMessage in iCloud, I do not know how the E2E encryption is done.
I've read some discussions and key base articles and it seems that at least the master key is encrypted using your pin code. Not much, but I guess one could use a complex password.
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
> During an interview with Apple blogger and Daring Fireball’s owner John Gruber, Federighi said that the company has figured out a way to do syncing while still remaining unable to read your iMessages.
Slack offers the ability to encrypt messages with your own key, managed in your own AWS KMS account, so chat history and search still work until revoked for a particular channel or time period :
A read over Keybase's blog [1] makes one realize how non-trivial building a secure team chat is.
We're still at a point in time where 99% of communities are ready to make exactly 0 compromise for privacy over usability. Slack is catering to the 99%.
If one definition includes "the server(s)" then I'm positive it does at least on their Enterprise product, which notably last time I looked was the only one that could be considered HIPAA-compliant, aka "no your two - site medical practice can't use Slack to chat between the sites and coordinate anything involving patients."
What if all your search history were leaked? What if all your text messages were leaked? What if all your emails were leaked? I guess those things aren't trendy enough to worry about.
For a long time I have noticed what I would call 'ankle biting journalism'. Basically take whatever is trendy, make only the most obvious observations about it (things that someone who only rudimentary knowledge would come up with in a few minutes), then act like these obvious things are serious and there is a problem here.
As usual, it's not that serious, and there isn't a problem here. I have no idea how Slack stores user chat history, but lets say they store them in plain text in the cloud. Then Slack is about as secure as IRC, which is exactly what it is trying to be, IRC 'but better'.
Besides, if you are using Slack for work, whoever is the 'Owner' of the enterprise account can export and view every conversation whenever they want, because 'compliance'.
So, I think this is a problem and that encryption and data security policies and audits would be a good thing. But your parent's point also resonated with me. This isn't a shocking expose of some giant new problem. Protecting proprietary communication has been a problem for as long as organizations have existed. It was a problem when the solution at Los Alamos was safes in offices, it was a problem with memos, it was a problem with faxes, then emails, and now, yes, Slack chats. It's a problem, people should work on it, but it's not news.
I mean, this is a good philosophical question, and I think the answer tends to just be "whatever a news organization decides to write about", so clearly this counts.
But I think what makes for interesting news are things that are new and non-obvious. The point of the thread starter (which resonated with me) is that this is neither. What rubs me wrong about the article is that it lacks context. From just this article, this sounds like a novel threat. But it's ludicrously far from that. You could write the same article about every communication system used by every business ever. For instance, tons of important stuff is still required to be done by fax, which is far less privacy-preserving than Slack. Email remains pretty much universally unencrypted.
The article doesn't try to grapple with this context at all, which makes it read oddly to me.
Edit: I should have pointed out that the article doesn't say they don't encrypt the data, it just says they don't end-to-end encrypt it, which by definition would require it to be impossible for Slack or anyone else to read the messages (other than the users who sent them or were in the channel at the time they were sent). Only a handful or recent apps like Signal and Telegram even attempt to do this.
Any form of communication (or really any form of information storage) could be sensitive, that's my point exactly. There's literally no reason to mention Slack other than it's hot and the author could glom onto a trendy brand name to get people to read an article that is basically devoid of any novel content.
If a new sport which merges football, basketball, and chess become popular, we would see a bunch of articles 'People Who Play Chessketball are Getting Injured'. 'Chessketball has an Injury Problem'. 'Things you Need to Know before you Let Your Children Play Chessketball' Yes, people are more likely to be injured whenever they participate in any physical activity. Also when they ride a bike or go for a jog. Also, it turns out, if they don't do any physical activity at all they will suffer from heart disease.
"In hindsight, complying with the company's Document Retention Policy (which at Netscape was basically, ``shred anything within 90 days unless you can't get your job done without it'') might have been a good idea." [1]
Do companies no longer have Document Retention Policies? That seems like the bigger piece of the story here.
It depends on the information that’s flowing in them. If they are under compliance purview then they might have to retain or at least archive years worth of information.
FYI if you're referred from hackernews and have never visited the site before, the jwz links redirect to (somewhat nsfw: photoshopped testicle in an egg cup) http://i.imgur.com/32R3qLv.png.
I would assume this article was "paid for" (perhaps not directly) by someone with a vested interest. E.g. a competitive vendor with a better security story, or whoever is having their legacy lunch eaten by Slack.
>> 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."
The problem you mention is different, and the severity is as high as the most sensitive content that's been posted.
As is the case with most chat platforms, the technical safeties put in place only serve to protect _legitimate_ users. The problem you're referring to is a matter of _illegitimate_ users or _insider-threats_.
* What if I copy-paste a sensitive conversation to a third-party?
* What if I export conversations or user accounts to a third-party?
* What if I grant an unauthorized party access to a conversation that they wouldn't otherwise be able to see?
In-transit encryption and encrypted storage do not solve these issues, because an insider threat inititated the action.
> 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.
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.
1. the mostly anonymized logs that require a technically difficult crack and would impact many thousands (millions?) of people simultaneously.
2. activity that can be tied directly back to individuals by anyone with time on their hands.
You're absolutely right that there are servers maintaining logs and such, that aren't accessible, but they fall into #1. And category #1 can happen, the famous cheating website being cracked as a great example. But that was itself relatively exceptional since simply being a user was enough to end in divorce.
The Slack message history distinctly falls into #2. It's a far more immediate problem.
Everything they have published shows that you can delete search history, among other things. They recently released a feature which is effectively a TTL on searches, for retention purposes.
What you say is all true, but some kind of end to end encryption would reduce the risk, or at-least impede mass leaking of data. That seems to be the entire point of the article.
First thought: who the hell would be interested to read thousands of lines of discussions like how to name a field in REST response or notifications of someone making a build xD
Netscape, 1998: "And I keep thinking to myself, Microsoft is going to pay some jackass lawyer $200 and hour to find out that we hate our cafeteria food, don't like the security posters, had a sucky newsfeed, and think ``Navigator'' was a cooler name than ``Communicator''." [1]
Just because you don't think you have anything interesting doesn't mean a competitor isn't going to subpoena it years later.
Edit: That was before I read the article. He rants, with apparent sincerity, about the politically correct losers who thought that having an official, internal anything-goes-flamefest vent forum was a bad idea; describes how he went to great lengths to preserve it; finds out exactly why it really was a bad idea (it got subpoenaed so Microsoft could rake it for dirt); and then rants about that. At no point does he show any awareness of the irony.
Nobody, but it's not about that. It's about trade secrets, access keys for e.g. AWS, git; it's about private information that can be used for social engineering or extortion. If a malicious actor can take over someone's account they could do even more convincing social engineering and access confidential information.
If you think "I have nothing to hide" you're lacking in imagination.
A variation of this argument always seems to come up in discussions about privacy.
Yes, 99.9% of what you do or say in your daily life is likely of no consequence. But every now and then you may do or say something that could be used against you, and someone who has many years worth of data collected on you can probably find quite a few such bits of info.
Among all of your internet "transactions" probably less than 0.1% are with your bank, for instance (sending your credentials, etc). You want end-to-end encryption and good security to protect that 0.1% of your data, not for the other crap.
People rant about coworkers and managers, complain about their spouses, joke about doing something illegal/stupid, compare themselves (favorably or not!) against a competitor, and share the occasional off color story/picture with a friend.
Should those things happen on corp systems/network? Most of them, no. Do they? Absolutely.
When we do those things, we don't think about it because we all have the immediate context, feelings, and stress of the situation in addition to knowing the other person involved.
If an opposing attorney or law enforcement reads it years later without the context and knowing the people, they can't interpret it the same way.
I sincerely do not believe that. Somewhere in there is a joke like "They trust me with their data. Suckers" - Mark Zuckerberg. An obviously tongue-in-cheek comment that can be interpreted in a different way.
Lots of people believed what you did, but you only need to have said one thing.
The single most terrible thing about Slack is the hostage holding of message archives. You don’t pay? Fine...you get 10k message history, no ability to set retention and Slack still stores all those messages forever, taunting me that they have it all and won’t let me do anything with them.
That’s just user hostile. If I don’t pay, I shouldn’t have all that message history stored forever. Either let me set retention on my messages or delete anything over 10k automatically. Don’t hold my content hostage and make it completely inaccessible and un-deletable unless I pay.
I worked on a project a while ago that used this as a feature. They were worried about a Freedom of Information request for chat archives (UK Govt linked) so intentionally didn't pay for Slack, so most of the message history wasn't available if a request came through.
>intentionally didn't pay for Slack, so most of the message history wasn't available if a request came through.
I'm pretty sure that won't work. They keep the logs regardless of whether you pay. It's not like if you don't pay for it, they erase your messages starting at 10k. You can't see it, but upon paying for slack premium, you'll immediately get access to them.
It was sort of helpful for us. We (a bootstrapped small business) remained on the free tier for a few years before upgrading and getting access to all history.
We might not have bothered if the history was simply deleted. I was grateful they didn't as there are some great moments in there, i.e. our first invoice, announcement of our first member of staff, prototype renders, etc.
I've been spending all these years holding my tongue because as a matter of principal I don't write anything I don't want a permanent record of and it would be nice to see all that overhead pay off or more accurately, it would be nice to see people get burned for being sloppy. So no, I wouldn't really stand to lose anything if everything I ever said on company chat was published in an easily searchable format online.
1) Very few Slack users are chatting as though their messages could become public at any moment. Maybe you don't have a problem, but this article isn't about one person with extreme discipline.
2) There's no way to know now what you'd want to be private in the future.
For example, let's say you're gay and mention your boyfriend casually in a Slack chat. Then your country outlaws homosexuality. Suddenly, a casual detail becomes a secret you're terrified of getting out.
You can apply this analogy to your religious beliefs, traveling to certain countries, or even reading certain websites. You just don't know what the public or your govt will find unacceptable in the future.
I mean, the article is generally right but they immediately get a detail wrong:
> Right now, Slack stores everything you do on its platform by default — your username and password ...
I would be extremely surprised if they store plaintext or even encrypted passwords. Maybe the author means usernames/passwords sent in messages, but that's not unique to slack.
fwiw, when I have to share a password or api key in a DM once the party acks receipt I then delete the message. Unless a snapshot is taken in the interval I reason that there won't be a persistent copy left behind.
Does anyone 'behind-the-curtain' know anything that would contradict my assumptions?
This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
Why would you assume that? I (as the 'designer' of a couple of distributed event-sourced systems), will create a message (as an event) that ricochets around to update several SQL and non-SQL systems that are normalized or denormalized views, or what not. When a 'delete' command (event) gets sent around, that gets accepted by subscribers/listeners, and they 'mark' their respective 'column' equivalents as 'deleted', but in an append-only log, the idea that a disk block gets updated is kind of nonsensical.
The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses.
I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
If you mean the site-/team- administrator, that's probably right. (We have similar issues for HIPAA related reasons).
Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.
If they don't store the password encrypted or in plaintext, how would they be able to authenticate you? It must be stored somehow, either plaintext or encrypted (preferred).
An encrypted password can be reversed, a hashed password cannot, it can only be verified. An encrypted password is only slightly preferable to a plaintext one because you still need to store the password somewhere, which am attacker would theoretically have access to, so it mostly serves as obfuscation.
There's a difference between encrypted (implies can be decrypted) and hashed (a one way function which cannot be reversed).
In general, I shouldn't be able to tell you your password, I should just be able to tell you if the password you just gave me is the one you gave me before.
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.
Easy - I don't give a damn and have no expectation they won't be leaked.
To be clear, when I use Slack I assume private chats will remain private, but if they don't, well... screw it. It's not like I paid for it so how am I entitled to anything?
No vendor can promise they won't get hacked. What if your Linux OS got hacked due to a zero-day bug and all your DB data was leaked?
once worked for a start-up that went through a high amount of churn and employee turnover. one of the pain points was the know-how being locked inside Slack threads and we had hit the 10K message limit months before I joined. The place was also politically toxic and the CEO was mostly the cause of this. Initially when I had still some passion left I suggested to move Slack to a self-hosted Zulip installation (threaded topics FTW) because the CEO constantly complained about having to pay for Slack subscription and he was totally against this as somebody who believes in FOSS.
After getting this Zulip migration approved the CEO pulled the plug in the last minute because he realized during a discussion about how to handle the import of the original messages - that all the old (toxic) discussions would now be in the hands of his internal employees and they couldn't be trusted not reading all the shit him and everyone else said behind each others back.
This made me aware that Slack has some interesting reasons for why teams are locked into their SaaS platform which may have nothing to do with scalability or uptime. In our case it was fear of libel lawsuits and further turnover. While you might be able to live with the insider-threat at SlackHQ with them being able to read your messages, sometimes the idea that anyone in your IT can read everything management has said shared or discussed in the past may be too risky for most.
In case anyone runs into this in the future, Zulip has a few features that could help:
* You can set a message retention policy that will delete each message after N days. (We're building the UI for it, but currently you can email support@zulipchat.com for help on turning it on.)
* On Zulip Cloud, you can set a message visibility limit that will save all your messages (e.g. for legal/compliance reasons), but only the last N messages will be visible to the team.
> Slack is one of many Silicon Valley unicorns going public this year, but it’s the only one that has admitted it is at risk for nation-state attacks.
Gosh, everyone who runs a computer is at risk for nation-state attacks.
The real question is: how high is the risk?
The risk section of an S1 tries to list every imaginable threat as a risk, without any assessment of the probability or impact (the two components of risk). Using this is a source for such an article is simply wrong.
Has anyone attempted at building a chat solution, similar in scope to Slack, that runs serverlessly? I imagine it’s technically possible, but perhaps not a better self hosting option than something like Rocket.chat.
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.
I worked for a fortune < 10 company. One day I found a complete dump of all public AND PRIVATE slack messages sitting on a dev server that was open to all.
I reported it to security. Next day I'm suspended. Turns out security did it because they wanted to search through 'just in case' but didn't want to go through the process properly.
Either it was my fault or they were incompetent, guess which one they chose. I was forced to quit eventually.
Oh yes, and they played the long game until it was economically self destructive for me to continue. Never forget the time advantage a corporation has over an individual.
There seems to be a fundamental assumption here that's just completely wrong, and that is that there's a way to guarantee that your chat logs /email /search history /whatever can ever be 100% secure from disclosure. This is as wrong as assuming you don't need backup because you have RAID, excellent malware protection, are fully patched, have great sprinklers, are geologically stable, not in a flood plain, etc.
You need to start from the assumption that it can happen here and take steps to ensure that damage is minimal /recoverable. Part of that is policy, part culture, another part is technical but none are sufficient by themselves. On the tech side, look at systems designed to comply with data protection laws.
I didn't get that assumption from the article at all. (Unless you meant "on HN" instead?)
To me, the article's focus on permanently deleting old messages specifically avoids that error - it's not about avoiding disclosure but as defense-in-depth since disclosure is always a possibility. Beyond that, avoiding Slack (even with data deletion) is unlikely to increase security, but it does decrease priority for smaller users who might be swept up in an attack on Slack in general.
Slack seems like a huge single point of failure. The chat logs across who knows how many companies and groups all stored on a single set of servers by a single company. All it takes is one bad insider with the keys to the kingdom, or just a government backend into the system, and all the secrets are loosed. And who's to say Slack employees don't watch our chat logs already? I really don't get the amount of trust placed in Slack, especially in the IT industry where everyone is very aware of security.
Anonimnity is fake. Assume your conversations in Slack are reviewed, don't be mean and sneaky, and you're all set. If you're a true dick irl, Slack will only serve to magnify that fact.
- Anything written down and transmitted digitally will be available to anyone who wants it eventually. Besides my copy, the recipient has a copy, as do any number of intermediaries. Encrypted or not, that encryption will almost certainly be broken in my lifetime.
- Anything written down on physical medium or stored digitally (but not transmitted) will be freely available to anyone that wants it eventually. It's slightly more secure than a digital copy, because I have physical control over the only copy and would most likely know if that physical control was compromised (so my NAS is considered transmitted since it is possibly accessible).
- Anything I say to someone in person is pretty safe, depending on how much I trust them not to record what is said (otherwise it becomes classified as digitally transmitted). Of course now a copy remains in their mind's eye, which is in some cases worse since it can be modified and they don't even know it.
- Any thought I have that I have never expressed outside my body is almost completely safe, baring successful administration of truth serum (or until someone invents adversarial brain scans).
How does this affect me in real life? I don't write down things I wouldn't want other people to know, and I am pretty careful about saying things I don't want other people to know. I use encryption whenever I can because it will at least slow down the attackers, but I never assume something that is encrypted is safe.
In my hierarchy these two points are swapped. At least I think there is a real chance to keep written material secret as long as you are not a target of a state level adversary. I can write in a room where I am sure there are no cameras watching and I can put my copy in a safe where I would know if it was compromised. On the other hand I can almost never be sure not be audio recorded - be it deliberately or accidentally by any of the microphones that are almost everywhere nowadays.
I have a very similar list to yours. I'm also a datahoarder though, so I also have the reverse characteristics, i.e. if I don't have a copy then assume there are no copies left for me to ever access (assume adversaries have a backup though).
> - Anything written down and transmitted digitally will be available to anyone who wants it eventually. Besides my copy, the recipient has a copy, as do any number of intermediaries. Encrypted or not, that encryption will almost certainly be broken in my lifetime.
I completely agree. So we're now assuming that the information will exist indefinitely for adversaries (NSA warehouse), however if I don't have a copy then it's effectively gone (for me only).
> - Anything I say to someone in person is pretty safe, depending on how much I trust them not to record what is said.
I'm not quite there yet, but I've become leary of all the phones, laptops, cameras, personal assistants, etc. While I'm from the US (so mass spying is supposed to be illegal), and most companies like Amazon/Apple have been shown to be "mostly telling the truth" in terms of how they only transmit data after a trigger phrase, it's a lot of microphones.
Let's assume the person I'm talking to is 100% trusted, all it takes is a hacked Alexa to leak the conversation.
Likely or practical? Not really. Do I do anything specific such that I'd consider myself a potential NSA target? Not really.
But I consider privacy a human right so it's always something I'm thinking about.
126 comments
[ 6.1 ms ] story [ 182 ms ] threadI guess there's also the problem of how to let a new joiner view previous messages. Can that be done with e2e encryption?
512 GB
> How about on your phone?
256 GB
> I guess there's also the problem of how to let a new joiner view previous messages. Can that be done with e2e encryption?
Of course. Share the key with a new joiner. Probably should be an option for admin, whether he wants to share (share the key) or does not want to share (generate new key and use it since that moment, old clients still remember old keys and can decrypt things).
Granted, I don't know much about encryption, end-to-end messaging, or otherwise, but it seems like a Very Hard Problem to solve for something like Slack.
Yes, shared among participants.
> it seems like a Very Hard Problem to solve for something like Slack.
There are plenty of messengers with E2E encryption and group chats with working search. Sure, it's not a straightforward task and server-side handling of search and other functions makes everything much easier, but I don't think that it's impossible task.
Though I'm not sure if demand is big enough. I would think that just self-hosting slack would be preferable for many organizations.
Honest question - how does this work across thousands of employees, some of which are almost guaranteed to be bad-actors at one point? Or is that just not a problem that's trying to be solved? What are the impacts if someone leaks that?
> There are plenty of messengers with E2E encryption and group chats with working search.
I don't know - are they on the (user) scale of Slack? How many people can you add to a group in WhatsApp or iMessage? (I honestly don't know, but I would suspect Slack lets you have more people in a 'group' than them).
Again, I have only a very cursory knowledge of how iMessage does E2E encryption. Obviously Slack would need to choose a different approach, but I wouldn't look at other messaging apps for examples.
Now I guess you could set up some kind of broker system and have like a different encryption key per channel or per conversation or something, which would at least mean some hacker has to get both the archived chats as well as the keys. This would make stealing chat histories more complicated, but not less possible.
Now with iMessage in iCloud, I do not know how the E2E encryption is done.
It isn't done. Apple holds the master keys. The trust is that the iCloud server is not compromised.
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
https://pxlnv.com/linklog/improving-imessage-encryption/
> During an interview with Apple blogger and Daring Fireball’s owner John Gruber, Federighi said that the company has figured out a way to do syncing while still remaining unable to read your iMessages.
https://slack.com/enterprise-key-management
We're still at a point in time where 99% of communities are ready to make exactly 0 compromise for privacy over usability. Slack is catering to the 99%.
[1]: https://keybase.io/blog
If one definition includes "the server(s)" then I'm positive it does at least on their Enterprise product, which notably last time I looked was the only one that could be considered HIPAA-compliant, aka "no your two - site medical practice can't use Slack to chat between the sites and coordinate anything involving patients."
For a long time I have noticed what I would call 'ankle biting journalism'. Basically take whatever is trendy, make only the most obvious observations about it (things that someone who only rudimentary knowledge would come up with in a few minutes), then act like these obvious things are serious and there is a problem here.
As usual, it's not that serious, and there isn't a problem here. I have no idea how Slack stores user chat history, but lets say they store them in plain text in the cloud. Then Slack is about as secure as IRC, which is exactly what it is trying to be, IRC 'but better'.
Besides, if you are using Slack for work, whoever is the 'Owner' of the enterprise account can export and view every conversation whenever they want, because 'compliance'.
Does it have to be " a shocking expose"?
All the things you mentioned about communication seem to apply to this article.
But I think what makes for interesting news are things that are new and non-obvious. The point of the thread starter (which resonated with me) is that this is neither. What rubs me wrong about the article is that it lacks context. From just this article, this sounds like a novel threat. But it's ludicrously far from that. You could write the same article about every communication system used by every business ever. For instance, tons of important stuff is still required to be done by fax, which is far less privacy-preserving than Slack. Email remains pretty much universally unencrypted.
The article doesn't try to grapple with this context at all, which makes it read oddly to me.
Any form of communication (or really any form of information storage) could be sensitive, that's my point exactly. There's literally no reason to mention Slack other than it's hot and the author could glom onto a trendy brand name to get people to read an article that is basically devoid of any novel content.
If a new sport which merges football, basketball, and chess become popular, we would see a bunch of articles 'People Who Play Chessketball are Getting Injured'. 'Chessketball has an Injury Problem'. 'Things you Need to Know before you Let Your Children Play Chessketball' Yes, people are more likely to be injured whenever they participate in any physical activity. Also when they ride a bike or go for a jog. Also, it turns out, if they don't do any physical activity at all they will suffer from heart disease.
I don't think that because the topic is "hot" that makes talking about it "no reason other than".
I feel like there is a surprising volume of "oh man why did the author bring this up" type posts on HN, I don't get it. The topic seems valid.
I hope that stories like this continue so that e2e encryption is supported by any messaging platform that wants to be taken seriously.
Do companies no longer have Document Retention Policies? That seems like the bigger piece of the story here.
[1] https://www.jwz.org/gruntle/rbarip.html
Anything I write on IRC I assume is public. Not so with Slack, where much is written in DMs.
The email comparison is more apt.
>> 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."
As is the case with most chat platforms, the technical safeties put in place only serve to protect _legitimate_ users. The problem you're referring to is a matter of _illegitimate_ users or _insider-threats_.
* What if I copy-paste a sensitive conversation to a third-party?
* What if I export conversations or user accounts to a third-party?
* What if I grant an unauthorized party access to a conversation that they wouldn't otherwise be able to see?
In-transit encryption and encrypted storage do not solve these issues, because an insider threat inititated the action.
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.
1. the mostly anonymized logs that require a technically difficult crack and would impact many thousands (millions?) of people simultaneously.
2. activity that can be tied directly back to individuals by anyone with time on their hands.
You're absolutely right that there are servers maintaining logs and such, that aren't accessible, but they fall into #1. And category #1 can happen, the famous cheating website being cracked as a great example. But that was itself relatively exceptional since simply being a user was enough to end in divorce.
The Slack message history distinctly falls into #2. It's a far more immediate problem.
http://media4.giphy.com/gifsu/2w5ffEOlO1ni8ArLnq/giphy-overl...
http://nymag.com/intelligencer/2016/03/what-hulk-hogan-taugh...
https://splinternews.com/the-gawker-hulk-hogan-trial-and-the...
Just because you don't think you have anything interesting doesn't mean a competitor isn't going to subpoena it years later.
[1] https://www.jwz.org/gruntle/rbarip.html
Edit: That was before I read the article. He rants, with apparent sincerity, about the politically correct losers who thought that having an official, internal anything-goes-flamefest vent forum was a bad idea; describes how he went to great lengths to preserve it; finds out exactly why it really was a bad idea (it got subpoenaed so Microsoft could rake it for dirt); and then rants about that. At no point does he show any awareness of the irony.
What a guy.
If you think "I have nothing to hide" you're lacking in imagination.
Yes, 99.9% of what you do or say in your daily life is likely of no consequence. But every now and then you may do or say something that could be used against you, and someone who has many years worth of data collected on you can probably find quite a few such bits of info.
Among all of your internet "transactions" probably less than 0.1% are with your bank, for instance (sending your credentials, etc). You want end-to-end encryption and good security to protect that 0.1% of your data, not for the other crap.
People rant about coworkers and managers, complain about their spouses, joke about doing something illegal/stupid, compare themselves (favorably or not!) against a competitor, and share the occasional off color story/picture with a friend.
Should those things happen on corp systems/network? Most of them, no. Do they? Absolutely.
When we do those things, we don't think about it because we all have the immediate context, feelings, and stress of the situation in addition to knowing the other person involved.
If an opposing attorney or law enforcement reads it years later without the context and knowing the people, they can't interpret it the same way.
No. Privacy is not about your right to hide. It is about another's access to info about you, i.e. consent.
"If you've got nothing to hide" is pure misdirection. It doesn't matter one bit why I won't allow you access to personal info.
I do not owe you an explanation - if you want my data, you owe me one.
The sexualized commentary about employee V's nice boobs.
The CEO arguing that employee M be kept because he's got leverage and we should let employee Z go instead.
That discussion we had about the time a hacker got ahold of 4000 customer records but we paid them off to delete the records.
I dunno, pretty much the stuff that can break a company into nothingness.
(FYI those are not scenarios where I work)
Lots of people believed what you did, but you only need to have said one thing.
That’s just user hostile. If I don’t pay, I shouldn’t have all that message history stored forever. Either let me set retention on my messages or delete anything over 10k automatically. Don’t hold my content hostage and make it completely inaccessible and un-deletable unless I pay.
I'm pretty sure that won't work. They keep the logs regardless of whether you pay. It's not like if you don't pay for it, they erase your messages starting at 10k. You can't see it, but upon paying for slack premium, you'll immediately get access to them.
We might not have bothered if the history was simply deleted. I was grateful they didn't as there are some great moments in there, i.e. our first invoice, announcement of our first member of staff, prototype renders, etc.
2) There's no way to know now what you'd want to be private in the future.
For example, let's say you're gay and mention your boyfriend casually in a Slack chat. Then your country outlaws homosexuality. Suddenly, a casual detail becomes a secret you're terrified of getting out.
You can apply this analogy to your religious beliefs, traveling to certain countries, or even reading certain websites. You just don't know what the public or your govt will find unacceptable in the future.
> Right now, Slack stores everything you do on its platform by default — your username and password ...
I would be extremely surprised if they store plaintext or even encrypted passwords. Maybe the author means usernames/passwords sent in messages, but that's not unique to slack.
Does anyone 'behind-the-curtain' know anything that would contradict my assumptions?
This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses.
I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.
An encrypted password can be reversed, a hashed password cannot, it can only be verified. An encrypted password is only slightly preferable to a plaintext one because you still need to store the password somewhere, which am attacker would theoretically have access to, so it mostly serves as obfuscation.
In general, I shouldn't be able to tell you your password, I should just be able to tell you if the password you just gave me is the one you gave me before.
> 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...
To be clear, when I use Slack I assume private chats will remain private, but if they don't, well... screw it. It's not like I paid for it so how am I entitled to anything? No vendor can promise they won't get hacked. What if your Linux OS got hacked due to a zero-day bug and all your DB data was leaked?
After getting this Zulip migration approved the CEO pulled the plug in the last minute because he realized during a discussion about how to handle the import of the original messages - that all the old (toxic) discussions would now be in the hands of his internal employees and they couldn't be trusted not reading all the shit him and everyone else said behind each others back.
This made me aware that Slack has some interesting reasons for why teams are locked into their SaaS platform which may have nothing to do with scalability or uptime. In our case it was fear of libel lawsuits and further turnover. While you might be able to live with the insider-threat at SlackHQ with them being able to read your messages, sometimes the idea that anyone in your IT can read everything management has said shared or discussed in the past may be too risky for most.
* You can set a message retention policy that will delete each message after N days. (We're building the UI for it, but currently you can email support@zulipchat.com for help on turning it on.)
* On Zulip Cloud, you can set a message visibility limit that will save all your messages (e.g. for legal/compliance reasons), but only the last N messages will be visible to the team.
Gosh, everyone who runs a computer is at risk for nation-state attacks.
The real question is: how high is the risk?
The risk section of an S1 tries to list every imaginable threat as a risk, without any assessment of the probability or impact (the two components of risk). Using this is a source for such an article is simply wrong.
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.
I reported it to security. Next day I'm suspended. Turns out security did it because they wanted to search through 'just in case' but didn't want to go through the process properly.
Either it was my fault or they were incompetent, guess which one they chose. I was forced to quit eventually.
In the end I lost all my equity.
You need to start from the assumption that it can happen here and take steps to ensure that damage is minimal /recoverable. Part of that is policy, part culture, another part is technical but none are sufficient by themselves. On the tech side, look at systems designed to comply with data protection laws.
To me, the article's focus on permanently deleting old messages specifically avoids that error - it's not about avoiding disclosure but as defense-in-depth since disclosure is always a possibility. Beyond that, avoiding Slack (even with data deletion) is unlikely to increase security, but it does decrease priority for smaller users who might be swept up in an attack on Slack in general.
Except the desire for privacy isn't limited to the rude things you say.
None of us truly wants to live in a world where a third party can secretly review a permanent record of our communications.
- Anything written down and transmitted digitally will be available to anyone who wants it eventually. Besides my copy, the recipient has a copy, as do any number of intermediaries. Encrypted or not, that encryption will almost certainly be broken in my lifetime.
- Anything written down on physical medium or stored digitally (but not transmitted) will be freely available to anyone that wants it eventually. It's slightly more secure than a digital copy, because I have physical control over the only copy and would most likely know if that physical control was compromised (so my NAS is considered transmitted since it is possibly accessible).
- Anything I say to someone in person is pretty safe, depending on how much I trust them not to record what is said (otherwise it becomes classified as digitally transmitted). Of course now a copy remains in their mind's eye, which is in some cases worse since it can be modified and they don't even know it.
- Any thought I have that I have never expressed outside my body is almost completely safe, baring successful administration of truth serum (or until someone invents adversarial brain scans).
How does this affect me in real life? I don't write down things I wouldn't want other people to know, and I am pretty careful about saying things I don't want other people to know. I use encryption whenever I can because it will at least slow down the attackers, but I never assume something that is encrypted is safe.
> - Anything I say to someone [..]
In my hierarchy these two points are swapped. At least I think there is a real chance to keep written material secret as long as you are not a target of a state level adversary. I can write in a room where I am sure there are no cameras watching and I can put my copy in a safe where I would know if it was compromised. On the other hand I can almost never be sure not be audio recorded - be it deliberately or accidentally by any of the microphones that are almost everywhere nowadays.
We're increasingly surrounded by microphones/cameras, some of which are embedded in IOT or other appliances.
Given the NSA's track record, the risk of devices getting hacked, etc. I've become rather conscious of potential implications they could have.
> - Anything written down and transmitted digitally will be available to anyone who wants it eventually. Besides my copy, the recipient has a copy, as do any number of intermediaries. Encrypted or not, that encryption will almost certainly be broken in my lifetime.
I completely agree. So we're now assuming that the information will exist indefinitely for adversaries (NSA warehouse), however if I don't have a copy then it's effectively gone (for me only).
> - Anything I say to someone in person is pretty safe, depending on how much I trust them not to record what is said.
I'm not quite there yet, but I've become leary of all the phones, laptops, cameras, personal assistants, etc. While I'm from the US (so mass spying is supposed to be illegal), and most companies like Amazon/Apple have been shown to be "mostly telling the truth" in terms of how they only transmit data after a trigger phrase, it's a lot of microphones.
Let's assume the person I'm talking to is 100% trusted, all it takes is a hacked Alexa to leak the conversation.
Likely or practical? Not really. Do I do anything specific such that I'd consider myself a potential NSA target? Not really.
But I consider privacy a human right so it's always something I'm thinking about.
These are coming sooner than many people will be comfortable with: https://www.npr.org/templates/story/story.php?storyId=157448...
Keybase is open source and uses pgp. Easy for the the average user. Can be used in command line.
Been using keybase for a while now, haven't tried the tool.