(Replying to PARENT post)

πŸ‘€josh2600πŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

It _seems_ you (someone from the Signal project?) are actively diverting from the point, with what is ultimately a security theater request. Keybase's app - which IS open source - doesn't trust the server at all. We could be running anything server-side, regardless of what we do or don't publish. Meanwhile, Signal's story is "you MUST trust our server, over and over again," as the blog post explains. Unfortunately there's no way to know what's happening on the server. So being like Signal and publishing your server source is strictly worse than being like Keybase and not (yet?) publishing server-side source. At any time, Signal could be throwing in these fake key upgrades, either due to running other source code on purpose, or being forced to, or just plain getting hacked. The most malicious Keybase server could not.

This comment may be of interest (we could release server code at some point, and I will take this as a vote), but I hope people reading this aren't distracted by Signal's flaw here.

[edit: chilled a bit!]

πŸ‘€malgorithmsπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

It's a shame that it's not open source from the perspective of people being able to self-host, but if you don't need to trust the server (as Keybase clients don't), then the security of the system is not weakened one bit.

That's a very useful property, because even if the server is open source, that doesn't guarantee that what the Keybase team is actually running in production matches the source they've released.

So I would say a system where the clients don't (and don't need to) trust the server, even if no server source is publicly available, is still strictly better from a security standpoint than a system where the clients do need to trust the server, and source is available. (Assuming, of course, that the design of the system as a whole is sound, and that clients have been audited to ensure that they follow the design of the system correctly.)

πŸ‘€kelnosπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I’m saddened this is the top comment, as it appears to be little more than trolling.

It is better to not even have to think about looking at the server-side code.

The best case would be there is no β€œserver” at all, but that’s the Internet we have to work with today to enable the usability and user experience they are going for.

πŸ‘€zarothπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

If the client is open and you can see what it sends to the server, why do you care what the server is doing? It shouldn't be able to do anything nefarious and all the crypto happens locally afaik.
πŸ‘€drexlspiveyπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Why I like Wire in this regard, they seem to have their front-end and back-end open sourced. I believe their servers AGPL licensed, but it still allows you to run your own instance. Sadly people are highly more likely to use either Signal or KeyBase than Wire, which I think is my favorite since it doesn't tie you to a phone number (tip: register from the desktop first), and you can delete all your account information.
πŸ‘€giancarlostoroπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"Open source project"
πŸ‘€icelancerπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

This can be applied to pretty much any security-focused product, or product claiming to be secure/encrypted. If it relies on an unknown number of proprietary/closed-source components, it can't be trusted. Keybase, WhatsApp, Telegram, and iMessage are all good examples of this. If your code can't stand up to public scrutiny it might not be able to withstand attack. I'm not willing to blindly chuck messages into a black box and hope what comes out the other end is exactly what I put into it. (This complaint is not specifically about Keybase; in fact the linked article and a few comments say their client doesn't trust the server at all, which is really cool. Point still stands.)

Keybase looks really really cool, and I would love to use it, but I can't in good conscience recommend something that is cagey about the half-open nature of their product, especially when the server. It is by definition "man-in-the-middle"-ing all your data, and if you can't inspect it you can't reasonably trust it.

πŸ‘€elagostπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

It's on their roadmap, guys.
πŸ‘€99052882514569πŸ•‘6yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

To Keybase people here, I'm not sure why you can or won't open/free the software. However, it might be possible that you meet your goal by using shared source that licenses published source for specific uses as educational/academic, security review, and/or build locally from source. Doesn't allow commercial use or forks of that code. There's precedent for that in security software, like Cryptophone doing it (below) for review. I suggest considering an option like that if open/free source doesn't work since it still increases confidence in Keybase.

https://www.cryptophone.de/en/background/source-code/

πŸ‘€nickpsecurityπŸ•‘6yπŸ”Ό0πŸ—¨οΈ0