13 ms·

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

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

throwawaymath 7y ago
> But to be clear, you're actively diverting from the point. ... I get why you showed up here, but you're really not addressing the point of the post at all, and in fact you're trying to distract with the suggestion that Signal's publication of that code protects people from this flaw. It doesn't. At all. Wow, that's a pretty hostile (and accusatory) response to a fair ask. This is one (small) step removed from accusing someone of shilling/astroturfing. Let your product stand on its own merits. If you have a good reason why you won't open source Keybase's server implementation, own it. Don't undermine requests to open source the code by publicly accusing people of supporting a competing product. The person you're replying to didn't make an argument in favor of Signal - or any other competing product, for that matter. In my opinion, your response is actively distracting from their request.
- drexlspivey 7y ago
  Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.
  - throwawaymath 7y ago
    Okay, and that's exactly the kind of reasoned response that's appropriate. What's not appropriate is implying the request is simply unfounded because of its source. It's not charitable.
  - elagost 7y ago
    It's a step toward people running their own servers, either federated with Keybase proper, or just as a personal instance. That would be valuable for quite a number of enthusiasts. Federation (like email/XMPP) is a very reasonable feature for any forward-looking communication platform.
    - sethgecko 7y ago
      Then this is not a request for transparency but for them to change their business plan
    - chupasaurus 7y ago
      Keybase's target is to become a central identity point. Other features (like team chat and git repos) are made to showcase what you could do with that.
- malgorithms 7y ago
  Fair enough - I don't want to dilute my point by coming across as too hostile, even though my point is that it seems like a well-crafted diversion. Let me edit it down and your quote of the original can stand.
  - mhluongo 7y ago
    You don't need to apologize IMO ¯\_(ツ)_/¯
- mhluongo 7y ago
  I think it's a pretty reasonable way to combat FUD. It's tough to compete on security because users struggly to know what's actually better (on top of needing convincing security is a worthwhile differentiator in the first place). A client that doesn't trust a server is a great improvement and "show us the server" is a terrible response.
  - throwawaymath 7y ago
    Then the reasonable thing to do is to explain why it's a terrible response. What's unreasonable is to imply that the request is a sideshow in favor of a competing product because of the identity of the person who brought it up. If you have a good reason not to fulfill the request, charitably responding to the request with that reasoning is an educational opportunity for the audience. There's just no need to bring identities into the mix like this, and I think a dispassionate response outlining why the server need not even be trusted would stand on its own.
- throwawaylolx 7y ago
  Well, equally, GP could've disclosed their conflict of interests instead of just using a hit&run one-line red herring. OP makes a post advocating not having to trust a server, and most upvoted comment is someone asking them to open their server so they can trust it? Doesn't make much sense..
  - throwawaymath 7y ago
    Agreed, they could disclose a conflict of interest. But I don't think it matters here, because their request could reasonably have been brought up by someone unaffiliated with Signal. In other words - you don't need to be affiliated with Signal to be in favor of open sourcing the server-side code. It's a fairly common complaint on HN, and I can see why it was the top comment for a while even if I don't ultimately agree with the need to open source the code. Likewise, if you look at the link to the GitHub issue you can see many other people likewise asking for - or reacting to responses to - open source the server code. Do all those people have conflicts of interest? Is it possible that the affiliation with Signal doesn't matter here? Then be charitable, and let your actual reason for not fulfilling the request stand on its own.
PascLeRasc 7y ago
You're also diverting from the point to argue that Signal is worse than Keybase for server trust. Releasing server-side code comes from the open-source philosophy that Keybase claims to be a part of on its website. Several people in that Github issue would like to self-host Keybase servers - open source is all about that kind of accessibility. No one's making the claim that publishing the code would make them trust Keybase more, though Signal arguably has benefited from releasing its code for public audit. What would be the cost of publishing your server-side code?
- stedaniels 7y ago
  Ever worked in licensing large systems that encompass dozens of differently licensed components? That often costs a lot, for many reasons.
99052882514569 7y ago
Imagine how much harder it would be for your dastardly competitors to "distract" and "divert", if you or someone else from your project actually addressed the obviously legitimate question of keeping the server closed-source? I mean other than coquettishly dropping a tantalizing hint by saying 'yet?'. That's nice, but insufficient.
hluska 7y ago
This degree of hostility and the borderline doxing is offputting, to such a point that my trust in your organization is degraded.
- throwawaylolx 7y ago
  Borderline doxing? The original poster literally has this information in their bio of this very website.
  - josh2600 7y ago
    MobileCoin != Signal. I literally do not work for Signal.
    - jhall1468 7y ago
      The only named advisor for MobileCoin is the founder of Signal. "Work" is not the only conflict of interest in the world, and you're dodging by consistently talking about it. We know you don't work for Signal. We also know that you very obviously have a close professional relationship (at the very least) with its founder.
      - josh2600 7y ago
        I have 0 control over the Signal project in any way shape or form. The fact that Moxie advises MobileCoin has nothing to do with his work at Signal. I can't force Moxie or anyone at Signal to do anything. Moxie and I have a close professional relationship but I'm not sure what bearing that has on asking for the code of Keybase's server to be open-sourced. That's not a biased statement, and I would say the same thing in any thread about Telegram, WhatsApp, or FB Messenger's privacy. It's all the same. If you want trust, you have to be open source. That statement has absolutely nothing to do with Signal. Yes I use Signal. Yes I'm a fan of the Signal team's work. No, I don't think Signal would be better off with a closed source server. Yes, I do think Keybase should open source their server. I honestly have no idea why this is even controversial :/.
