141–150 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.
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)…
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.
Earlier quoted context omitted.
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) pro…
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.
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.
Problem 2 is easy file sharing
Problem 3 is more features, ie IRC v3
Earlier quoted context omitted.
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/en…
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…
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."
Earlier quoted context omitted.
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…
"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…
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)…
All at once? I feel like this could be a nice fringe benefit.
Many employers will balk at a vacation this long...
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...)
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?