Just use federated systems like Matrix or Tox. Signal is just yet another silo and not a long-term solution amid increasing government censorship. The same applies to Threema, Telegram and others.
Domain-name-based federation is a half-assed solution to data portability. It gives special privileges to people who can run always-on nodes, which not everyone can or should be doing. It’s also tied to the domain name system, which is neither practical nor ideal.
I really want to disagree with you but I have come to think the same way over the last few months, having myself run a matrix home server and an XMPP server.
If my server gets taken down, people have to regroup and find a new one somehow.
If Signal goes down, people have to regroup and find a new service somehow.
There’s not much difference here to the average user. If they can’t talk they can’t talk, regardless of everyone else.
Sure, the first option is better because the rest of network stays up, but it’s not enough of an advantage compared to the benefits of a centralised system.
If anything, the ease of moving from WhatsApp to Signal highlighted just how easy it can be to go from silo to silo. It doesn’t even feel like you have an ‘account’ in the traditional sense.
There are lots of big problems to solve with P2P, most of them to do with mobile and multiple devices, but until someone gets there I’m just glad that people are looking at Signal over WhatsApp.
I tend to believe that federated networks, while obviously being harder to block than centralized ones, are also no panacea against government censorship. Because as censor, you now have to block not a single entity, but multiple, which is also doable. And the nodes in a federated network are also inflexible, as they have a unique name that identifies them. Which is nice for users, but also helps the censor to track them. As soon as a node is one the censor’s list, it’s only option is to reappear under a different name (which is bad for users).
Not sure if this applies to all federated networks, but probably to most. If you have counterexamples then please share and explain how they avoid those, IHMO inherent properties of federated networks.
How do federated systems approach problems that require hardware solutions (e.g. Signal’s use of SGX)? Is there a way to guarantee that whatever server is running for a particular federated node is using the correct hardware?
That’s exactly what SGX does - it guarantees that the in-enclave code matches the recorded signature (or that intel have been compromised). Every federated node would need an intel SGX-compatible CPU but no other issues.
In the case of signal, the server sends a blob signed by intel (very difficult to forge) which confirms
The hash of the server code
The hash of signals public key
The version of intel CPU / enclave
Arbitrary data sent by the signal server
One approach from there would be: the ‘arbitrary data’ bit contains a public key, which your signal client can use to encrypt messages to the server. The corresponding private key does not leave the enclave (and you can verify that by comparing the open source implementation with the hash of the server code).
I find it pretty hilarious that the same people who have been so much against federation are now urging third party (proxy) servers to be set up. This again shows how decentralisation has its merits. If the US government rather then the Iranian one would want to shut down Signal they’d be able to topple the entire system by shutting down the company and/or their servers.
Wow, the docker-compose repo is really bad. Moxies initial version even used http for downloading nginx.
micahflee points out that the Dockerfile should entirely be replaced by the nginx Docker image. Also there are some links to hosts that aren’t even running/domains that point into the nirvana (uptime.signal.org).
I believe moxie should stay within his area of expertise, than ?single-handedly? push some PoC idea of his own. I’m also quite sure tor-project would happily volunteer with anti-censorship-circumvention systems recommendations in case Signal would reach out for help.
Instead the issue feature tab got removed from the repository. I hope they won’t have some sort of security bugs when they implement their sgnl://signal.tube/#<url> proxy handler method.
Just use federated systems like Matrix or Tox. Signal is just yet another silo and not a long-term solution amid increasing government censorship. The same applies to Threema, Telegram and others.
Now I’m feeling like a broken record, but…
Domain-name-based federation is a half-assed solution to data portability. It gives special privileges to people who can run always-on nodes, which not everyone can or should be doing. It’s also tied to the domain name system, which is neither practical nor ideal.
Either do real P2P, or don’t bother pretending.
I really want to disagree with you but I have come to think the same way over the last few months, having myself run a matrix home server and an XMPP server.
There’s not much difference here to the average user. If they can’t talk they can’t talk, regardless of everyone else.
Sure, the first option is better because the rest of network stays up, but it’s not enough of an advantage compared to the benefits of a centralised system.
If anything, the ease of moving from WhatsApp to Signal highlighted just how easy it can be to go from silo to silo. It doesn’t even feel like you have an ‘account’ in the traditional sense.
There are lots of big problems to solve with P2P, most of them to do with mobile and multiple devices, but until someone gets there I’m just glad that people are looking at Signal over WhatsApp.
Who says you need to use matrix.org? There are many, many options…
Far more than just the 1 single option you get with moxiechat.
I tend to believe that federated networks, while obviously being harder to block than centralized ones, are also no panacea against government censorship. Because as censor, you now have to block not a single entity, but multiple, which is also doable. And the nodes in a federated network are also inflexible, as they have a unique name that identifies them. Which is nice for users, but also helps the censor to track them. As soon as a node is one the censor’s list, it’s only option is to reappear under a different name (which is bad for users).
Not sure if this applies to all federated networks, but probably to most. If you have counterexamples then please share and explain how they avoid those, IHMO inherent properties of federated networks.
How do federated systems approach problems that require hardware solutions (e.g. Signal’s use of SGX)? Is there a way to guarantee that whatever server is running for a particular federated node is using the correct hardware?
That’s exactly what SGX does - it guarantees that the in-enclave code matches the recorded signature (or that intel have been compromised). Every federated node would need an intel SGX-compatible CPU but no other issues.
In the case of signal, the server sends a blob signed by intel (very difficult to forge) which confirms
One approach from there would be: the ‘arbitrary data’ bit contains a public key, which your signal client can use to encrypt messages to the server. The corresponding private key does not leave the enclave (and you can verify that by comparing the open source implementation with the hash of the server code).
I find it pretty hilarious that the same people who have been so much against federation are now urging third party (proxy) servers to be set up. This again shows how decentralisation has its merits. If the US government rather then the Iranian one would want to shut down Signal they’d be able to topple the entire system by shutting down the company and/or their servers.
I’m not familiar with U.S. legal system, but, how easy is it to shutdown an NPO compared to a real business?
I think in a few European countries it’s really complex to do so.
Wow, the docker-compose repo is really bad. Moxies initial version even used http for downloading nginx. micahflee points out that the Dockerfile should entirely be replaced by the nginx Docker image. Also there are some links to hosts that aren’t even running/domains that point into the nirvana (uptime.signal.org).
Also others are pointing out that the Proxy isn’t resistant to probing: https://github.com/net4people/bbs/issues/60
I believe moxie should stay within his area of expertise, than ?single-handedly? push some PoC idea of his own. I’m also quite sure tor-project would happily volunteer with anti-censorship-circumvention systems recommendations in case Signal would reach out for help.
Instead the
issuefeature tab got removed from the repository. I hope they won’t have some sort of security bugs when they implement theirsgnl://signal.tube/#<url>proxy handler method.Why not use Tor for this, which is a general and well-known solution?
Lack of mobile clients, probably.
In theory they could bundle a Tor client in Signal and send traffic through its SOCKS/HTTP proxy (definitely doable on Android).
But in practice it’d probably be hell.
If I’m already running Nginx would it be enough to use this file? https://github.com/signalapp/Signal-TLS-Proxy/blob/master/data/nginx-relay/nginx.conf