josh2600 7y ago
Whoa... I don't work for and have never worked for Signal. Feel free to ask Moxie if I have ever worked for Signal and the answer will be an abject "no". I think it's worth meditating on the tradeoffs of your system design. Nothing is perfect. Signal is trying to do the best that it can, and I really think that the starting line in writing secure software is open sourcing the whole thing from top to bottom. Anything less isn't auditable. Note: I edited this post to make the language more addressable. I love the work Keybase is doing, but I want them to open source their server.
- zeeboo 7y ago
  How does open sourcing the server help you audit what their servers are running? There's no way to know if what's open source matches their running code, and if the security of the system depends on the server being open, it's not secure.
  - josh2600 7y ago
    Because if you don't trust it you can run the server yourself and see if the behavior is correct AND over time as we move to a world where servers become better able to verify the code they're running, we can improve the trust model. Given the choice between having the server code open sourced or not, the choice that is higher trust has to be open source.
    - zeeboo 7y ago
      That's just false. You can get all of the trust information necessary from the client. It's exactly the same amount of trust. edit: To be clear, even if they open sourced the server right now, I would not even look at the code to determine if running the client was safe. The only time I would care to look at the server code is if the client's correct operation depends on the server running specific code. If it doesn't do that, then the server code doesn't matter. And if it does do that, I wouldn't trust the system, anyway.
      - josh2600 7y ago
tptacek 7y ago
This looks even less chill than the previous message, which didn't (iirc) accuse "someone from the Signal project?" of making "security theater requests". Your comment would be much better without any allusions to this person's affiliation. Just answer the question directly without casting aspersions. You seem confident in your answer, so that shouldn't be hard.

throwawaymath 7y ago

> But to be clear, you're actively diverting from the point. ... I get why you showed up here, but you're really not addressing the point of the post at all, and in fact you're trying to distract with the suggestion that Signal's publication of that code protects people from this flaw. It doesn't. At all. Wow, that's a pretty hostile (and accusatory) response to a fair ask. This is one (small) step removed from accusing someone of shilling/astroturfing. Let your product stand on its own merits. If you have a good reason why you won't open source Keybase's server implementation, own it. Don't undermine requests to open source the code by publicly accusing people of supporting a competing product. The person you're replying to didn't make an argument in favor of Signal - or any other competing product, for that matter. In my opinion, your response is actively distracting from their request.

drexlspivey 7y ago
Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.
- throwawaymath 7y ago
  Okay, and that's exactly the kind of reasoned response that's appropriate. What's not appropriate is implying the request is simply unfounded because of its source. It's not charitable.
- elagost 7y ago
  It's a step toward people running their own servers, either federated with Keybase proper, or just as a personal instance. That would be valuable for quite a number of enthusiasts. Federation (like email/XMPP) is a very reasonable feature for any forward-looking communication platform.
  - sethgecko 7y ago
    Then this is not a request for transparency but for them to change their business plan
  - chupasaurus 7y ago
    Keybase's target is to become a central identity point. Other features (like team chat and git repos) are made to showcase what you could do with that.
malgorithms 7y ago
Fair enough - I don't want to dilute my point by coming across as too hostile, even though my point is that it seems like a well-crafted diversion. Let me edit it down and your quote of the original can stand.
- mhluongo 7y ago
  You don't need to apologize IMO ¯\_(ツ)_/¯
mhluongo 7y ago
I think it's a pretty reasonable way to combat FUD. It's tough to compete on security because users struggly to know what's actually better (on top of needing convincing security is a worthwhile differentiator in the first place). A client that doesn't trust a server is a great improvement and "show us the server" is a terrible response.
- throwawaymath 7y ago
  Then the reasonable thing to do is to explain why it's a terrible response. What's unreasonable is to imply that the request is a sideshow in favor of a competing product because of the identity of the person who brought it up. If you have a good reason not to fulfill the request, charitably responding to the request with that reasoning is an educational opportunity for the audience. There's just no need to bring identities into the mix like this, and I think a dispassionate response outlining why the server need not even be trusted would stand on its own.
