It looks like Signal isn't as open source as you thought it was anymore

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

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?).

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.

"..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...

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.

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.

PGP has one of the worst metadata stories in all of secure messaging.

> 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).

> It's a purity test and nothing more.

Wrong. Publishing the server sources allow people to create a parallel and independent service.

What's stopping you? What does that have to do with having a bit-for-bit identical version to what Signal is running?

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

True but not quite my point.

Be kind. Don't be snarky. Respond to the strongest plausible interpretation of what someone says.

Trust is a personal relationship. I am not making a claim that such trust should be abandoned because they delayed an update and did not transparently and openly communicated with the community about what they are doing on the server side or why. A personal relationship is personal, and what is or isn't a problem in building and maintaining that trust is up to each person.

I do however claim that the placed trust in signals servers is critical for the security, and that the server side security matter. Who runs the server matters and what the server code does also matters.

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

Any independent server is of necessity going to be an independent project forever, so I'm not sure what your difficulty is here.

Can you elaborate what you mean by this?

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.

No, this is not at all what I mean.

Then pray tell good sir.

Metadata problems in messaging systems are about what data about the communication leaks.

Sorry, I suspect I'm missing something obvious. You specifically said PGP, which is an encryption program that provides cryptographic privacy and authentication for data communication.

And above you're saying it's about meta data problems in messaging systems. What is PGP's bad meta data story you were referring to?

We're into the weeds here on this thread but the search bar below will avail.

A quick entry point might be found here: https://crypto.stackexchange.com/questions/42247/are-the-met...

Essentially, for most PGP workflows, PGP encrypts the body of the message but the entirety of the metadata (things like sender, recipient, subject line, basically anything you’d think of as “metadata”) are fully unencrypted.

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

If you believe that this webpage was delivered securely to your computer, then PKI might be practical. Of course, there are a few implementation details with that PKI.

This is not a problem with PGP. This is a problem with an application of PGP.