I think a half-way point is needed for something to be truely durable. I agree with the criticisms of P2P in that you need to make some privacy tradeoffs. But durability is another concern (as we've seen recently with the takedown of Element from the Play Store). Is it possible for somebody else to spin-up a new centralised Signal server? Why isn't the server code-base open source?
Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now. But the capability would be there. That way, if x government chooses to go after Signal's servers, the availability of all the code needed to run a replacement is already available.
As it stands, we are placing a lot of trust in the Signal Foundation for communication (assuming we rely on the Signal app/service). I have no problem with a central server being used for communication if I can communicate data in a zero-trust way. But I want assurance that that server can be quickly and easily replaced in the event it goes down.
EDIT: I stand corrected. Server code is here: https://github.com/signalapp/Signal-Server
Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
> Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now.
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
>What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
If you read the link, what's discouraged is using the non official client to connect to the Signal service, or using the "Signal" name on something that isn't produced / run by OWS.
There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.
In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.
“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“
> People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect
That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
Of course they do. That's why millions of us have been pushing for years for DNSSEC, TLS (hopefully someday with DANE), Tor onion services, RPKI, etc..
A bad state of affairs is no reason to keep going in the wrong direction.
ICANN's DNS roots are flawed by centralization, and DNS itself is a very insecure protocol. However, DANE is still a major progress over the browser CAs, because you can stop trusting random corporations and state agencies (the CAs, who are known to emit fake certificates) and instead trust your naming scheme.
Agreed DNS might not be the best candidate for this. However DNSSEC validation within the LAN (eg. on your local router, not @Google/CloudFlare) mitigates a lot of risks associated, and a new secure backward-compatible protocol like the GNU Name System (yes that's a thing) may eventually overcome those risks entirely in clever ways.
There's literature and actual deployments on tying name resolution to public key discovery in location-addressed protocols (eg. .onion, .i2p..) and it makes entire sense in my view. If such concerns interest you, check out the latest GNS draft RFC: https://lsd.gnunet.org/lsd0001
No, DANE is a step back from CAs. When the Certificate Transparency logs show a CA has misissued, any of Google, Apple, or Microsoft can destroy that CA, as has happened with several of the largest CAs. Meanwhile, not only is there no such thing as Certificate Transparency for DANE, but you also can't revoke .COM at all.
Pretty much every way you look at DANE, it's a debacle.
I feel that's pretty disingenuous. Like you noticed the server-side code is active, and changing server address would be a niche-of-a-niche activity. Also, what would be the point of going after Signal's servers? Even if a/the government got a hold of all the data in there, it's encrypted with client keys. I mean sure, if they took over secretly and became a malicious MITM that's different, but it's still only for any future messages, not history. Not to mention I'd be inclined to believe they'd get the word out.
Signal's research and protocol is already used in, well, basically each and every discussion/video platform. WhatsApp, Telegram, Skype, Facebook Messenger, Google Messages, Duo... so it's hard to see Signal becoming more ubiquitous. Seeing the app more will probably happen naturally when events happen (like the WhatsApp privacy change) to drive people towards more secure platforms, but honestly I don't really see a major shift anytime soon.
That's true for the fundamental part of sending and receiving messages, but at least one ancillary feature (contact discovery) requires trusting the server. They do have a setup with an Intel SGX enclave for remote attestation but I'm not knowledgeable on the limitations of this, although I understand that there are some.
Good point, I was just considering the messaging part. It'd be useful to be able to opt out of contact discovery, as I'm not sure you can do this on the current client.
look in their forums , few get it running an those who do discover that certain features like reactions etc don't work. So why exactly is happening on the server ??
Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now. But the capability would be there. That way, if x government chooses to go after Signal's servers, the availability of all the code needed to run a replacement is already available.
As it stands, we are placing a lot of trust in the Signal Foundation for communication (assuming we rely on the Signal app/service). I have no problem with a central server being used for communication if I can communicate data in a zero-trust way. But I want assurance that that server can be quickly and easily replaced in the event it goes down.
EDIT: I stand corrected. Server code is here: https://github.com/signalapp/Signal-Server Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.