throwawaylolx 7y ago
Well, equally, GP could've disclosed their conflict of interests instead of just using a hit&run one-line red herring. OP makes a post advocating not having to trust a server, and most upvoted comment is someone asking them to open their server so they can trust it? Doesn't make much sense..
- throwawaymath 7y ago
  Agreed, they could disclose a conflict of interest. But I don't think it matters here, because their request could reasonably have been brought up by someone unaffiliated with Signal. In other words - you don't need to be affiliated with Signal to be in favor of open sourcing the server-side code. It's a fairly common complaint on HN, and I can see why it was the top comment for a while even if I don't ultimately agree with the need to open source the code. Likewise, if you look at the link to the GitHub issue you can see many other people likewise asking for - or reacting to responses to - open source the server code. Do all those people have conflicts of interest? Is it possible that the affiliation with Signal doesn't matter here? Then be charitable, and let your actual reason for not fulfilling the request stand on its own.

PascLeRasc 7y ago

You're also diverting from the point to argue that Signal is worse than Keybase for server trust. Releasing server-side code comes from the open-source philosophy that Keybase claims to be a part of on its website. Several people in that Github issue would like to self-host Keybase servers - open source is all about that kind of accessibility. No one's making the claim that publishing the code would make them trust Keybase more, though Signal arguably has benefited from releasing its code for public audit. What would be the cost of publishing your server-side code?

stedaniels 7y ago
Ever worked in licensing large systems that encompass dozens of differently licensed components? That often costs a lot, for many reasons.

99052882514569 7y ago

Imagine how much harder it would be for your dastardly competitors to "distract" and "divert", if you or someone else from your project actually addressed the obviously legitimate question of keeping the server closed-source? I mean other than coquettishly dropping a tantalizing hint by saying 'yet?'. That's nice, but insufficient.

hluska 7y ago

This degree of hostility and the borderline doxing is offputting, to such a point that my trust in your organization is degraded.

throwawaylolx 7y ago
Borderline doxing? The original poster literally has this information in their bio of this very website.
- josh2600 7y ago
  MobileCoin != Signal. I literally do not work for Signal.
  - jhall1468 7y ago
    The only named advisor for MobileCoin is the founder of Signal. "Work" is not the only conflict of interest in the world, and you're dodging by consistently talking about it. We know you don't work for Signal. We also know that you very obviously have a close professional relationship (at the very least) with its founder.
    - josh2600 7y ago
      I have 0 control over the Signal project in any way shape or form. The fact that Moxie advises MobileCoin has nothing to do with his work at Signal. I can't force Moxie or anyone at Signal to do anything. Moxie and I have a close professional relationship but I'm not sure what bearing that has on asking for the code of Keybase's server to be open-sourced. That's not a biased statement, and I would say the same thing in any thread about Telegram, WhatsApp, or FB Messenger's privacy. It's all the same. If you want trust, you have to be open source. That statement has absolutely nothing to do with Signal. Yes I use Signal. Yes I'm a fan of the Signal team's work. No, I don't think Signal would be better off with a closed source server. Yes, I do think Keybase should open source their server. I honestly have no idea why this is even controversial :/.

josh2600 7y ago

Whoa... I don't work for and have never worked for Signal. Feel free to ask Moxie if I have ever worked for Signal and the answer will be an abject "no". I think it's worth meditating on the tradeoffs of your system design. Nothing is perfect. Signal is trying to do the best that it can, and I really think that the starting line in writing secure software is open sourcing the whole thing from top to bottom. Anything less isn't auditable. Note: I edited this post to make the language more addressable. I love the work Keybase is doing, but I want them to open source their server.

zeeboo 7y ago
How does open sourcing the server help you audit what their servers are running? There's no way to know if what's open source matches their running code, and if the security of the system depends on the server being open, it's not secure.
- josh2600 7y ago
  Because if you don't trust it you can run the server yourself and see if the behavior is correct AND over time as we move to a world where servers become better able to verify the code they're running, we can improve the trust model. Given the choice between having the server code open sourced or not, the choice that is higher trust has to be open source.
  - zeeboo 7y ago
    That's just false. You can get all of the trust information necessary from the client. It's exactly the same amount of trust. edit: To be clear, even if they open sourced the server right now, I would not even look at the code to determine if running the client was safe. The only time I would care to look at the server code is if the client's correct operation depends on the server running specific code. If it doesn't do that, then the server code doesn't matter. And if it does do that, I wouldn't trust the system, anyway.
    - josh2600 7y ago

tptacek 7y ago

This looks even less chill than the previous message, which didn't (iirc) accuse "someone from the Signal project?" of making "security theater requests". Your comment would be much better without any allusions to this person's affiliation. Just answer the question directly without casting aspersions. You seem confident in your answer, so that shouldn't be hard.