6 ms·
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 thi
by josh2600 8y 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 8y agoHow 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 8y agoBecause 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 8y agoThat'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 8y agoAs just one example, you have no idea what metadata logging the server is doing. This is just the surface.
- zeeboo 8y agoSo audit the client assuming that all of the traffic it sends is in the clear (i.e. not over https to keybase's servers). If that's not sufficient, then don't use keybase. Regardless, until you have a way to ensure the server is running the code you expect it to be running (can this even exist? what about hardware level attacks on the servers keybase is running?) the server code is useless from a security perspective.
- josh2600 8y agoYou’re just pretending the server is outside of scope. In reality you have to consider the security model of the whole system. The server is not outside of scope.
- zeeboo 8y agoYou can construct a client such that the server IS outside of the scope. You can determine if a client has such a property from the client alone. I would only want to use a client such that the server is outside of the scope. It's strictly better if the client has this property even if the server is open and magically trusted to be running the code you expect. The keybase client is such a client. If it isn't please inform someone with details on why. edit: Do you audit all of the software running on all of the routers between you and keybase's servers? Why or why not? If not, why does this reasoning not extend to the servers? Why would the routers not part of the whole system, top to bottom?
- josh2600 8y agoIt would be great to audit all of the software running on all of the routers I use. I hope that we someday move to a model where all routers run open-source attestable software. Let me phrase this another way: if there's nothing to hide on the server, why isn't it open source? We can go back and forth on this forever. My position is simple: strictly speaking, it's more rational to trust open source software. Trusting closed source software ultimately boils down to "trust me". I would love to reduce the degrees to which we have to blindly trust the systems we use.