Hacker News Reader

Comment by geofft | Hacker News Reader

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.

View on HN

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.

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

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

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.

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

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.

More features isn't always better. I already find Slack very overwhelming.

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://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.

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.

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.

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.

> I am talking about IRC administrators putting that, or a fork of that in front of their IRC infrastructure

...at which point you're just reinventing Slack, except you're depending on random volunteers to pay for and manage the infrastructure of it.

Correct.

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.

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

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.

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

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.

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.

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.

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.

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.

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 their security

After, they

  have to trust Slack to not break their security

But I've seen enterprises take and in fact insist on this often. It never seems to matter that this is a useless gesture. A signed contract that they won't break their security, which is a far less invasive and easier measure, is better. At least that provides some recourse.

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.

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.

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 ?

Reply on news.ycombinator.com