Slack enables customers to control their encryption keys in enterprise version(techcrunch.com)
techcrunch.com
Slack enables customers to control their encryption keys in enterprise version
https://techcrunch.com/2019/03/18/slack-hands-over-encryption-keys-to-regulated-customers
175 comments
> Wonder how all this granularity works together with the search functionality.
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.
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.
This is a good thing for computing freedom: it puts more control in the hands of customers instead of requiring them to outsource encryption to Slack. It's a small step, since it's Amazon KMS and since presumably Slack still sees cleartext in transit. But it goes in the direction of restoring the security profile that a customer did when they ran their own internal IRC server, and that's a good thing.
The article says it’s only open to enterprise customers. Computing freedom you have to pay a ton for is not really freedom. It’s really not even close to the control of IRC.
One of the tensions between federated services (DNS, SMTP, HTTP, etc.) and non-federated services (Twitter, Slack, Facebook messenger, Signal, etc.) is that quite a bit of control (perhaps all) is delegated to the single operator in the non-federated model.
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.
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.
Is it not worth Linux running on mainframes because mainframes are expensive? Is it not worth Kerberos being free software because the only real users of Kerberos are enterprises?
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!)
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!)
Both of the technologies you named as examples are free and open. Anyone can inspect them and deploy them on their own. Slack isn’t like that unfortunately. This is a move to add another feature that will attract enterprise customers, I would doubt that even Slack themselves would proclaim this as a move towards greater software freedom.
I agree that this move is articulating enterprise customer demands rather than demonstrating greater software freedom. I don’t view this as unfortunate though. Slack is a productivity and collaboration product versus a utility like a low level database or encryption method. As such, many users and businesses want to pay for support, added features, hosting/availability/backups. It is better to have someone having to pay Slack a lot for power features than have a bunch of targeted ads in Slack. The buck stops somewhere.
> Anyone can inspect them and deploy them on their own
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.
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.
>Is it not worth Linux running on mainframes because mainframes are expensive?
The non-strawman scenario would be if Linux only ran on expensive mainframes.
The non-strawman scenario would be if Linux only ran on expensive mainframes.
> Is it not worth Linux running on mainframes because mainframes are expensive?
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?
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?
Still benefits you; more users to bolster the ecosystem (contributing to shared code), and code that later turns out to be useful (many-cpu systems were expensive supercomputers... right up until they started landing on desks).
It's pretty clear many customers don't want control, they want features, and irc lacks those.
Not true, Slack is actually pretty far behind on terms of features. It is true that people like the better looking, easier to use technology however.
IRC doesn't even have the only feature I care about: the native ability to see messages sent while I was logged out.
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]
https://www.irccloud.com/faq#faq-bnc
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]
https://www.irccloud.com/faq#faq-bnc
There are a few web clients that use redis to allow you to see history. I will be the first to admit, those clients don't scale as well as IRC itself does. [1] [2] And of course, someone would have to manage that infrastructure. It isn't for everyone.
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/
[4] - http://www.epicsol.org/#getting_epic
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/
[4] - http://www.epicsol.org/#getting_epic
Sure, but that fixes it for you, not anyone else.
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.
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.
People do use Slack because it looks better and is easier to use.... the features you're talking about are possible with IRC, it just requires work that the average consumer isn't willing to do. The other half of the equation is that IRC is better in ways that consumers don't care about, yourself included.
Can you deploy irc in a way that meets or exceeds the features provided by slack to an enterprise with thousands of users? And then teach Joanne from accounting how to use it?
We’re not disagreeing. That ease of deployment and use is Slacks killer feature. I’d go beyond that actually, there’s an entire suite of companies for whom their claim to fame is that exactly. And that’s predictable — technology is saving us time like it should.
Not sure I follow. The first to options I provided fix it for everyone.
What I mean is that everyone you talk to has to opt in to it too.
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.
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.
If they implemented one of the first two front-ends I linked, you would know what the message was and would not have to ask your friends to repeat The only people that opt-in are the IRC server infrastructure engineers. End users just connect to the web front end. The first two links turn your IRC servers into a Slack clone, except with more or less features. This is certainly non-trivial to set up and maintain and end users would not implement this. They are just consumers of it.
Now I don't understand. I'm clearly talking about other people (everyone else but you), not the nerd running irssi on a VPS nor thelounge.
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.
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.
I am not talking about putting TheLounge or Convos on a VPS node. I am talking about IRC administrators putting that, or a fork of that in front of their IRC infrastructure, so that you and your friends will have chat history / session persistence.
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.
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.
If they're running their own irc server they can run their own thelounge, or quassel server on the same machine, and everyone can connect via that, problem 1 solved.
Problem 2 is easy file sharing
Problem 3 is more features, ie IRC v3
Problem 2 is easy file sharing
Problem 3 is more features, ie IRC v3
If you want those features but are unwilling to run a bouncer or use irccloud, you’re correct, Slack is the best offering for you. But I’m wondering: why Slack and not IRCCloud if that’s the feature that matters to you?
IRC is worse for me because the people I talk to don't run a bouncer or use irccloud even though I do. Fixing it just for me does not fix the reasons why IRC sucks in this regard.
More features isn't always better. I already find Slack very overwhelming.
2 Options as I see it: Either don't use Slack or try to gather consensus and change things
Using Slack isn’t really a choice for most people, but I agree, coming up with alternatives is important.
Using Slack is a choice for someone in your organization, even if you aren't that person. You probably also don't get unilateral control over your working hours, pay, and office.
It’s still their product. You have the freedom to not pay for it and use whatever alternative you want or build your own.
It should be noted that once the Network effect [0] takes place, it becomes less about freedom to build your own software and more about the cost (including - maybe especially - intangible) and viability of doing so.
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.
[0] https://en.wikipedia.org/wiki/Network_effect
[1] https://en.wikipedia.org/wiki/False_dilemma
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.
[0] https://en.wikipedia.org/wiki/Network_effect
[1] https://en.wikipedia.org/wiki/False_dilemma
I'm not so sure the network effect is significant here.
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.
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.
One day people will realize that control over encryption keys means nothing if you don't have control over the application using those encryption keys.
[deleted]
I wouldn't say "nothing"–it's certainly not complete control but it reduces the attack surface. I don't control the proprietary password manager I use, but the fact that I control the encryption keys and they don't means I'm less vulnerable to attacks on their service infrastructure.
EKM does not provide the same security as a password manager for the content (i.e. Slack messages and passwords). In this case Slack is still able to request a key from the KMS in order to perform operations over the messages (search, archive etc). Those keys generally have some sort of expiration on them by default (hour, day, etc) before they're rotated. However, during that window the key could be copied and used w/o the "reason" being logged. More realistically, the security threat is that there is a bug somewhere that while the data is unencrypted in memory it accidentally logs some proprietary data into a secondary system that is not encrypted with the same EKM system... EKM is a bit of shell game but everyone loves some good security theatre.
You forget that this is supposed to protect the enterprises against hostile action by Slack itself. This, of course, it does not do, as slack could simply change the application to accept an additional key, or to just do what they want done without any request.
I don't understand that about companies. The trust situation just doesn't change:
Before "managing their own keys", they
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 would argue that your threat-model is wrong in this scenario. EKM isn't there to protect you from the company that you're using, it's to protect both you and the company from legal overreach.
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.
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.
Then perhaps I suggest you search Microsoft Skype. Providers can be forced to modify code as well:
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.
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 is a perfectly sensible threat model to exclude government intervention. Perhaps more sensible, on the grounds that the government can always make your life hard in other ways, and the government can get away with not following the law. There are lots of meaningful attackers who are unaffiliated with the government, and it's absolutely worth protecting against them.
This does not result in a change of threat model at all. That's what I've been pointing out. It does not protect against anyone at all, nor does it make you more vulnerable to them.
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 ?
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 ?
Does EKM let you actually borrow a copy of the key instead of just doing operations remotely (like an HSM would)? Ugh, then yes it's security theatre. But I'm also surprised regulators are fooled; there's a reason they usually want HSMs on-prem.
The title of this post makes it sound like a bad thing, but in regulated industries like Finance,
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.
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.
I think this is about making sure only you can create chat transcripts, not Slack. This would greatly increase enterprise adoption if they knew a company easn’t Reading it’s mail. Am I reading this wrong?
[deleted]
Funny because I know large financial companies that have been using Slack for years.
Not all roles require the same level of audit. In general for simplicity, an entire firm will use one system that just applies the same policies for everyone, but a dev building a web interface for an internal risk tool will not be under the same requirements as a sales trader talking to clients and taking orders to execute in the market on their behalf.
I am not sure slack can ever meaningfully become encrypted while having persistence. All it takes is for a admin (or hacked admin account) to change the password of the target slack user and login as said user to view all their private messages. The encryption is mostly pointless as far as I can tell when all of it is circumvented by a changed password.
If you really want encryption with only access by the people in the room, you can use Matrix: it's not based on your password, but on the keys. If you have your keys (and encryption has been enable in the room), you and only you/your devices can read the messages.
So if someone else changes the password it doesnt show them? What if you legitimately chang your own password how does that work? I think I like the proof concept from Keybase unfortunately their name makes it sound like an SSH key repo and not an all in one chat and file sharing service. Also not quite as open as Matrix in the sense that people can choose other servers.
Right, the encryption isn't based on the password, but on encryption keys that are only on your devices. If you want to add a new device, you share the keys from one of your other devices to that new device. But just being able to log into an account (say by having the password) on a new device doesn't give any way to get the keys/read the encrypted messages.
So how easy is it to transfer between devices? This sounds like your keys could wind up in untrusted sources like if e.g. someone emails their keys to themselves, pretty sure then all bets are off that those keys are even secure?
Quite! If you don't have them backed up to your homeserver Riot asks you if you want to share the keys with the new device, you check that the device ID and key match, and then hit ok and it happens.
If you have them backed up to your homeserver, you just hit download from server then put in the password you encrypted them with.
Correct, it won't show if you change your password. For legitimate uses, you export your session keys prior to changing your password.
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.
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.
That is not what the encryption they are using is for, you are confusing end-to-end encryption with encryption at rest.
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).
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).
Depends on what you mean by "meaningfully encrypted". If E2E encryption is what you are going for, then yes. Companies that use Slack specifically don't want that, though, since they want to be in control of all communications (due to industry regulations or whatever other reason). So it is still encrypted, but the company holds the keys.
I thought it was rather difficult for an admin to view private messages on Slack? Last I checked you had to apply for this kind of access, on your own account.
They used to require that you enable it and it would send a notification out to all users of your Slack instance (
they also wouldn’t have access to data prior to that without a legal request) but now they just let you enable it silently.
They are only secure so far as everyone in the DM or private channel is employed. The company can always take over old accounts and get access to DMs that way.
If everyone has to use corporate email addressees they could just take over the emails temporarily to reset the password. If they really cared they could do so without the user ever knowing. They could also put language in their employee handbook or contract saying that you have to give them your password and fire for refusing... however, I fail to see how any of this is an issue since this is the company Slack and they have the right to see how people are using it.
I wonder if just using standard OTR over slack for sensitive stuff is viable.
>All it takes is for a admin (or hacked admin account) to change the password of the target slack user and login as said user to view all their private messages.
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.
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.
I don't think that's true. In the corporate world, Slack is authenticated with AD/SAML/etc. and Slack has no idea who is changing passwords on that backend system.
The reality is that IT administrators are the root of trust at all organizations. This new feature doesn't change that.
The reality is that IT administrators are the root of trust at all organizations. This new feature doesn't change that.
The admin just changes the email address than does a forgot password recovery. You dont need SSO/special integrations. You can do this on a vanilla slack install to any user.
IT administrators may handle the root of trust, but IT administrators are closely subservient to management. Management, in the business of control, knows this, and pushes at many opportunities. In the US courts, management whim controls any asset, not de-facto key holders.
>The reality is that IT administrators are the root of trust at all organizations.
Is this true?
Is this true?
From a technical perspective, yes, though of course not a legal perspective. Take certs signed by an internal CA for example; as far as end user devices are concerned, the root of trust is that CA, which is presumably configured and managed by your IT staff. (Or sysadmins or whatever the role happens to be at your company.)
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.
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.
If you're using SSO, which almost every big customer does, you can usually do a password reset in the SSO itself.
Also I'm pretty sure a Slack admin can change a user's email address, at which point they can trigger a password reset.
Also I'm pretty sure a Slack admin can change a user's email address, at which point they can trigger a password reset.
It does email the person you made the change though. If you control the email system, then you could do it silently.
bingo. The admin just changes the email address than does a forgot password recovery. This works without SSO/special integrations. You can do this on a vanilla slack install to any user.
One good security feature would be to not give the user's email address by default to apps you connect Slack to.
(And then have them disclose it to every user...)
(And then have them disclose it to every user...)
Isn't that how it already works? Apps have to ask for the email scope during install and you have to approve that individually for the app to get access to your email.
Isn't this just shifting partly your trust from Slack to Amazon?
I think it's very smart of Slack.
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-...
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-...
Amazon isn't perfect, but I sure as hell trust Amazon KMS more than most others out there.
> Hard part being 3rd party validation, penetration testing and certification.
Hard part?? That's just the laborious part. The hard part is in building an actually secure service.
Hard part?? That's just the laborious part. The hard part is in building an actually secure service.
Yeah I don't really care about Slack, it's banned at work.
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.
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.
> 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.
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."
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."
That's cool! Thank you for digging into it.
While the encryption keys would be at amazon the slack data would be on "slack's servers" (AWS or elsewhere) meaning that both slack and AWS location of the keys would have to be compromised and then somehow associated to each other.
Enterprise customers want the ability to pull their keys and walk away from a platform, sometimes with very little notice.
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.
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.
One thing I'm not totally clear on after reading the article is which AWS account the AWS KMS resides. Is it Slack's AWS account or the customer's?
https://slack.engineering/engineering-dive-into-slack-enterp...
This shows the KMS key is in the customer's AWS account.
This shows the KMS key is in the customer's AWS account.
[deleted]
Related article from last fall discussing why Slack was supporting EKM rather than E2E encryption: https://motherboard.vice.com/en_us/article/kzj5xn/why-slack-...
Just to be clear, does it say anywhere that Slack does/doesn't retain access to the key store? It seems like it would be impossible for the service to work without maintaining access to the keys from their servers, so nobody should expect this to provide end-to-end privacy. Is that correct?
The key store lives in the customer's AWS account, and they can revoke keys or complete access at any point.
How does it compare to Symphony [1]?
They want to get the financial market companies, but a lot of them already have their own solution.
[1] https://symphony.com/
[1] https://symphony.com/
Can you elaborate on why you are asking how a chatroom service compares to a webapp framework?
Symphony's chat tool is a Slack competitor where customers can control the keys, including via HSM. On the surface it is similar to what this news is announcing Slack added to its own tool:
https://symphony.com/product/messaging-and-productivity
https://symphony.com/product/messaging-and-productivity
Can you clarify? They both offer chatrooms and depending on your definition of webapp framework they both are as well (external app integration, bots...).
Can_Not was probably thinking about Symfony [1].
[1]: https://symfony.com/
[1]: https://symfony.com/
You're definitely confusing with Symfony, the PHP framework. As others pointed out, Symphony is a Slack competitor.
I would still say Symphony’s target is Bloomberg. Despite Symphony’s good progress so far, Bloomberg are still far ahead in market share and their network is a great moat which makes it very hard to substitute, also given that onboarding new platforms across financial firms is a huge challenge even when you aren’t pushing against network effects benefiting your main competitor.
[deleted]
I am curious, does this mean that Slack will not be able to read messages of such organizations? I.e. the keys will be known to organizations only and Slack will have no access to them?
Slack will have temporary access to messages (in transit on their backend), but if the keys are revoked by the organization then yes Slack cannot see them.
So this basically means within an enterprise instance of Slack -- "your" messages can be decrypted and made available for consumption if required?
[deleted]
Paging MitchellH here, but how does this capability intersect with HashiCorp Vault?
The most surprising thing about this article isn't the article; its the comments in here, and the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works.
Please don't post shallow dismissals to HN. If you know more, share some of what you know, so others can learn. Nobody knows everything.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
"the surprising number of people who have no clue how Slack works or how corporate/enterprise regulation & compliance works"
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/
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/
I guess what's surprising is if you've never cared to think about the subject, why would you come here to comment on it?
Many corporate/enterprise environments, in particular those involved in regulated activities (e.g. finance) require visibility of all work-related communications, to ensure employees aren't committing any crimes.
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)
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)
I have no idea how corporate/enterprise regulation & compliance works in relation to Slack. Could you elaborate?
I would suspect it is something along the lines that don't expect any privacy at work unless you are in the restroom typing on your phone and not using the company's WiFi.
> on your phone
On your personal phone that doesn’t have any work apps installed on it.
On your personal phone that doesn’t have any work apps installed on it.
Mostly just a very simple point: If you're an employee at a company, you have practically no right or expectation of privacy (applicable to this conversation).
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.
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.
That is not true. It depends on the company and what information you're expected to exchange. Everything was end-to-end encrypted in my previous job.
I'm not sure what the OP was alluding to but based on: (1) I ran a department that was audited for compliance [minor, startup, audit for investors] and (2) my wife works for a big4 that does audit companies for compliance in the Financial sector that file w/ SEC.
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...
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...
If a banker is accused of inside trading then chat records need to be pulled without tipping them off. Similarly for an employee accused of sexual harassment.
In a past life, I worked as part of a legal regulatory IT function.
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
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
> 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.
That's an interesting way to fix a problem!
That's an interesting way to fix a problem!
I too have worked for a bank and also had to take the mandatory 2 weeks off (contiguous) despite not having access to financial transactions. That took some getting used to. I missed being able to take off several Monday's in a row.
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.
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.
> You are mandated to take a vacation of at least 2 weeks every year
All at once? I feel like this could be a nice fringe benefit.
Many employers will balk at a vacation this long...
All at once? I feel like this could be a nice fringe benefit.
Many employers will balk at a vacation this long...
Surprising, and not if you've been reading enough.
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.
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.
"Bro, just write the app, let me worry about the rest!"
Out of curiosity, does Slack allow a single person multiple Screennames?
I see a scenario where a single person can have different handles, so personal communication doesn't overlap with work related communication. But the article does not make that clear.
I think with Slack you register new account to every workspace you join. I don't think it even have single account for everything concept, and you'll have to get a new handle everywhere you join.
Many slack instances such as regulated ones that require encryption keys use external authentication, such as Azure Active Directory, to authenticate users. If you are able to get multiple user accounts in the corporate directory service, they have bigger problems than multiple slack usernames.
It works the other way; you can't _not_ have multiple screen names. Each workspace (which is the new, not as good name for a slack team) has its own unique set of users. Every workspace whose slack you join means you need to create a new user for that workspace.
It's not like Discord, it's not a global profile that gets shared across all Slack instances - you can register with different email addresses per-slack.
At this point, between no encryption, horrible clients, mistreatment of irc users, and questionable corporate behavior there's nothing in Slack that's worth saving it for me. Superior free software alternatives exist that bring the same or better functionality while also giving the user full control.
What does any of that have to do with this article (other than that it's about Slack)? The ability for enterprises to control their keys is hardly unusual.
Please elaborate on "questionable corporate behavior". Everything else you said is matter of opinion and slack's growth would speak to the exact opposite.
"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.
"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.
What "questionable corporate behavior" are you referring to?
Which free alternatives?
Matrix is the most popular one I think.
Matrix, Mattermost, Rocket.Chat, and that's just off the top of my head. All three are free (as in speech) and aren't terribly hard to set up on-premise or spin up a container for somewhere else.
Zulip is a great choice, too.
I find Rocketchat quite good.
I like Slack a lot except for the fact that it's a sluggish web app hidden away in a native window. I understand it gives them a lot of freedom to change things constantly, but what I would really want is a proper native app.
Reads more like "Hands over control to any customer that will pay for it."[1]
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.
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.
Are you saying you had some sort of presumption of privacy on a corporate Slack account?
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.)
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.)
I don't know slack internals. but I assume the employer having the key means that they now have a way to rewrite history in a way that looks cryptographically correct.
That's not how it works. Just because you have the keys doesn't mean you have direct filesystem or database access to change what you please.
Ok, lets just make this clear:
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.
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.
I didn't suggest it was.
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.
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.
"But generally, an entity that has keys can forge messages."
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.
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.
Why do you believe employees are worried about the actions of Slack instead of the actions of their own employer? This change allows companies to spy on employees.
No it doesn't! Employers have been able to read messages on Slack for ages now.
Oh, whoops. I guess they caved to pressure.
> Are you saying you had some sort of presumption of privacy on a corporate Slack account?
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.
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.
Perhaps not in the U.S., but Europeans could definitely sue their employer if private messages are read (which Slack explicitly supports).
Slack is a shady thing and I'll never install their desktop app, which presumably is full of user tracking.
Slack is a shady thing and I'll never install their desktop app, which presumably is full of user tracking.
There are industries where you have no expectation of privacy at work because all comms are required to be monitored and stored due to the law. So this new feature really enables them to serve these customers who operate under such laws.
Matrix allows encryption with only access by people in the room, and even since they joined.
Right, and Matrix cannot be legally used by such customers. (I was the person who set up Slack compliance logging at my previous employer, which was SEC- and FINRA-regulated, moving from internal IRC. We weren't legally allowed to use even the chat window on the side of Google Docs etc.)
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 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.
Even if it isn't the law, most companies make you sign away your ownership of any and all communications made using company provided systems or materials as part of the employment contract.
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.
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.
What is your expectation if the UI does not show that? That your communication is private? Why would you expect private communication when using your employer's infrastructure or, worse, a third party infrastructure like Slack?
If you don't own the keys, it's not your data.
If you don't own the keys, it's not your data.
"That your communication is private?"
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.
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 of a customer's account to .. the customer?
As opposed to the headline, which implies it might be available to only regulated entities, yes.
it actually says "regulated customers"
Yes. It says:
"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.
"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.
Ok, I understand what you mean now. Yes it's strictly an unnecessary qualifier, but does make the intent of the move clearer.
Most acceptable use policies (or information security policy or employee handbook) point out that employees must presume that the company does monitoring of the employee's communications.
Further, some readings of the ECPA (Electronic Communications Privacy Act) indicate an obligation on the part of the company to monitor.
Further, some readings of the ECPA (Electronic Communications Privacy Act) indicate an obligation on the part of the company to monitor.
I am pretty sure that this was already true anyway - after all anyone with enough money could just buy the company.
Yet another reason to use e2e encryption and authentication.
Yet another reason to use e2e encryption and authentication.
Only available for an "additional fee" for Enterprise users. Cheeky.
Also, Slack, I'd like a native MacOS app please.
Also, Slack, I'd like a native MacOS app please.
It's only needed by large, highly regulated businesses, and it only works for self-hosting obviously.
Slack doesn't provide a self-hosting option at any tier. This allows you to host the encryption key in your own AWS account's KMS service, which Slack then (running in Slack's own AWS account) then queries.
Is that obvious? Using AWS you delegate access to KMS keys to other accounts.
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.
[1] https://slackhq.com/enterprise-key-management