I may be coming in to this conversation a bit late, but I work on the Keybase project. I’m keybase.io/chris on keybase, not that I can prove that easily here (yet :-) ). This might help: https://chris.keybase.pub/lobsters.txt . Some people asked me to come here and offer support for this.
We and plenty of others have already written extensively about why PGP is inadequate (especially the old keyserver model, which is unusable for most people and dangerous in certain ways), and (2) why we need to find a way to let people cryptographically prove connections between services and keys, using usable software. So I won’t add more here. But a few specific thoughts:
(1) I personally would want to look at a user in Keybase and, if they’re interested, know who they are here on lobste.rs. I only lurk here occasionally, but I feel like I can learn a lot more about a person’s identity following them here than, say, to other services.
(2) I’d like to see transitive connections between something like their personal site, their GitHub (or upcoming other git integrations), and lobste.rs.
(3) The PR actually isn’t complicated, and it doesn’t prevent connections to other services, cryptographic or not.
(4) There’s not much I can say to the “Keybase is a private company” thing. Not all companies are evil. But answering that is like responding when my brother tells me to relax. I AM FREAKING RELAXED DAN. And yeah, Keybase is funded in the traditional model, and tbh we couldn’t have gotten it to where it is without that model.
(5) There are different forms of Internet idealism that share a common user base : decentralization, privacy, security, “freedom” (as in free), etc. These are all different ideals that we idealists are all pursuing. But almost no one is tackling every single one at once with a project, and if so, good luck to that project. One of my least favorite things is when the different attempts to solve these problems with the Internet don’t satisfy each other on every axis, and halt the advancement of all of them. You can imagine lobste.rs being mad that Keybase is a company, Keybase being mad lobste.rs data isn’t digitally signed (or its chat encrypted), IPFS being mad both aren’t decentralized enough. Everyone mad at everyone. But all of us can help each other.
Like I said, there’s nothing I can say to this, except I’d love to see Keybase<>Lobsters, and if you do it, I’d encourage you to remove the integration as soon as you feel Keybase is sucky. I bet that wouldn’t happen.
And nothing ever changes and we’re still stuck with [pg]pg that even many tech people can’t figure out… 🤷
Hi, Chris. Thank you.
My concern about “Keybase is a private company” is that it will compel your developers to make decisions that are technically weak. I’m not just talking about the server source code here–though that is huge.
I am going to construct some specific questions as examples of a class of questions that I think are important. (I invite other crustaceans to ask questions, while we’ve got Chris’s ear.)
Is or is not the Keybase company willing to make a technical improvement to the chat protocol which would eliminate the company’s ability to measure user engagement but increase user security?
Would the Keybase company merge a PR into the official client which added a UI to the that presents an option for connecting to an alternative server?
What happens to files I have stored in KBFS and my contacts list, etc if Facebook buys the Keybase company? Would the company merge a PR now that strengthens users ownership of their data, even if doing so makes Keybase a less attractive acquisition?
yes, I would choose user security over user engagement tracking. Working on Keybase the product is a nightmare for us, from a UX management standpoint. That is, compared to previous work we’ve done, where we had a lot of good tools at our disposal. if you look through our client you’ll see there’s nothing in there that exists to serve tracking purposes. Everything is about trying to make usable, cryptography. Any compromises are typically an internal conflict between convenience and security (which is the real dilemma, not tracking and security). Heck, even our website doesn’t have google analytics or any 3rd party hosted JS. Lobstahs and Keybase FTW.
in spirit yes, in practice no. I fear shooting myself in the foot here by admitting that to the people who place decentralization on a higher pedestal than encryption, when forced to choose. But our biggest fear would actually be security related. We’re suuuuuper scared of most PR’s. Even small things, like a few lines, we end up re-writing from scratch ourselves. I honestly don’t care about hosting Keybase’s data. It would be cheaper/cooler if a user could host it elsewhere. To be clear, though, the second biggest issue is effort. Keybase isn’t just a half-dozen API endpoints: there’s server infrastructure in the form of traditional API endpoints, real-time streaming stuff, and an encrypted filesystem. Moreover there’s a presumption that users are all connected, so it’s hard to imagine how the client would work where you and I can talk on it, but my data is on my servers and your data is on your servers. It would take multiple person-years of effort to have some awesome thing working like that. And Keybase wouldn’t be where it is right now if we focused on this, and realistically….something like 1-in-1000 Keybase users ask for this. As an alternative, consider the fact that Keybase lets you speak easily and securely with someone else to secure other modes of comm. Want to use IPFS + some other encryption software? Exchange your keys on Keybase and don’t look back. We got you started safely! A Keybase integration makes this possible, and we’re happy to have helped. Want to use Signal? Share your phone number and compare your security codes on Keybase. Want to use Tarsnap for backups? Keep your key in KBFS. You can bootstrap using all kinds of other software using Keybase; we make totally decentralized software better. And then don’t actually use Keybase’s chat or filesystem for anything else. I’d propose this is the better answer than a Keybase that can understand different servers.
there’s nothing I can do to address the “what’s stopping you from eventually releasing a bad client” angle… I don’t want this to happen. My answer will continue to be “the client wouldn’t be this good if we weren’t a company” even if it appears that by being a company we’re more likely to have a bad client.
hope I haven’t shot myself in the foot with admitting some of the difficulties here. Again, (1) this integration would just be used by the people who want it, and (2) lobste.rs could remove it whenever they decide they dislike it.
Thanks for the q!
I do appreciate your engaging. I agree with all your points. On point (4), I don’t think any ill will is necessary to wind up with bad outcomes. The incentives of for-profit corporations are such that, when the service they’re providing is essentially for the public benefit, everyone should give careful thought to how the company’s needs and the public’s needs might diverge over time.
Case in point: I’m sure that my employer was sincere about “don’t be evil” when it was first raised as an informal motto - at a time when the company was much closer in size to the size Keybase is now. I’m equally sure that nobody at the top feels that they have changed direction or betrayed their ideals, even with all the controversies the company has been through in the past two years.
With all that said, as I remarked elsewhere in this thread, I rely on Keybase day-to-day and am in favor of the integration.
Would you be willing to spend the necessary implementation work so that Keybase doesn’t compete with OpenPGP public key signatures / web of trust / keyservers, but instead cooperates with it? Specifically if the user has a GPG key by supporting in Keybase to:
A) Make the signatures used in account proofs so that they can be verified with a GPG public key.
B) Export/sync account claims/associations with GPG public key identities.
C) Allow a user to automatically sign their GPG keys when they follow another user. (Use the appropriate format to indicate that the fingerprint was not received over a secure channel and the identity of the human wasn’t checked. Only sign the identities in the key that were verified. Optionally: If the user states that they received a fingerprint e.g. in person and verified the identity of the human, by e.g. pasting a fingerprint of another user, indicate that instead.)