5 ms·

> While communication is guaranteed to be secure due to the end-to-end encryption implemented in the open-source client apps and the Signal protocol So the cli

> While communication is guaranteed to be secure due to the end-to-end encryption implemented in the open-source client apps and the Signal protocol So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I? I use Signal for its safety characteristics, which as stated are apparently ensured by the client regardless of what the server does, not because of the server, and I continue to agree with Moxie that federation is a white whale that doesn't solve any regular person problems.

fossuser 6y ago
I tend to agree with you - but keybase made a similar argument and then sold out their users to Zoom (with all of the concerns around the CCP's influence over Zoom). When that happens there isn't much recourse except to jump ship. I think this is unlikely with Signal since Brian Acton's $50M donation is contingent on them keeping inline with the mission (iirc) and also Moxie being involved is a good sign. Plus, realistically if the company gets ruined you're probably better of jumping ship anyway (as long as there's somewhere else to go - matrix? urbit?).
DavidSJ 6y ago
A few problems with this: 1) Much (most?) of the time, participants don't get to verify their safety numbers, and in those cases you are at least trusting the server to deliver your messages to the right client. There's a potential vector for man-in-the-middle attack (witting or unwitting) on the server side which shouldn't be dismissed here just because users are "supposed to" verify safety numbers. 2) Their behavior regarding server software might be predictive of their behavior regarding client software in the future. Given network effects, it might not be so easy to leave the Signal ecosystem in the future if your social network is on it, so it's worth knowing right now that it's possible that in the future the client software will also be closed-source.
- FourthProtocol 6y ago
  "..trusting the server to deliver your messages to the right client." This is where I feel a little unsure about Signal. It wants access to my contacts, and so it is possible to poison my contacts to get a rogue recipient into Signal. I would like a Signal in which I have the option to manually add contacts. Ideally a hash or key exchange or something, maybe a la PGP...
  - tptacek 6y ago
    PGP has one of the worst metadata stories in all of secure messaging.
    - FourthProtocol 6y ago
      True but not quite my point.
    - grep_name 6y ago
      Can you elaborate what you mean by this?
      - FourthProtocol 6y ago
        He means that key exchange is frought with trust issues online. An exchange in meat-space is (can be!) 100% reliable, but doesn't scale. PGP is a posterchild for the impracticality of public key crypto. The UK actually made it work in conjunction with identity federation through the Government Gateway, but then the Government Digital Service got hold of it and destroyed any chances of moving it forward. Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
        tptacek 6y ago
        No, this is not at all what I mean.
        6y ago
belorn 6y ago
If you think the security aspect of the server don't matter, then can I please have all the metadata that get generated on the server and which only security is the public statement by Moxie Marlinspike that they do not save the logs or store them. The client only guarantees security in term of the message content. Who talks to who, when, where, how long, and the historical patterns are secured by the policy of the server provider. Trust in the server is critical.
- tptacek 6y ago
  This is really silly. Signal has discussed repeatedly what metadata they keep. It might be sane to ask questions about that, except that every competing messenger keeps the absolute worst case metadata, generally in plaintext, nicely bundled up in SQL tables. At best, you'd be making the claim that Signal might... secretly be as bad as everything else. And, of course, the source code does nothing to do address this concern; they control their servers and can run any secret fork they want. It's a purity test and nothing more.
  - hoophoop 6y ago
    > It's a purity test and nothing more. Wrong. Publishing the server sources allow people to create a parallel and independent service.
    - tptacek 6y ago
      What's stopping you? What does that have to do with having a bit-for-bit identical version to what Signal is running?
      - hoophoop 6y ago
        ...the simple fact that there's no guarantee that either the server or the client would receive updates. That means hard-forking the old server and client and maintain them as an independent project forever. That's what's stopping me and many other people from creating a community and federated version.
hoophoop 6y ago
> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I? You should because any successful centralized messenger is one update away from becoming entirely closed source. If Signal will reach say a billion users it will be able to do that without significant userbase loss, due to network effect. > safety characteristics, which as stated are apparently ensured by the client regardless of what the server does In reality, the contact social graph and the frequency and pattern of messages between users is leaked. Any global observer can do a correlation attack thanks to the centralized servers (and absence of onion routing).
jjav 6y ago
> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I? What operations does your client do? How would you know? If the client is open source and the build is reproducible and you can built it yourself to compare the binary with the official binary on the app store, then.. yes, you can trust that the client is guaranteeing your end-to-end encryption. If there is a snapshot of open source code which doesn't match the official binary, you have no way to know what the client you run is actually doing. That's why you should care. This has nothing to do with trusting Signal, good people. If your threat model is such that you care about secure messaging, you can't just trust a binary that's handed to you.

fossuser 6y ago

I tend to agree with you - but keybase made a similar argument and then sold out their users to Zoom (with all of the concerns around the CCP's influence over Zoom). When that happens there isn't much recourse except to jump ship. I think this is unlikely with Signal since Brian Acton's $50M donation is contingent on them keeping inline with the mission (iirc) and also Moxie being involved is a good sign. Plus, realistically if the company gets ruined you're probably better of jumping ship anyway (as long as there's somewhere else to go - matrix? urbit?).

DavidSJ 6y ago

A few problems with this: 1) Much (most?) of the time, participants don't get to verify their safety numbers, and in those cases you are at least trusting the server to deliver your messages to the right client. There's a potential vector for man-in-the-middle attack (witting or unwitting) on the server side which shouldn't be dismissed here just because users are "supposed to" verify safety numbers. 2) Their behavior regarding server software might be predictive of their behavior regarding client software in the future. Given network effects, it might not be so easy to leave the Signal ecosystem in the future if your social network is on it, so it's worth knowing right now that it's possible that in the future the client software will also be closed-source.

FourthProtocol 6y ago
"..trusting the server to deliver your messages to the right client." This is where I feel a little unsure about Signal. It wants access to my contacts, and so it is possible to poison my contacts to get a rogue recipient into Signal. I would like a Signal in which I have the option to manually add contacts. Ideally a hash or key exchange or something, maybe a la PGP...
- tptacek 6y ago
  PGP has one of the worst metadata stories in all of secure messaging.
  - FourthProtocol 6y ago
    True but not quite my point.
  - grep_name 6y ago
    Can you elaborate what you mean by this?
    - FourthProtocol 6y ago
      He means that key exchange is frought with trust issues online. An exchange in meat-space is (can be!) 100% reliable, but doesn't scale. PGP is a posterchild for the impracticality of public key crypto. The UK actually made it work in conjunction with identity federation through the Government Gateway, but then the Government Digital Service got hold of it and destroyed any chances of moving it forward. Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
      - tptacek 6y ago
        No, this is not at all what I mean.
        6y ago

belorn 6y ago

If you think the security aspect of the server don't matter, then can I please have all the metadata that get generated on the server and which only security is the public statement by Moxie Marlinspike that they do not save the logs or store them. The client only guarantees security in term of the message content. Who talks to who, when, where, how long, and the historical patterns are secured by the policy of the server provider. Trust in the server is critical.

tptacek 6y ago
This is really silly. Signal has discussed repeatedly what metadata they keep. It might be sane to ask questions about that, except that every competing messenger keeps the absolute worst case metadata, generally in plaintext, nicely bundled up in SQL tables. At best, you'd be making the claim that Signal might... secretly be as bad as everything else. And, of course, the source code does nothing to do address this concern; they control their servers and can run any secret fork they want. It's a purity test and nothing more.
- hoophoop 6y ago
  > It's a purity test and nothing more. Wrong. Publishing the server sources allow people to create a parallel and independent service.
  - tptacek 6y ago
    What's stopping you? What does that have to do with having a bit-for-bit identical version to what Signal is running?
    - hoophoop 6y ago
      ...the simple fact that there's no guarantee that either the server or the client would receive updates. That means hard-forking the old server and client and maintain them as an independent project forever. That's what's stopping me and many other people from creating a community and federated version.

hoophoop 6y ago

> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I? You should because any successful centralized messenger is one update away from becoming entirely closed source. If Signal will reach say a billion users it will be able to do that without significant userbase loss, due to network effect. > safety characteristics, which as stated are apparently ensured by the client regardless of what the server does In reality, the contact social graph and the frequency and pattern of messages between users is leaked. Any global observer can do a correlation attack thanks to the centralized servers (and absence of onion routing).

jjav 6y ago

> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I? What operations does your client do? How would you know? If the client is open source and the build is reproducible and you can built it yourself to compare the binary with the official binary on the app store, then.. yes, you can trust that the client is guaranteeing your end-to-end encryption. If there is a snapshot of open source code which doesn't match the official binary, you have no way to know what the client you run is actually doing. That's why you should care. This has nothing to do with trusting Signal, good people. If your threat model is such that you care about secure messaging, you can't just trust a binary that's handed to you.