Slack enables customers to control their encryption keys in enterprise version
techcrunch.com
techcrunch.com
I see one benefit of this being able to securely throw away data. Like if you are doing work for customer XYZ and chatting about it on the corresponding channel you can throw away the keys for the channel when the project ends.
Wonder how all this granularity works together with the search functionality. Or maybe they maintain per channel search index that can be covered by a separate key.
Having implemented a similar system, I too greatly wonder that this.
My guess is they keep it in memory (e.g. ElastiCache) and populating the cache would require the keys.
Computing freedom for anyone is computing freedom, and contributes to a norm of user control instead of service provider control. This step is a very small step, and it only affects a few users. But it's still a step in the right direction.
(Something self-hosted like IRC is a much better step, and I'm glad there are free software/on-prem direct Slack competitors now, too. That's also a step in the right direction!)
That's what I don't get from reading this thread. Like you said, Kerberos does have its uses outside enterprise deployments, and if you want authenticated/encrypted NFS for whatever reason it's really one of your only options.
The non-strawman scenario would be if Linux only ran on expensive mainframes.
Honest question: what is it worth to me? I don't but into this "any linux usage is a win" mentality. Linux being used on tivos is worthless to me (https://www.gnu.org/proprietary/proprietary-tyrants.en.html), and it's hard to see why Linux running on hardware I will never have the opportunity to own should be worth anything to me either. Am I expected to cheer for the linux team no matter the circumstance?
And no, I don't want to run my own bouncer, and I don't want people running their own insecure bouncers across my company. Yes, I could use something like IRCCloud but that requires another account and I'm tied to their client unless I pay[1]
Another option would be to rent a really cheap VM and run a tmux or screen session with weechat [3] or epic [4], but command line isn't for everyone either.
[1] - https://github.com/thelounge/thelounge
[2] - https://github.com/Nordaaker/convos
[3] - https://weechat.org/
What's the point when the person you're talking to went offline because they went through a tunnel or momentarily closed their laptop when you sent the message?
This classic HN idea that people only use Slack over IRC because it looks better/easier is a reminder of nerd hubris that prevents one from understanding people and products.
I personally pay $50/year to irccloud.com for these features. Nobody else does. Every day I get the pleasant IRC experience of sending someone a message after they've parted or "hey I got d/c, what did you say again?"
Slack and Discord coming out of the box with a fix for this for everyone is one of their fundamental community-building advantages over IRC.
In other words, IRC isn't worse than Slack/Discord in this regard because you have to opt-in to these things. It's worse because everyone else has to, and they clearly don't.
For example, that I pay $50 to irccloud but nobody else does still makes IRC a poor experience for me because IRC is about communicating with other people, not masturbating over my irssi config.
The reference to VPS nodes was specifically for the case of WeeChat or Epic in a tmux or screen session as yet another alternate option. That is in no way related to TheLounge or Convos.
...at which point you're just reinventing Slack, except you're depending on random volunteers to pay for and manage the infrastructure of it.
Problem 2 is easy file sharing
Problem 3 is more features, ie IRC v3
I don't think you are going to get "computing freedom" via a non-federated service regardless of how you define "computing freedom". Autonomy and independence aren't part of the equation in that context.
If the problem is "this user is unsatisfied with this product', the solution is not necessarily to tell them to build their own [1]. We, as people, are allowed to criticize (hopefully constructively) products that have flaws in them even while using said software.
Slack is designed as a space for team communication, so it seems like a situation where the network effect is at it's least powerful. After all, teams are about the smallest size imaginable. Any alternative is also going to be on the Internet, be it another product, IRC, or a mailing list. The only inertia you have to overcome is the inertia to create an account.
Second of all, the value of peers on a team network is not equal. The team leadership and top contributors are the most valuable members of the network. If they decide to jump ship to another product, your choice is to either follow suit or essentially exclude yourself from the team.
Would you seriously not work someplace or not contribute to a product because it meant you couldn't use Slack and had to use Hangouts or IRC? I'll agree that Slack's product is better and -- baring complaints common to many Electron apps -- relatively without fault, but requiring it seems a bit excessive.
I don't understand that about companies. The trust situation just doesn't change:
Before "managing their own keys", they
have to trust Slack to not break their security
have to trust Slack to not break their security
I work at a company that does EKM for its customers. It doesn't force us to secure our customers' accounts, it allows us to secure them. We get to say things like "I'm sorry, we are unable to pull this data" rather than having to convincingly argue why we shouldn't. This makes us very happy. Maybe we can be forced to break things in such a way as to eventually get any future data you submit, but that's a whole lot more difficult / expensive for the government than the typical "all ur data are belong to us plz" requests.
Yes, if the service provider is malicious, EKM isn't going to save you from them. But if the service provider is not malicious, it can save both you and your service provider.
https://www.google.com/search?q=microsoft+skype+legal+interc...
Do you seriously doubt Microsoft was forced to include legal intercept in Skype after reading the first 3-5 links there ?
So I disagree with your assessment that it provides any protection whatsoever. Perhaps it raises the difficulty a bit.
It does not exclude government intervention at all. The government still has the power to compel a change in the code that works with the encryption keys. When that happens, exclusive access to the keys, to put it mildly, won't matter.
If you think differently, let's see you put your actual trust in this process. You keep access to all your encryption keys and passwords, I even promise not to copy them, but you log into your web banking using a web browser I control. Which is the equivalent of the situation discussed here: I control the code interpreting the encryption keys, you control the encryption keys. Depending on your bank's authentication method I may or may not be able to copy the keys, but either way I'll be able to, say, change a bank transfer you make to my liking, which is really the point anyway. So I will transfer a suitable fee for your education, let's say $100, "without access to" your encryption keys to some charity of my choosing. Deal ?
firms are required to produce chat transcripts of the traders to regulators. Slack would be unusable in this industry if the firms could not capture all of the chat logs.
In Riot (the most prominent Matrix client), you need to log out to change your password. In the current version, you're warned to export your keys if you want to maintain the logs from any encrypted conversations.
What they are most likely doing is encrypting their database transparently, so that if someone breaks in and just dump the database, nothing worth would have been stolen.
This is typical, and often required by different regulation bodies when you deal with personally identifiable information (PII).
An admin cannot change a user's password.
You can enable an account wide feature which allows admins to view all messages but that's separate and costs money. Also not what you described.
The reality is that IT administrators are the root of trust at all organizations. This new feature doesn't change that.
Is this true?
It’s of course possible to limit administrators’ access to certain systems, but ultimately the mechanisms to do so are themselves probably set up by your IT administrators in the first place, so in that sense they’re still the root of trust.
Also I'm pretty sure a Slack admin can change a user's email address, at which point they can trigger a password reset.
(And then have them disclose it to every user...)
AWS Encryption SDK[1] is a well designed, battle tested data encryption library. Amazon KMS is a well audited service used by AWS to manage all sorts of keys and even supports external HSM integration.
For slack to build all this from the ground up would be time consuming. Hard part being 3rd party validation, penetration testing and certification.
[1]: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...
Hard part?? That's just the laborious part. The hard part is in building an actually secure service.
However, this pattern is good and IMHO should be adopted by SaaS orgs that want to appeal to enterprise/regulated customers. We have a few vendors that we're sort of pressing in this direction, and a few have come to us with similar architectural proposals to address GDPR.
Specific to AWS it would be even better of the service allowed for the customer to host the CMK in their own account so they can choose to import key material if they like. This has some downstream implications on what you can do with the key vs. Amazon-generated CMK which may be advantages in some cases.
Looks like it does, based on https://aws.amazon.com/blogs/apn/control-access-to-your-data...
"With Slack EKM, you can use KMS in your own AWS account to create a Customer Master Key (CMK) that always stays under your control. Then, using key policies, you grant Slack access to use your CMK to generate and decrypt data keys."
A made-up example: assuming Brexit occurs, EU customers of a London-based SaaS chat service may no longer wish to keep that data outside of the EU. The easiest way to wipe it out quickly? Pull the key. Or perhaps your government is trying to compel you to produce data that you believe they have no right to. Some companies would rather have the option to destroy it and face the consequences, whatever they may be.
This shows the KMS key is in the customer's AWS account.
[1]: https://symfony.com/
Why would this be surprising? Most of us have probably never cared to think about these subjects. Your comment would be a lot more useful it contained some information about these subjects instead of just expressing your shock that some people don't know things that you do.
edit: I guess this is obligatory at this point: https://www.xkcd.com/1053/
This isn't limited to, but includes monitoring of all activities when on work properties. Video cameras, desktop monitoring, HTTPS interception, IM logging and phone recording, and more.
EDIT: as other comments have pointed out, this essentially boils down to "do not expect any privacy at work" (you have no privacy on employer owned devices) and "do not do any work on devices you expect privacy on" (your employer will install their middleware on your devices, or you may be violating laws)
When a company is audited, not only are their financials audited but also their IT department. The IT department has to be able to present plans on how it is able to audit user actions, retroactively retrieve information from prior dates to detect fraud, and manage their infrastructure in a complaint manor.
Since the big4 are not IT firms, they can only provide "guidance" on the state of the company and if the IT department is actually able to accomplish said goals. Some companies are held to a higher standard and have specific items that they have to accomplish (i.e. how they manage their encryption keys in order to secure their communication). From my understanding, there was actually a lawsuit that Deloitte and PwC lost because they could not determine that fraud has occurred [0]. In the article I've included, it does not say anything about IT but based on my conversations with my wife, this has something to do with some Execs changing their records to hide fraud. Since the financial audit didn't pick anything up (the transactions weren't recorded), their IT compliance team should have been able to tell that there were lack standards in data integrity, management, and access.
This might not be the full picture and I might have not remembered the full conversation correctly. However, I believe this is why Slack having the EKM management might appeal to larger firms who might have to file under compliance of one law or another. Hopefully someone can chime in with a better explanation.
[0]: https://www.marketwatch.com/story/pwc-faces-largest-ever-aud...
What it boiled down to is you have to be able to track every communication you can, and depending on the jurisdiction, you had to keep it around for 7-25 years.
Not only did you have to keep it around, you had to provably keep it in such a way that it couldn’t be “sabatoged”, generally this meant you had to store it on “WORM” (Write Once, Read Many) storage.
The basic rationale is because of the $$ involved, you wanted to make sure no one was a) insider trading, b) defrauding investors, c) defrauding the bank.
Banks are pretty good at these types of controls.
Example controls they do:
1. You can’t trade outside of their monitored platform
2. You are mandated to take a vacation of at least 2 weeks every year (once you reach a certain level), the idea being that any “off books stuff” you may be doing would get exposed.
3. They regularly “flag” specific keywords, and not just the obvious ones, to identify bad actors. I won’t go into details, but it is much more robust than you think.
Just my 2 cents...
Minor edit: spelling
That's an interesting way to fix a problem!
We certainly had to back everything up to write-once medium and store encrypted copies in Iron Mountain. Outside of financial institutions, I get dirty looks when I suggest backing up data this way. It also protects against bad automation.
All at once? I feel like this could be a nice fringe benefit.
Many employers will balk at a vacation this long...
There are a few people in these comments saying things like "but the employer can still read your messages" or "companies should adopt matrix because it can do true E2E encryption of DMs between just the people in the room." That'll never happen in a typical corporate setting.
On your personal phone that doesn’t have any work apps installed on it.
Very generally surprising in that maybe we expect folks to be a bit more technical at hacker news.
Less so when we realize how widely varied technology and businesses are and you can be a hyper smart, productive and technical and know nothing about how other technology works.
I worked with someone who I managed to establish a working relationship with a very capable engineer at a previous job. Without getting into details he did some chip design and once you got "in" with him he was a great asset to work with if you were on the support side (where I worked at the time). I made a joke once when his phone was having a problem that some of our equipment must be between his phone and the server and it was having X problem (something we were working on). I'm 90% sure he actually didn't realize that the equipment the company made was ultimately something that could in fact be between his phone and the server. He was amazing at his job ... just didn't need to know that thing to be that way.
"no encryption" - There is encryption, not end to end but data is encrypted at rest: https://slack.com/security
"horrible clients" - I disagree. They're not perfect but they work and are consistent 99.999% of the time.
"mistreatment of irc users" - People need to get over this. It's not IRC. That's like being upset that email doesn't support fax well enough.
I wonder if the UI shows the employees that their employers have the keys.
[1] Edit: as opposed to only regulated customers. Also, there's an upcharge...you don't automatically get control.
If you did, you had it in error.
If I am reading this right, this actually reduces your exposure as an employee. Instead of your employer and Slack having full access to everything you do on that account, now your employer has full access but Slack's access is reduced substantially. (If the setup is working as I expect, Slack will still get metadata.)
Slack is a shady thing and I'll never install their desktop app, which presumably is full of user tracking.
Slack is not the tool you'd want to use for anything but the most innocent work-related messages.
For that it is kind of usable, not good but one of the better that will get approved by management.
Again, I don't know the internals. But generally, an entity that has keys can forge messages. There's an incremental difference between the ability to snoop and the ability to forge. There's docs on the slack API, but none for the protocol, and not much is said about the new functionality.
It's certainly possible that was already there via other means, but a change in key control seems significant enough to warrant a UI indicator to me.
It depends on how it's structured, and with the most natural structure, this wouldn't be true. You'd be able to forge a message with the keys to exactly the same degree that you can forge a message coming from your coworker in Slack right now; short of social engineering to steal their password, anything else that would allow you to do that right now would be a major security vulnerability in Slack. And, more to my point, one that could be fixed.
Private keys here would be adding a layer of protection and making it harder, not easier, to forge anything.
Of course, an employer today could also claim to have evidence that you sent X to person Y, but Slack's own records would show that you didn't.
They'd have to go out of their way to make it so that merely holding the encryption key would allow you to fully forge messages.
Generally speaking, this is not adding power to the system, it's actually removing it. The reason why enterprise customers want this feature is not to give the customer more power, it's to remove power from Slack, because without this feature, Slack (not your employer) could forge messages. Assuming they implement this key stuff securely, this would remove the power to forge messages from Slack, and your employer would continue to not have it.
Slack grew because employees like me convinced their employers to start using it. The same people can also convince their companies to drop Slack and use something else.
> If I am reading this right, this actually reduces your exposure as an employee. Instead of your employer and Slack having full access to everything you do on that account, now your employer has full access but Slack's access is reduced substantially. (If the setup is working as I expect, Slack will still get metadata.)
It kinda sounds like you're saying that the employee has responsibility for data on Slack if there is a security breach at Slack. Either way, Slack has little interest in spying on employees and sowing discord.
Be sure to read your employment agreement. And never, ever, use work related systems for anything personal or private or inappropriate. "NSFW" means something.
Heck, apply this level of thinking to any system you don't own or control. Unless privacy is baked into the protocol, you have none. Period.
If the privacy of your work chats is important to you, there are lots of other jobs you can take. And of course nothing prohibited private chats between employees as long as they were not about work. I absolutely used Signal with friends who happened to be coworkers, but it was for things like planning our next D&D session and not planning out next trade.
If you don't own the keys, it's not your data.
No. Just feel like who owns the keys is relevant. I can see, for example, if my employer is using a self-signed cert within my browser. Though I understand they have other ways to see what I'm doing in a browser even if there is no MITM cert.
"hands over control...to regulated customers"
It hands over control to ANY customer, not just regulated ones. And only to those that pay the upcharge.
Just seems oddly worded.
Further, some readings of the ECPA (Electronic Communications Privacy Act) indicate an obligation on the part of the company to monitor.
Yet another reason to use e2e encryption and authentication.
Also, Slack, I'd like a native MacOS app please.