I don’t think they found their ‘killer-app’ yet. But to me, what they were doing up to now always made sense, in some way or other. And I think/hope there’ll be a problem sometime in the future that they’ll be perfectly equipped to handle. ChatOps might not be quite that yet, but I think is a good fit, in any case.
Interesting… I’ve still to understand the “model” of their platform thoug. The client is open source but the server environment, if there’s one, is not? Am I right?
All I have to say is “shut up and take my money,” but they don’t appear set up to do that. I’m very hesitant to put a free service into my production path.
They say that as operators of the server, they can’t get your ssh keys. That would be true if they didn’t also build and distribute the binaries for their open source client.
I’m not saying they’d do something nefarious, yadda yadda, what if a bad actor takes over their build infrastructure, look at node.js, yadda yadda. I think this side of the topic is well understood.
I guess there is no way around that, if you want to do what they set out to do. There’s always a risk, and there is no mitigation against certain types of risk if you can’t or don’t want to compromise on features (they can’t, the feature is their service in this case). All you can do is make the risk understood (which I think they do a good job of, I certainly don’t feel they are not honest about that).
Ubuntu has their client packaged btw, as far as I know, I’m sure other distributions have too.
I’d be interested in what you would you suggest as a viable alternative approach?
But yes, if/when distros build and publish the keybase client and put it under their respective security umbrellas, AND if some independent analysts declare that the client’s E2E works as advertised (server can’t read ssh keys nor messages etc), then that would solve some of my complaints. You see, I do not particularly worry about the upstream author of bash putting a back door in, because distros build it and put their reputations on the line. Same deal.
frkl, in general, keybase just needs to release their source code for the server and whatever related source code. That would solve all of my complaints eventually, as the community evaluates the code, breaks it, improves it, etc. (Or maybe we’d decide the hype wasn’t deserved. How should I know, yet?) If it’s legit, then I’m confident that most users will use the official instance anyway. I’m sure I would.
I just want them to pull that left hand out from behind their back. This is a security product. Show me your hands. Duh.
I might even be willing to accept keybase if they (or somebody) releases a free software alternative server that the client can connect to. Even if it has less features? (Am I negotiating with capitalists?) I guess this is called a reference implementation.
I just will NOT tell all my friends and family to use a closed source non-free communications platform again. (I brought big G a hundred innocent souls before I realized what was going on there… My heart is broken. Never again.)
How does releasing the server source help audit the security of the system? You can’t be sure that the source they release is the source their running, and the whole point of E2E encryption is that you only need to audit the source of the endpoints, and in this case, that source is open. Additionally there has been a (paid for by keybase) 3rd party security audit: https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf
I do agree that it would help with the “keybase shuts down” scenario, though.
Releasing the server source would be an act of good will, it would be morally correct (to me), and it would be ethically correct (among certain reputable segments of the internet population).
If we have faith in E2E, I guess we don’t have to trust the servers? Yes, that’s the whole point.
Of course, what if that’s not the source code that’s actually running?
Well, see https://signal.org/blog/private-contact-discovery/, specifically under the heading Trust But Verify. As you can see, the problem isn’t ‘solved’ but at least one group has taken a whack at it.
The signal server is open source. btw.. But as you know I’m sure, keybase is far more ambitious. kbfs makes me daydream…
Economic and moral arguments are fine. I don’t intend to argue with those.
I’ve read that signal blog before, and it leaves me with some questions. For example, even if you’re sure you’re contacting the secure enclave, and that it’s running the software it’s claiming it is, the enclave has to have some sort of key to decrypt the messages you’re sending it, otherwise anyone could read them. How do you know someone else doesn’t have that key? Indeed, it seems like those first assumptions about correctly contacting the enclave are dubious: how do you know that they don’t just have the “secure enclave’s” key and are pretending to be one? Have you physically inspected their hardware and agree that the packets are being routed to the correct server? I’d love to learn why these things aren’t actually problems.
But until then, it seems like it has just put up some smoke and mirrors to distract you from just trusting them. It probably helps against attackers compromising their servers, but it shouldn’t be possible for that to be a threat in the first place. It’s fundamentally worse even if the source is open, because it’s strictly better when the server source is irrelevant. I can run keybase with zero trust in their servers, but I’ll always have to have some amount of trust in signal.
Okay. I don’t know this part… What is the difference between the Keybase client and the Signal client that makes server trust unnecessary for one and necessary for the other?
I wonder what their target market segment is?
I’d think shops that work at any scale would have had to automate by now using LDAP or some other centralized auth mechanism.
We use jumpcloud for this purpose at my current job, but if I were to start a company, I might consider keybase..
I still do not understand how they are planning to make money though, which I find worrying.
I don’t think they found their ‘killer-app’ yet. But to me, what they were doing up to now always made sense, in some way or other. And I think/hope there’ll be a problem sometime in the future that they’ll be perfectly equipped to handle. ChatOps might not be quite that yet, but I think is a good fit, in any case.
Interesting… I’ve still to understand the “model” of their platform thoug. The client is open source but the server environment, if there’s one, is not? Am I right?
That’s right: https://github.com/keybase/client/issues/6374
All I have to say is “shut up and take my money,” but they don’t appear set up to do that. I’m very hesitant to put a free service into my production path.
They say that as operators of the server, they can’t get your ssh keys. That would be true if they didn’t also build and distribute the binaries for their open source client.
I’m not saying they’d do something nefarious, yadda yadda, what if a bad actor takes over their build infrastructure, look at node.js, yadda yadda. I think this side of the topic is well understood.
I guess there is no way around that, if you want to do what they set out to do. There’s always a risk, and there is no mitigation against certain types of risk if you can’t or don’t want to compromise on features (they can’t, the feature is their service in this case). All you can do is make the risk understood (which I think they do a good job of, I certainly don’t feel they are not honest about that).
Ubuntu has their client packaged btw, as far as I know, I’m sure other distributions have too.
I’d be interested in what you would you suggest as a viable alternative approach?
Ubuntu builds the client from source, then? (One would hope they’d always do that..) Let’s see… Hm, I can’t find a keybase package in Ubuntu. https://packages.ubuntu.com/search?keywords=keybase&searchon=names&suite=all§ion=all
But yes, if/when distros build and publish the keybase client and put it under their respective security umbrellas, AND if some independent analysts declare that the client’s E2E works as advertised (server can’t read ssh keys nor messages etc), then that would solve some of my complaints. You see, I do not particularly worry about the upstream author of bash putting a back door in, because distros build it and put their reputations on the line. Same deal.
frkl, in general, keybase just needs to release their source code for the server and whatever related source code. That would solve all of my complaints eventually, as the community evaluates the code, breaks it, improves it, etc. (Or maybe we’d decide the hype wasn’t deserved. How should I know, yet?) If it’s legit, then I’m confident that most users will use the official instance anyway. I’m sure I would.
I just want them to pull that left hand out from behind their back. This is a security product. Show me your hands. Duh.
I might even be willing to accept keybase if they (or somebody) releases a free software alternative server that the client can connect to. Even if it has less features? (Am I negotiating with capitalists?) I guess this is called a reference implementation.
I just will NOT tell all my friends and family to use a closed source non-free communications platform again. (I brought big G a hundred innocent souls before I realized what was going on there… My heart is broken. Never again.)
How does releasing the server source help audit the security of the system? You can’t be sure that the source they release is the source their running, and the whole point of E2E encryption is that you only need to audit the source of the endpoints, and in this case, that source is open. Additionally there has been a (paid for by keybase) 3rd party security audit: https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf
I do agree that it would help with the “keybase shuts down” scenario, though.
Releasing the server source would be an act of good will, it would be morally correct (to me), and it would be ethically correct (among certain reputable segments of the internet population).
If we have faith in E2E, I guess we don’t have to trust the servers? Yes, that’s the whole point.
Well, see https://signal.org/blog/private-contact-discovery/, specifically under the heading Trust But Verify. As you can see, the problem isn’t ‘solved’ but at least one group has taken a whack at it.
The signal server is open source. btw.. But as you know I’m sure, keybase is far more ambitious.
kbfsmakes me daydream…Economic and moral arguments are fine. I don’t intend to argue with those.
I’ve read that signal blog before, and it leaves me with some questions. For example, even if you’re sure you’re contacting the secure enclave, and that it’s running the software it’s claiming it is, the enclave has to have some sort of key to decrypt the messages you’re sending it, otherwise anyone could read them. How do you know someone else doesn’t have that key? Indeed, it seems like those first assumptions about correctly contacting the enclave are dubious: how do you know that they don’t just have the “secure enclave’s” key and are pretending to be one? Have you physically inspected their hardware and agree that the packets are being routed to the correct server? I’d love to learn why these things aren’t actually problems.
But until then, it seems like it has just put up some smoke and mirrors to distract you from just trusting them. It probably helps against attackers compromising their servers, but it shouldn’t be possible for that to be a threat in the first place. It’s fundamentally worse even if the source is open, because it’s strictly better when the server source is irrelevant. I can run keybase with zero trust in their servers, but I’ll always have to have some amount of trust in signal.
Okay. I don’t know this part… What is the difference between the Keybase client and the Signal client that makes server trust unnecessary for one and necessary for the other?
The contacts you send to signal being disguised requires you to trust their correct implementation of the secure enclave.
Forget I said that, I’m an idiot. I did an ‘apt search’ on one of my machines and forgot I installed their ppa…
And yes, fair points…