51–60 of 178 posts
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.
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.
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.
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.
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.
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.
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/
Earlier quoted context omitted.
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.
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 signif…
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.
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.
Hands over control of a customer's account to .. the customer?
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.
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.
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!)
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.
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.