• relies on a centralized authentication server
• bans third party clients
• requires a phone number to create an account despite no longer supporting SMS
• marketing "Perfect Forward Secrecy" AKA "Forward Secrecy"[0].
I favor Session Private Messenger[1] because it is decentralized and allows third party clients, but Signal enthusiasts warn me that the Session client may, hypothetically, at some future date, integrate a cryptocurrency, as the Signal client already does[2].
Yes, Signal is (intentionally, i.e. as a stated design goal!) not federated, and I'm not super happy about it.
Yes, it includes a cryptocurrency nobody asked for, and I'm definitely not happy about that.
Yes, they've dared to dabble with trusted computing, and Intel SGX at that! (Although only in a purely-additive way, which I find really hard to disagree with, personally.)
But they have done so much for giving users a reasonable chance at evading the warrant-less wiretapping that is dragnet data collection.
Signal has pushed WhatsApp to become end-to-end encrypted by default, and that might have very well set the most important precedent for encryption-by-default in the recent past (see the UK's current legislation, and the EU's attempts of doing the same).
They're continuously pushing the envelope and are collaborating with academic cryptgraphic researchers on pq-safety, which will trickle down into all non-Signal users of the Signal protocol before too long (which includes WhatsApp and Facebook Messenger, making up for multiple billion daily users).
Yes, we should continue to hold them to a high standard, but I'd love if we could sometimes also keep things in perspective.
[1] I know there was some controversy because someone (Signal, maybe?) accused them of using a custom encryption scheme that was poorly designed. I didn't follow that drama very closely, but given Telegram is still around and there hasn't been any outrageous news claiming its encryption getting cracked, I assume it was a mistaken claim.
Defaults matter.
> given Telegram is still around and there hasn't been any outrageous news claiming its encryption getting cracked, I assume it was a mistaken claim.
“Innocent until proven guilty” is for criminal systems, not security analysis.
And the controversy you are referring to, regarding unusual (to put it mildly) design choices in their E2E protocol is indeed very concerning, but the fact that Telegram by default is not end-to-end encrypted and stores all chat history server-side in a way that is accessible to its operators is undisputed.
> “Innocent until proven guilty” is for criminal systems, not security analysis.
Sorry if this sounds ignorant; I'm not a cryptanalyst/security researcher. Isn't this kind of the norm in the industry?
A few examples come to mind like hashing algorithms or encryption methods becoming obsolete over the years.
Was that due to the innocent-until-guilty mindset, or because computational power just overtook those standards?
It's a bit of a mix of both!
At the low level, we unfortunately can't do much more than hope that certain fundamental mathematical/computational complexity assumptions hold. For RSA, that's the assumption that factoring prime numbers is hard; for AES, it's the assumption that it's really hard to invert the pseudorandom permutation a given AES key and the algorithm description represents. We don't have formal proof for these assumptions (or really hopes) being true; some even suspect that these proofs are fundamentally impossible.
In that sense, these really are assumed secure until proven otherwise (by counterexample). And one such counterexample to RSA, Diffie-Hellman and its elliptic curve variants are certain quantum computing algorithms!
However, at the high level, there is the concept of security proofs. These are formal, and in a nutshell they (often) work by mapping a new/unknown problem or solution onto a known one we've already proven some property of.
An example of that would be "if the decisional Diffie-Hellman assumption holds, running protocol x is a secure way of deriving a session key, and a passive observer can't derive the key themselves with non-negligible probability/without improbable resource expenditure" (obviously the actual formalism is much more involved).
In that sense, at the high level, there are positive security proofs, and this is the kind of work that the researchers working on Signal do. It's much harder than clobbering together a few low-level cryptographic primitives and hoping that they'll stick securely, but it's the best approach we have!
Considering too their very sketchy communication about that data collection and the confusion it's caused, I suspect that lie to be a canary warning people away from Signal.
If it isn't, and they're just misleading people about the risks of using their service while also advertising it to vulnerable people like activists and whistleblowers, I guess they failed to live up to my "high standard" of having ethics. In either case, all I can do is recommend that people stay the hell away from Signal.
If you want a Mozilla of secure messaging, try Jitsi or Jami
The photo is part of your profile, which is only available to bidirectional contacts, as far as I know?
And getting visibility into everybody's phonebooks is really hard to avoid in a service like Signal. Yes, theoretically they don't have to automatically scan your entire phone book for Signal membership and could do that just in time when you are about to message somebody (and I believe you can actually use it like that if you just don't grant it phone book access).
But many users do actually like being able to see which of their contacts are reachable on Signal, rather than going by trial-and-error essentially forever, just in case one of their existing contacts did finally sign up in the end. Adoption also matters to keep a project alive.
As far as storing your contact list online goes, you can always opt out of that by not creating a PIN, or alternatively use a high-entropy one, which takes SGX out of the equation entirely if you don't trust it.
And for actual contact sync, Signal has been doing extensive non-SGX research on the topic (and used a bloom filter based solution for Redphone in the past!), and it's apparently just a really hard problem to solve trustlessly in a scalable way [1].
> I suspect that lie to be a canary warning people away from Signal [...] they're just misleading people about the risks of using their service while also advertising it to vulnerable people like activists and whistleblowers, I guess they failed to live up to my "high standard" of having ethics [...]
This is exactly what I mean. From what I can see, Signal sometimes takes non-conservative bets, but ultimately acts in good faith. That's a style not everybody has to agree with, but calling the entire effort harmful is just ridiculous to me.
I'm all in favor of having these discussions, but to some extent, I'm also concerned that when they bleed over into mainstream tech news (usually in a very lossy way thanks to shoddy reporting), it will confuse people even more or drive them towards less secure alternatives such as Telegram.
> If you want a Mozilla of secure messaging, try Jitsi or Jami
These are nice projects, but no. We're talking about a Mozilla-equivalent to Facebook (WhatsApp, Messenger) here, not Zoom (which Jitsi actually does quite nicely)!
Do you have a source for that? That has not been the case previously. Please see this thread: https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
Unless they've changed something recently, if you don't set a pin, one is created for you and all of your data is still uploaded and stored in the cloud. If you do set one, no matter what it's set to, your data is uploaded and forever stored in the cloud.
The confusion surrounding this issue seems intentional (note https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...)
What's harmful is misleading vulnerable users about the risks they take by using Signal. Signal has a responsibility to make it very clear to everyone using their product what data is being uploaded to their servers and stored, and when that takes place. Signal promotes their app to people whose freedom, and lives may be at stake, so it's critical that those people are allowed to evaluate what using Signal could mean for them. They can't do that while Signal outright lies to them and provides misleading answers to direct questions.
> These are nice projects, but no. We're talking about a Mozilla-equivalent to Facebook (WhatsApp, Messenger) here, not Zoom (which Jitsi actually does quite nicely)!
What does facebook messenger do those those apps don't? They support voice and video calls, but also instant messaging, file sharing, screen sharing, group chat, etc
They created a centralized SGX based "cryptocurrency" and some not-publicly-identified person with a phenomenal amount of this entirely premined cryptocurency used the signal integration as a pump to steal a billion dollars from FTX's customers.
This isn't even equivalent to Mozilla integrating something widely used like Bitcoin at all... and Mozilla hasn't done that.
Even if you're utilitarian-consequentialist enough to see enabling/participating in a scam as a justifiable means to fund charitable efforts (like SBF) then you should still see that an encrypted messager with remote update ability really shouldn't be putting itself in a potentially exploitable position. "Ship this backdoor to these targets, or you get prosecuted for your cryptocurrency stunts".
The "Don't Break the Law When You're Breaking The Law" adage doesn't just apply to doing crimes, it also applies when you're doing stuff that powerful entities wished were crimes.
> (Although only in a purely-additive way,
I don't agree. Signal now uploads your contacts and other privacy relevant data to their servers, protected by nothing other than a trivial-to-bruteforce pin and SGX. They used varrious dark patterns to prevent any opt-out from the functionality. Their excuse for the acceptability of protection by trivially weak pins is SGX.
If they were streaming all session keys to the Chinese government protected by ROT13 would we say that it's okay that rot13's dubiousness is okay because its purely additive? No. Signal depends on SGX is a material way, and compromises user confidentiality with it even for users that have no interest in the marginal functionality provided by backing up that data to their servers.
The grandparent poster also missed many other problems with signal. For example, they actively block users from protecting themselves from rogue updates by timebombing every version. They undermined the ability for users to validate identities via other channels by making the comparison fingerprint process functionally pairwise unique (something which originally worked in signal). They've at various times made it extremely difficult to tell when a MITM has replaced your counterparty, e.g. by reencrypting and automatically resending when messages when the key changes (though I'm not sure if they backed off on that) and by noting a key change with a small grey message which the other side can scroll off by sending multiple times.
All that said I think signals weaknesses are kind of moot now in any case, because it no longer acts as an SMS app on android anymore it will likely fade out as more and more people fail to discover that the people they're communicating with have it installed. Signal is dead but it'll take a decade for the body to cool off.
I know several others who operate Signal bots using API clients (in Java, IIRC).
They don't like it, but the ToS doesn't prohibit it.
We would consider it ridiculous if Google updated their ToS to say you must use Chrome to access google.com. I consider HTTP APIs of which I am a legitimate user to be the same; I will use whatever client I wish.
They (the forkers) were stupid to induce brand confusion like that.
Signal is GPL free software; you can fork it and release it with any API URLs you like in the source or binary. It is perfectly legal to fork Signal and remove the user-hostile expiration timer, the image scaling enshittifier that happens on upload, and leave the signal.org API URLs completely unchanged. You just can't call it Signal (or LibreSignal, or BetterSignal, or ExtraSignal, or whatever) when distributing it.
The API ToS is what applies to end users who connect to the API. It says nothing about what software you are allowed to use to do so.
Signal would prefer to pretend that they get to choose what tools their users get to use to consume their service. Unfortunately for them (but good for us), they don't. It's the web and such a restriction would be insane.
Don't confuse software and services. They aren't the same.
https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
Sadly, they do get to choose what is considered "authorised" use of their service :(
I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me. [0]
I push back when anyone recommends Signal because it is fundamentally not an open network.
Both absolutly do hamper fast evolution of a product because they require a LOT of coordination and consensus, both of which are incredibly expensive and time consuming.
With a non-federated and unstable protocol, they are free to update and deprecated whatever they like and on a fast timescale. That is impossible with a federated stable protocol.
This has nothing to do with FOSS.
XMPP is a good example of a protocol that got fragmented to death by many many different and incompatible extensions, ultimately making it too fragmented and too slow to adopt to new requirements.
Third party clients really should be fully allowed too (even though they're not actually being banned so technically they're being condoned)
The reality is that most of Signal's popularity stems from them using phone numbers for initial authentication. Obviously there are people who can work without phone number, but the general population cannot. Or perhaps more correctly, will not. They'll just continue using a system that does.
I think you're wrong in multiple ways. First, you are asserting a false dichotomy. Using phone numbers as one option for authentication in absolutely no way requires using them exclusively. To take a fairly large scale example, Apple's iMessage does not require any phone number. People can transparently use it with their phone numbers easily, but it will also work fine and always has with any email-based Apple ID. No telephone is required at all.
Second and more foundationally, we can objectively observe given the popularity of a range of online accounts using email or just user names (Facebook, Google, etc) that the general population is perfectly capable of working without a phone number. The UX might require more effort, and onboarding in some countries might be easier of course with phone numbers.
Session actually already does. It's just not exposed to the user because the OPTF foots the bill for it. But theoretically if the OPFT was to completely fold and Oxen & Session were to keep chugging along, you'd need to pay some minuscule per message fee for the service you are getting from the network.
The OPTF intends on footing the bill for basic messaging as long as they continue to exist but they probably will need to add some degree of user facing fees for video chat, etc in the long run if it ever seriously takes off.
what do you mean by that?
Why wouldn't signal market a crypto property that is especially important in the context of a messenger app?
OTOH it's also probably read by most as meaningless hyperbole, so the actual damage from being misleading is probably minimal.