Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack enables customers to control their encryption keys in enterprise version

techcrunch.com

Post reply on HN
Print view View original

111–120 of 178 posts

Re: Slack enables customers to control their encryption keys in enterprise version

#111

Post by tedunangst »

randlet wrote: post #54
013a wrote: post #48

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.

"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 i…

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?

Re: Slack enables customers to control their encryption keys in enterprise version

#112

Post by chias »

candiodari wrote: post #86
grantlmiller wrote: post #72

Earlier quoted context omitted.

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…

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 have to trust Slack to not break thei…

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.

Re: Slack enables customers to control their encryption keys in enterprise version

#113

Post by xYa1001 »

atomical wrote: post #39
jerf wrote: post #15

Earlier quoted context omitted.

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 wil…

> 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…

What is so controversial about this comment that it is down-voted several points? The whole thread is dominated by Slack apologists.

Re: Slack enables customers to control their encryption keys in enterprise version

#114

Post by baby »

ds wrote: post #14

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.

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).

Re: Slack enables customers to control their encryption keys in enterprise version

#115

Post by lenomad »

aerophilic wrote: post #90
jvannistelrooy wrote: post #51

Earlier quoted context omitted.

I have no idea how corporate/enterprise regulation & compliance works in relation to Slack. Could you elaborate?

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)…

> 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!

Re: Slack enables customers to control their encryption keys in enterprise version

#116

Post by baby »

013a wrote: post #68
jvannistelrooy wrote: post #51

Earlier quoted context omitted.

I have no idea how corporate/enterprise regulation & compliance works in relation to Slack. Could you elaborate?

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 c…

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.

Re: Slack enables customers to control their encryption keys in enterprise version

#117

Post by gwright »

femiagbabiaka wrote: post #44
geofft wrote: post #33

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.

Re: Slack enables customers to control their encryption keys in enterprise version

#118

Post by hombre_fatal »

LinuxBender wrote: post #105
quacker wrote: post #102

Earlier quoted context omitted.

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

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…

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.

Re: Slack enables customers to control their encryption keys in enterprise version

#119

Post by black-tea »

tmaly wrote: post #103

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.

Funny because I know large financial companies that have been using Slack for years.

Re: Slack enables customers to control their encryption keys in enterprise version

#120

Post by LinuxBender »

hombre_fatal wrote: post #118
LinuxBender wrote: post #105

Earlier quoted context omitted.

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…

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.

Not sure I follow. The first to options I provided fix it for everyone.
Post reply on HN