Hacker News new | ask | show | jobs
by Alex3917 2524 days ago
Not only does Keybase not automatically update its client, there is no way to even figure out if your client is out of date and in need of security updates. Even if you look up the exact version of your installed client, which you can find, there is nothing on the website that says what the most recent version is. The only way to even get a hint is to look on GitHub, and even that isn't accurate; version 4.2.1 is the latest release, but when I download the mac app it's still version 4.2.0.

For whatever problems Slack has, at least I know if there is a new version that I need to install.

3 comments

Keybase developer here. Keybase does automatically update on Mac, and you can check if you're out of date on the CLI with `keybase update check`. Additionally, the "widget" popup from the system tray will display an out of date banner automatically.

4.2.1 was a bugfix release that only affected Linux and BSD, so we didn't push out Mac or Windows releases for it.

> Keybase developer here. Keybase does automatically update on Mac

Interesting, is this relatively recent? It didn't update for me, but I hadn't opened it in at least six months.

Also, that CLI command should probably be wrapped in a "Check for update" menu option.

You know what's better than installing slack? Not installing it and using it in the browser.

If there's a website option for any tool, I recommend using that over native. It's usually more performant and is less of a security risk. And it's always up to date.

> You know what's better than installing slack? Not installing it and using it in the browser.

What's sometimes even better than that, is not using Slack at all.

> It's usually more performant and is less of a security risk.

Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").

Software running in a browser is probably going to heavily sandboxed and have tight restrictions on what it can access since the purpose of a browser is to run untrusted code. Native software will usually have minimal sandboxing because it's supposed to be trusted, and can do anything the user running it could do.

As far as performance, I think that only applies to apps like Slack and Spotify that use Electron to pretend to be a native app.

Which do you think is more potentially damaging?

1) Using a website which has had its server code compromised (slack).

2) Installing and using an application which has had its code compromised (maybe also slack).

The installed application is going to have more access and potential to damage your system and to compromise your data. There's not really anything more to it. One's in a browser sandbox and limited by browser capability, the other can do literally anything it wants.

Makes sense, thanks. I think my mental threat model was different:

you're talking about dodgy (potentially compromised) software: better run in the browser sandbox (albeit imperfect) than natively.

I was thinking of sensitive software (eg secret chats) I want to protect from attack: better run natively than in the (imperfect) browser sandbox.

In the context of this discussion (Slack), your threat model probably makes more sense.

What's the mystery here? It doesn't have access to your file system or the ability to request root access.
I expect he's referring to the web page running in a sandbox vs running an app locally with no sandbox.
That is why you use a system with a package manager. Maybe you could follow the releases feed on Github. It was what I do when I maintain a package on AUR.