TBH this was my reason not to use Signal at all... same with WhatsApp super annoying linking between mobile and desktop :/
Why can't we use XMPP where you can have multiple device and accounts without required mobile phone? Oh I know - because dumb walled gardens and BigTech not liking it... it's a mirracle we got away with e-mail before they came to power :/
Doing end-to-end cryptography is hard enough to get right. Adding multiple devices to the mix makes it even harder.
So it's an explicit trade-off, made to keep your communication safer. Signal, in general, is uncompromising about privacy and about keeping metadata out of their hands.
YMMV and it's always down to threat model... absurd ammount of information is sent via plain text email
in case of XMPP you have OMEMO which is multi device and works fine-ish (nowadays) though I would still prefer simpler OX (PGP; pefrect-forward-secrecy is an overkill IMHO for majority of people)
If you think a device with storage mechanism that can simply connect to another computer and view all your keys is safe enough for your communication needs, then it is fine, you don't need to use Signal.
People use Signal because they don't want to be compromised when they just leave their phone / laptop unattended for a couple minutes on a bus or a train. They don't want to be in a situation if one day their laptop gets computer virus and they have to assume all these accounts are compromised and have to restart their digital identity all over again.
Account is compromised as long as it could be accessible to someone for reading, and potentially impersonation. Possibility to revoke access doesn't mean 'uncompromisable', it means 'easier mitigatable'. The real barrier here is practical restriction of access, and OS-level data encryption, and it works equally well (or equally bad) for any software, whether it's XMPP-based or it's Signal.
Unfortunately linked accounts don't count as primary devices so you will always have to keep the original device active or else they'll eventually delete your account.
Yes but that's different than linking a device. Moving it to a new device deactivates the old one. You can only have one primary device and you must log in with it every so often or else your account gets deleted.
I have the opposite use case where I need to have two Signal accounts on a single phone. Having Molly alongside the official Signal app was always the solution, but I wish Signal would allow switching between profiles, or Android would allow arbitrary user accounts (I don't really want to add Signal to my work profile).
Which is a massive pain to use for stuff like this, and it explicitly recommends against using it with apps that use notifications when you enable it. It shuts down constantly, like as soon as your phone locks (at least for me), and won't process push notifications until the space is opened again.
I really don't get why they don't just give you a thing to install something as many times as you want. It's insane that you still have to use these weird workarounds.
I've used work profiles too. Together, that gives you a total of three installs of an app, all with strange (and different) interactions and limitations between them. All of which is quite different than you'd expect for a "let me have two of this app" feature (because it isn't one, though it's frequently propped up like it is).
Again, you're confirming that you don't understand the features. First you complain about Private Spaces locking, and now you're legitimately complaining about having to install an app twice? A) you don't and B) the segmentation is the entire point.
Android work profiles allow you to run multiple isolated copies in parallel - with separate address book and all. Works very well for Signal. I wish there was something similar for iOS.
Someone in that thread notes that when you install the Signal APK from here [1] it "doesn’t get updates tho", but this isn't the case. Signal will update itself; you get a notification to update. Often earlier than the Play Store, probably due to its reputation to randomly delay updates.
Yes, it notifies of updates (once it did wake me up in the middle of the night), but last time I checked, it does not update itself automatically. Obtanium works, though, but a bigger issue is the extreme power drainage of the websocket.
Signal sends you a notification that says "new version available, tap here to update", but tapping it never did anything for me. I have to re-download the apk their website every time there is an update.
Yeah. Installed Signal as raw apk in GrapheneOS and you just need to open it to install the update. It does not update automatically in background. But anyway, works.
If anyone is interested, I run my own minimalist fork of Molly named Polly.
I just released a stopgap with the fixes:
- RingRTC 2.73.0-1, which includes the call-teardown fix (the hangup/hot-mic issue)
- Signal's blacklist of the eight compromised eMudhra TLS intermediates
It's still based on Signal 8.19.2. The build is arm64-only and Android 14+.
Plug: I also maintain my own UnifiedPush distributor app that optionally pairs with a notification gateway: https://git.lonecloud.dev/lone-cloud/prism-android
My motivation for Prism was to get Proton Mail email notifications delivered via UP, which requires a self-hosted Prism server.
Sometimes I get the feeling that Signal hates users who aren't total normies. Unified Push, which works flawlessly on Molly, could easily be implemented in the regular client. Just as they could easily offer a Google free version for F-Droid or simply for people who want nothing to do with Google. But they just refuse. Just like it took years for nicknames to be introduced, and registering without a phone number has only recently become possible and only through the Google Play Store.
Using the preinstalled Google services effectively turns your smartphone into spyware. In the standard Android that comes preinstalled on most smartphones, Google services run with system privileges and can collect all kinds of data including location data. If Signal exclusively supports this, it reinforces dependence on Google and discourages people from using versions of Android that don’t include Google’s spyware.
The whole point is that it's unusable without Google services due to battery drain. Meta got it right with WhatsApp and a battery-efficient WebSockets implementation for notifications without Google services, but Signal's implementation is poor.
This is an exaggerated take. I've been running Signal on LineageOS for years across at least 5 different phones in exactly this manner with no Google services installed. I'm currently using a Motorola G84 and charge every 2 days with moderate usage; Signal is my primary communication method with family.
The G84 has a very good battery by default though, judging from its predecessor. It can take some additional strain. Something weaker will suffer more.
I have run Signal on LineageOS or GrapheneOS for nearly a decade, no Google services, and I have always had satisfactory battery life, i.e. ~2 days of normal use.
I bought a PinePhone, so I definitely know what truly unoptimized battery life looks like, lol.
It's a moot point, as Signal isn't going to support self-hosted notification servers any more than it'll support self-hosted communication servers.
Signal works without GMS or any alternative, at the cost of more phone wakeups. This is much more preferable to everyone whose WiFi or data service you use see you connect to "push.myownname.com", or for you to rely in some rando gatekeeping your message delivery.
But not providing one does seem to follow with their "be a normie as much as possible in order to not stand out" mantra, even if (to me) providing that extra service for non-GMS users seems harmless. Maybe it's not, I don't know.
Anyway, however much more battery it uses, from my experience, it hasn't been an inconvenience, the phone still lasts a couple of days without charging.
There is no reasonable reason why they shouldn't support it. Having my cell phone battery drain faster is a much bigger drawback for me than simply hosting my own push server at home.
I'm not sure if the comment above you is correct, but if it is (meaning Signal would benefit from the anonymity of every client being the same/similar, like TOR), then this would go against that.
That being said, I've never heard this mentioned as a benefit of Signal, and I figured the main benefit was y'know robust and proven E2E encryption.
This argument doesn't make sense, Signal is fundamentally not an anonymity tool. It's a privacy tool.
They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.
"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.
One of the goals of Signal is that they do not know who is talking to whom. Sealed sender and all that. This can possibly break down in certain scenarios with some server-side correlation. But they certainly do have a design goal that the social graph is entirely private.
I am aware of sealed sender, I even mentioned it in my comment. ;)
My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.
To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.
Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.
Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.
Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.
In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)
Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)
> When you say "Each group of users can have their own servers" you aren't enhancing privacy you are standing out.
You're also hedging against mandated government backdoors.
A single organisation like signal can easily compelled to add a backdoor (or leave the territory) like the EU is trying to do. Going after thousands of servers individually is a whole different problem.
>You're also hedging against mandated government backdoors.
Let's see the law that allows compelling backdoor into Signal then. AFAIK https://en.wikipedia.org/wiki/Bernstein_v._United_States established code as speech, meaning compelling backdoor is compelled speech, which goes against the first.
There just is a contention between software freedom and privacy that people don't want to acknowledge sometimes. Signal is firmly on one side of the divide, and their software is open source because it is the convention to have the source public and auditable, not because they are interested in user freedom and respect.
It's not that they're not interested in user freedom and respect. They just have different ideas about what's important. If Signal federates, that will bring to the table all sorts of 3rd party clients who will have say in how Signal does things, yet no duty to comply with the Signal's spec sheet and deploy timely protocol updates and features. Any clients not keeping up are damaging the brand, as was in the case of Matrix clients' poor support for E2EE. Then there's the aspect that the larger the organization managing the spec becomes, the easier it is to infiltrate and clog with bikeshedding.
Signal's strength is its security agility and thoughtful feature design, not federation and availability.
But that is my point, there is a contention and they made their call. It is not wrong for them to do so, there are just plenty of people who prefer the other side.
Signal isn't anonymous. The server has access to your IP addresses and the server can at will build social graphs about the users.
Where Signal's safety in numbers happens is in normalization of end-to-end encryption. Users who want to protect their message content are not standing out from the rest, unlike in e.g. Telegram where the vendor sees with whom you enable secret chats.
Discovery is important and a hard problem, worth making some trade-offs for. Signal published a good blog post about this, including this passage:
> In order to turn the address book on a device into a social graph for Signal, the Signal client needs to be able to determine which of the device’s contacts are Signal users. [...] The obvious problem with this method is that the hash of a user identifier can almost always be inverted. [...] This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function.
When they say "social graph for Signal", afaik they don't mean 'on Signal servers' but 'social graph on your phone'. It's a personal social graph that exists on the end-user device.
I don't remember how the hash issue is dealt with, however.
> Signal is not peer-to-peer. It is a centralized, client-server architecture.
It's not a P2P mesh, but Signal's servers are involved only for certain functions. I think communication tx is P2P - to send a message via server (used to hide sender IP address from onlookers and the recipient), you need to enable relaying. Possibly finding the recipient still relies on the server - if I want to send a P2P message to Abel, to what IP address do I send it?
The official signal.org blog post I linked does actually explain how it works. They write that the client sends parts of hashed phone numbers to Signal:
> The client transmits those truncated hashes to the service. The service does a lookup from a set of hashed registered users. The service returns the intersection of registered users. The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.
Also: Signal messages are currently never P2P. They always pass through Signal servers, which see (but apparently not retain) your IP and timing metadata. The Signal WebRTC calls are partially peer-to-peer, that is what the relaying in the Signal settings panel is about.
>I think most messages are P2P unless the user activates relaying?
No they're all routed through the servers. It's only the calls that can be sent P2P and you have to opt in for that. The issue is that leaks your IP address to the contact who may not be trustworthy, so it's not used by default.
(Not to object the degoogeling, but:) To create a Signal account, you have to validate a phone number. So Signal is currently largly about privacy, not anonymity.
FWIW I wouldn't know why to message someone if I didn't know who they were. The same goes for them not knowing who I am. What would we even talk about?
The service operated by the incorporated 501c3 has full visibility into who else a user messages and when. This is not good for privacy.
What the non-low-value users are generally looking for is the option to not opt-in to discard anonymity with any potentially involved third parties such as server operators and network operators, and left at the discretion of the users solely.
Other systems have already solved this. One user can be not anonymous while another can choose to not opt-in to not be anonymous.
The users still know who the user on the other side is.
They could still implement these things in the app and put them behind a switch for users who care about independence more than one specific type of anonymity. Explain the tradeoffs on the settings screen.
The only valid reason to be against an optional feature is the maintenance burden, I don't think it's too much here but I also can't speak for the Signal team.
No it's the other way around. Signal is explicitly designed for normies, which is why so many people use it. I doubt they sat around and thought of ways to screw certain users.
>Just as they could easily offer a Google free version
Easily? There's no easy in maintaining and releasing two different versions of your app, especially for a small non-profit.
Hates users who are not total normies and designed explicitly for normies are not opposite. In fact an app that hates not normies would be designed for explicitly for normies.
> Easily? There's no easy in maintaining and releasing two different versions of your app, especially for a small non-profit.
It's literally just another job on your CI. They got a 50 million seed donation in 2017 and reported almost 30 million in revenue in 2024. They are not exactly small. If they were VC founded and not a non profit they would be a unicorn.
You're misreading. In 2024 they had $415k of revenue against $1.4 million in expenses, with $28.7M in assets (which I assume is what you're confusing). Assets have been steadily declining since 2022 as expenses have been consistently higher than revenue.
> They got a 50 million seed donation in 2017 and reported almost 30 million in revenue in 2024. They are not exactly small. If they were VC founded and not a non profit they would be a unicorn.
The donation to Signal and VC investment are very different things: Donations to Signal are for operating costs. VCs invest for the purpose of enabling and owning a share of exponential growth to 'unicorn' status.
> unicorn
Unicorns are billion dollar companies that are rapidly growing. Signal isn't close to that.
One of the most frustrating decisions from them was to stop allowing signal to be a catch-all messenger for encrypted and non-encrypted messages. I was able to onboard so many people, including very non techy relatives, because switching to a secure app for a small subset of people was never something they really wanted to do.
For security and privacy to really win out and raise the bar, it has to be able to happen in the background without the user even realizing it.
Making an app for enthusiasts is fine but Signal is going to remain niche if they can't make it more of an open ecosystem.
Yeah this resulted in a mass exodus of my contacts from Signal. The worst part is some of them never deactivated their Signal accounts, they simply uninstalled it from their devices. For a good while, I was sending messages to the void because Signal thought they were still active users.
I only have 2 people in my contacts that use it now. Every now and then somebody will install it for a couple weeks and ditch it again.
Yeah, the hostility toward F-Droid and wanting to run their app on LineageOS without gapps made me ditch Signal years ago. It seemed like the main gimmick back then was that it was also your SMS app, which IIRC isn't a choice anymore. So what's the draw now? Why would you not use XMPP+OMEMO or Matrix which work everywhere, don't need a phone number (at all, ever), and have free as in freedom clients and servers? It's insane to me.
To put it simply, I need a messenger app to talk to other people. Most people I talk to are not programmers or very tech savvy.
Putting them on Signal requires me to convince them to download an app from the play store, with thr same name. The app is very similar to messenger or whatsapp and they're used to the functionality already. So many of my friends made an account so we can talk.
Anything more involved and they stay on meta's garden. Any successful messaging app needs to prioritize "normies" to get users.
Before the smartphone era, non-tech-savvy young people were still pretty tech-savvy compared to modern computer (= phone) users, who rarely step outside a few corporate phone apps and have even lost the concept of the file and the directory. You can't expect the same curiosity and willingness to make an effort from normies today as back in the XMPP era.
Well I bet you didn't have to convince them to leave messenger back then.
It's not that they are not capable of figuring out something more complex. It's that it's hard to convince non-tech savvy friends to switch apps and it becomes much harder if the alternative needs setup or feels unfamiliar .
You can both appreciate Signal overall and be critical of some aspects.
What the user criticizes is due to sheer choices, which affect some users a lot; for example, numberless registration and full cloud backups can only be purchased with a Google or an Apple account, which clashes a bit with the privacy objectives.
And it's not a problem of not having the infrastructure to support other payment methods, since the donations support all the common ones, and there's now even a cryptocurrency integrated in the platform.
Disallowing and ostracizing other clients is a choice, they spent effort to enforce it (for example by adding mechanisms to recognize the official clients).
Hear hear. It’s been my observation that HN in particular has become much more combative. It’s full on like the meme where someone says “I like strawberries” and someone else complains “oh, so you hate pineapples?! They’re a fruit too, you know?! My great-grandfather ate pineapples. You’re a monster”¹. Yeah, chill, no one said anything about pineapples, stop assuming things or thinking everyone is against you. Don’t succumb to the tribalism.
¹ Unfortunately, I feel I must point out that I’m (I hope obviously) exaggerating for comedic effect.
What really disturbs me as I’m watching myself engage it more frequently. I’ve left other sites because I didn’t like the side of me that came out. Feeling a little bit like that these days here.
2 years ago when I got a new phone, I had to re-register in both WhatsApp and Signal.
Both send you a code over SMS. I hate giving apps SMS access, so I refuse SMS intercept permission when an app asks for it, and instead I manually enter the received code in the app.
This was possible in WhatsApp, but was not possible in Signal. It won't allow you. You must give it SMS access to read the code. So much for privacy/security/... Only app I use which didn't allow me to manually enter the SMS code.
I understand you’re being a bit overdramatic to make a point, but no, Signal and Facebook messenger are not the same levels of secure for the user. That’s not the same as “trust them wholly,” but surely you understand they are on very different ends of the spectrum.
I’m pretty sure it’s for security reasons, it allows the app to ensure the code comes from a correct Signal phone number and not from a third party actor. It’s hand holding yes but it’s a trade off in favor of non-technical users.
Signal hates anyone who even thinks about using this IM app as the de-facto IM app, or with more than that one person who also tries Singal as an annual ritual in your friend circle. I tried to use the app again after a year or so. Gave it full contact permission and it wasn't able to pick friends who are alreasy on Signal. I was not even able to send them messages using the number. But a friend was able to send it a message to me. After 2-3 days finally the app started showing friend's name that's in contact. Tut there were scary warnings (I know, I know that's for my safery). The whole UX just feels at odd with anything and everything I've used. They manage to look and feel worse than WhatsApp of today and that I'd say is an achievement.
Signal is not good for normies: compare sending a message with Signal to WhatsApp. Didn’t go through? WhatsApp will try try try to resend. Signal tries far less then shows the dreaded red exclamation point. Not great while travelling or with poor reception.
Signal developer here: we should retry with reasonable backoff for 24 hours before showing a delivery failure. If that's not your experience, please file a bug if you get the time!
Thank you for all you do. All of my grandparents joined Signal to message me and they have no issues for the most part. Although, one of them didn't know to press the download icon on photos I sent. I'm not sure why they weren't downloaded automatically.
Also please accept cryptocurrency for buying username-based accounts. The overlap between people that want to buy an account and those that want to use a fully identified payment method is not a lot.
I spend about half of every year traveling the mountains and deserts of the world, often ones with poor infrastructure. I use Signal more than any other messenger app, and I have never had the deliverability issues you complain about; messages do all get through eventually.
> Sometimes I get the feeling that Signal hates users
one would think this is a well known fact already after the PIN nag screen forcing users to use PIN or have half of the screen blocked (at that time we left with family and never returned back) or removal of SMS feature, which would be only reason why to keep Signal in the phone for those few people who use it since you could use it at least to receive SMS
TBH Firefox devs are not much better, I remember waiting years and years for pull down to refresh while they kept playing with features nobody asked for (on related note Vivaldi for Android supports already extensions) or Proton Mail devs requiring Android 10 minimum to install the app, while all other clients (Nine Mail, Gmail, etc) are fine with older Android (I mention it because I was setting up old extremely locked phone for my kid recently, I have A16)
Interestingly here, the sqlite DB would be trivially fixable, and messages restorable, with the `sqlite3` CLI.
But there's no way to get at that sqlite DB file. Even if you change Signal's code to add a feature to export the DB, it apparently cannot see your DB, because iOS sandboxes that so that it is only visible to Signal builds signed with the Signal developers' keys.
So that means your messages are all there, on your device, running open-source software, and yet you cannot get them.
This cannot have been the intention of Signal being Free Software. Where is "change it to make it do what you wish (freedom 1)"?
(I do not use iOS myself but have friends suffering this issue. Everybody involved is programmers and yet we seem to be able to do nothing about it.)
So it seems that even though the messages are on the user's device, it really is the Signal developers who "own" that data, and have the exclusive and ultimate control over it.
Makes me wonder:
Does this mean users suffering this need to GDPR-request their data out from Signal?
> Even if you change Signal's code to add a feature to export the DB, it apparently cannot see your DB, because iOS sandboxes that so that it is only visible to Signal builds signed with the Signal developers' keys.
This is not something exclusive to iOS; Android does the same thing.
I'm not sure about Signal, but I had a similar issue with another app, a SQLite db inaccessible. I found that you could take a computer-based full backup and then there are various 3rd party tools that will poke through that backup for whatever "hidden" app data you need. One I previously used is iMazing, but I'm sure there are free open source ones as well.
Something doesn't connect here. I have a workout tracker app I use, and while I can't access the sandbox from the outside, the app has a feature to import/export workout history and it lets me dump a sqlite db copy via iOS share sheets just fine.
To be sure this would mean Apple has to allow for 3p installs that have self signing keys that can let one gain visibility into the data of the app(in this case its in the sandboxes), yeah?
An owner of a device in physical possession of it and with the knowledge of all keys and passwords involved, they should be able to get all their personal data stored on it out of it, yes I think so, no matter who signs what on whatever app store.
The whole point of signal is that they cannot provide you with your data - they do not store it.
Further, I have been frustrated with similar design decisions with Signal - but how can they ensure you can export your messages without allowing letter agencies to do the same? Falling back on platform security guarantees is a rather good choice in terms of the economics - Signal need not gatekeep access to their private data - it is android and iOS that do the heavy lifting there. I’d love to move my messages between devices and sims - but I understand why that is not feasible for now.
I've used F-Droid for years. It's simple, has good apps that aren't full of ads, just works. PGP... sucks a lot, I never really got along with it. Maybe an age thing, but hardly anyone I've met uses PGP/GPG. Yet I have many friends/family on Matrix.
I also would like it to have stable supported libraries. But this doesn't seem to be a focus. It's a pitty, we have a Foss solution and it's hard to integrate with it....
As I understand it, Signal falls back to a persistent websocket when Play services are not available. FWIW.
I agree that working around a reliance on FCM by default would be a position that better aligns with the expectations from the freedom & privacy set, though.
It explains perfectly why Signal does not want third-party clients.
To the haters: I am not saying that it is perfect, in an ideal world we could have secure third-party clients. I am just saying that it is pragmatic: in our world, we don't.
Signal has forever been a pragmatic approach to private messaging, and it succeeded at that: Signal literally put E2EE on the map!
Signal has a threat model, and they do the best app they can addressing that threat model. Which means that they cannot accept third-party clients or federation. They don't say "you cannot use XMPP or SimpleX or Matrix on the side", they just say "we provide this, if you benefit from it, use it for free".
Still, there is a very vocal minority that takes every opportunity they take to explain how "insane" that is, and how they "cannot imagine how anyone with some kind of intelligence wouldn't be revolted". I believe it is the same posture as those complaining about Android or GrapheneOS not giving root access ("even in the advanced settings"). The fact is that if you want root access on your phone, you should install a system that gives you root access, and not select a system that does not and then complain.
Signal is great at what it does. It's okay to also want something else while acknowledging that Signal is great at what it does.
Under Signal's original leadership, there was definitely a hard stance against third party clients connecting to the network. I think they've been quiet on third party clients since Moxie left.
They can give you the right to reuse their source code for building your own service using your own network (an aspire to give you this right), but still forbid you to connect to their service on their network with third party clients.
In practice, they don't seem to enforce that a lot (anymore).
It doesn't necessarily go to court. In the past, there was a project that was a light fork of Signal, LibreSignal, that was Signal but without the google libraries. They have asked the developers to stop distributing a version of it that connected to their network, and the developers stopped the distribution.
I guess they didn't do so for Molly. I suppose a lot of water has passed under the bridge.
You can totally fork their projects! You just can't call yours "Signal" (trademark I guess?) and you can't connect to their servers. Molly seems to be tolerated, somehow? Maybe because it is niche.
But clearly connecting to the Signal servers with an outdated, modified fork is against Signal's goal.
I have my own third-party client called Corvus. However, it's only for the desktop, and uses a native Qt GUI. I haven't gotten the impression that Signal is doing anything to block third-party clients per se. https://github.com/ada-h00k/Corvus
Sure, it doesn't contradict what I said. The number of Signal users connecting through Corvus is probably a rounding error for Signal, it's not worth doing anything against it.
Signal is a non-profit. They won't shut you down because they want to make profit. They may shut you down if they think you lower the quality of their service. I'm pretty sure that with Corvus you're not on their radar because probably almost nobody is using Corvus, right? Or do you have tens of thousands of users?
Right now, it's probably only being used by a small number of people in the lower double digits. However, it's based on signal-cli, which a lot of people use and which Signal apparently has no objection to.
I have been a signal user from very early on, converted most of my family and quite a few friends. I did use Molly to register my second phone (just found I can do that with signal now, so uninstalled Molly and installed signal).I have the impression that the calling experience significantly degraded over the last year, i.e. calls just not ringing at the other end, sometimes even not showing as missed calls, Video calls being very low quality even though both ends are on high quality connections (and switching to other apps yields high quality). Just yesterday I was standing in a queue inside and a friend was outside. We both tried to call each other but the call was just giving ringtone without ringing on the other end. It's become so bad that I'm now considering setting up my own matrix server and transition to that.
Anyone else experiencing the same? I have been wondering if it might have been me using molly, so will test now after going back to signal for second device.
Now should be quite a good time to set up a Matrix server fwiw; we are finally at the tail-end of the journey to Matrix 2.0 (instant sync; auth via OAuth; native multiparty e2ee calling; encryption which operates invisibly). https://matrix.org/blog/2026/10/30/this-week-in-matrix-2026-... gives an overview of where things are at. I'm biased, but by far the easiest and most robust way to run a Matrix stack should be https://github.com/element-hq/ess-helm#ess-community.
As someone that follows This Week In Matrix, is there likely to be a major shuffle in the next few weeks regarding calling configuration for self-hosting? I see that there is work being done, thoug I'm not sure how much that will affect server operators
no, there shouldn't be; MatrixRTC calling has finally (after only 5 years of iteration :) stabilised. The biggest change is renaming the APIs from unstable to stable URL prefixes, but this should be invisible.
Signal only has one recent CVE, one which lets an attacker keep an audio or video stream open after you hang up. It doesn't disclose e.g. your chats with other users.
It's not great. But I prefer it over the risk of downloading an APK from signal's website that I don't know how to properly verify the integrity of (there's a key listed on the website, but who knows if it's correct?). (I don't use Google play)
Network-connected application developers have as a community, desensitized me to this. They are the Boy Who Cried Wolf. Continuous mandatory updates in the name of security. Guilting you into thinking each update is critical due to "security".
I don't care. It's a hassle, and I don't believe the threats they warn of are something to warrant my attention in the landscape of things I should worry about in my life. Anecdotes don't help. To overload with another analogy: Security is a "think of the children" or "full stop": it's a thought-terminating cliche, and I don't believe people who use it.
Signal's rigid anti-fork stance allows it to stay compliant with its 9-figure government contract, which requires it to include a backdoor in final builds that are not reproducible from the official source code.
All these poor, starving users who can't have any freedom unless they compile their own builds don't even have proof that Signal _doesn't do that_. And the worst thing is they probably have no idea there are already free and verifiable alternatives like Delta Chat and SimpleX.
Signal has reproducible builds for Signal Android.
Maybe some of Android users who are naive enough to use Google Play to manage a package like Signal could over time consistently inspect what APK they have and share results.
But reproducible builds for Signal Desktop are "experimental" and "may not work on the public releases yet", which in real terms means Signal Desktop doesn't actually have reproducible builds yet.
Maybe reproducible builds of apps for iOS and macOS will happen some day but the people with the necessary competencies to do reproducible builds are unlikely to believe in others using those systems enough to attempt reproducible builds for them.
Even with reproducible builds, whether packages on iOS can be verified seems to be a grey area at best and with no source code for iOS there is no starting point to believe anything iOS tells us.
SimpleX has been inconsistent with integrity of releases. Some releases have the expected GPG signatures but more do not.
For any release to not have at least one GPG signature on the source tarball is a serious concern.
Evgeny, the head of the SimpleX project, is doing much better with Git commits now than he has in the past. But a cursory look at the Git commit history at the link below shows an RSA4096 key that is over three years old.
What many would like to see from the SimpleX project are a combination of signatures on release source tarballs with RSA, ECC, and PQ keys where at least two of those are on hardware wallets.
I know there are some have urged Evgeny to use hardware wallets for signing source tarball releases and to be forthcoming that he is using a hardware wallet (something built into a Macbook is not sufficient) but there isn't anything on the SimpleX blog showing this.
https://simplex.chat/blog/
_
> users who can't have any freedom unless they compile their own builds
Those who don't have cicd don't have any freedom and have questionable security at best. Whether this is how things should be, I'll let others argue that. It's how it is.
>Signal's rigid anti-fork stance allows it to stay compliant with its 9-figure government contract, which requires it to include a backdoor in final builds that are not reproducible from the official source code.
The incorporated 501c3 named Signal is, in IT terms, a vendor. Is it not?
The Signal client software is open source and some of the clients have reproducible builds. The Signal server software is open source, though has a history of being over a year out of date at some points. Other deployments of this server software for production use are rare.
Suppose you configured an instance of the Signal server software and others you know ran also a somewhat modified Signal client that could access that instance of the Signal server software.
But the centralized namespace of the hosted Signal service hosted by the incorporated 501c3 named Signal would not be accessible through that server instance now would it.
And, as dictated by the incorporated vendor of the centralized namespace, and other reasons, in practice, this client would have to run as a separate piece of software. "Another app".
This is vendor lock-in.
The service hosted by the 501c3 named Signal seems widely open yet is a permissioned namespace. A physical location tracking number aka phone number or a credit/debit card is required to access the namespace. This is for slaves. The profane.
Open Signal on your phone to keep your account active
This vendor is abusive.
And, I don't think this is what Moxie wanted.
Signal 501c3 is a centralized service. XMPP and Matrix are decentralized/federated. SimpleX is distributed.
Moxie as far as I know is still involved in the project and is the source of decisions such as requiring a phone number. My understanding is he is leaning hard on "encryption for anyone and everyone" over all other considerations such as decentralization.
A common criticism is "huh, not very anarchist of him!" Which, maybe? If decisions like that can get Signal into as many hands as possible, and if Signal can continue to operate in such a way as to have basically nothing to offer governments that demand data other than account join date, I think that's an improvement in material conditions.
Your bio has a pretty frank indication of the maximally decentralized, encrypted alternative, and how user hostile that still is:
> If you want to DM, I am generally open to chat. Generate a https://SimpleX.chat invite and paste it into a file simplex-invite.txt, then run the commands below and include pasted contents of DM.txt in one of your comments in any thread we're both participating in.
> Moxie knows about everything I’ve said in this article. He’s a very smart guy and I am under no illusions that he doesn’t understand everything I’ve put forth. I don’t think that Moxie makes these choices because he thinks they’re the right thing to do. [...] Moxie can’t come out and say it openly, but he’s made the decisions he has made because they serve his own interests.
And it looks like it's working. The Signal social network is growing. Revenue is growing (revenue pays for ongoing maintenance). Alternative servers are not sapping user metrics. It's still easy to push both security fixes and eye-catching new features because one central server, and client upgrades are aggressively pushed. Spam is not a plague because registration remains expensive - you need a genuine phone number you control, or Google to vouch for you (who in turn have their own robust defences against account creation).
If it was a free sign up where you just need an IP address to play, spammers would have hundreds of millions of accounts and you'd get as much nuisance friend requests as you get email spam. Most people would leave. You've seen the scraperpocalypse, every sketchy person on the planet has money to fund a million sign ups each from a unique US residential IP (thanks to "smart" TV vendor neglect/corruption allowing residential proxies), IP reputation is worthless.
Personal instances of Signal would hide until spammers found them but you'd better have your own locked down registration because you can't hide forever. Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting, moreso than using Signal's centralised services.
You think, users should be required to carry a cell phone or make use of a debit card or credit card, in order to message another user, is exactly, what Matthew wanted?
A self-described anarchist who described the original cypherpunks as his teenage heroes?
When XMPP+OTR had already been, among competent people, the prevalent norm for over half a decade when he gave that DEF CON 18 talk?
That is just crazy, man.
In that DEF CON 18 talk, Moxie talked about scope of choice and how the scope of choice changed to "do I want to carry a cell phone, or not?". A notion that Matthew's dream was to impose on the world a demand to carry a cell phone or a debit/credit card transaction on others, such a tax, to enjoy what he and his friends and colleagues already on top of pure Internet Protocol, is on its face absurd.
_
> Spam is not a plague because registration remains expensive
The issue of spam is fully mitigated with an invite token, a 16 byte string ; "is", not "can be", because other systems in production have already been doing this.
The way it works is simple. If Alice wants to receive a message from Bob, Alice can share a connection string username+token to Bob. Then Bob can message Alice and for that time not other users of the hosted centralized namespace.
Very simple concept.
Simple enough for a mediocre dev to implement without an LLM.
The spectre of spam does not justify the demand for "checking in" with your local PSTN tower, nor the friction involved with an uninvolved and unwanted third party named Google (love Google overall but this is such a bastardly and disgusting concept), nor does it justify demanding a debit/credit card transaction become involved.
The spectre of spam does not justify any of this horse shit.
"Hey Bob, here is my username to message me, provided you subject yourself to this horse shit", where such horse shit antithetical in a fundamental way to the values espoused founder of Signal.
The new, grossly degenerated Scope of Choice.
Perhaps some who call themselves "hackers" or software developers may have been actually fooled by this false spectre of spam. I was never among them.
Even worse, the phone numbers, Google Play accounts, debit cards and credit cards, these are cheap. Among the scammer underworld these are a plenty and fungible.
An invite token personally sent by Alice or read aloud by Alice to Bob, is not.
But if somebody wants to harass a specific user on Signal, that's relatively cheap to do.
_
> Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting
Uncle Jeff, AWS, who doesn't tell exactly everyone but a lot of people, not excluding ICE at any given time, knows when you are posting, from where, and to what other users. The last of which is specifically obviated by a separate namespace hosted on a separate server.
On the occasions I have run Signal's server software, I and other users did mitigate these concerns. We do appreciate that others also have these means, or not.
Another messaging system, you may have already read its name actually, has already solved these problems in a way that they are successfully mitigated in a wholly transparent way for casual users.
_
> Alternative servers are not sapping user metrics.
This imperative is not the users' problem and runs counter to the best interests of the users.
_
> Its tradeoffs all the way down.
Right. In Matthew's view, the horse shit is a tradeoff.
I believe there are other tradeoffs available that are ethical, not more ethical, but ethical, and carry much less technical complexity.
You should definitely avoid Session. While its decentralized nature is a positive, the developers have implemented many features insecurely and have also removed forward secrecy. There are blog posts by a cryptography expert on this topic: https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
From the page you link (and in which I see nowhere the author designates themself a "cryptography expert", albeit they may be one):
> The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy
I often see this complaint. But it seems to me that, since Session allows users to generate a new private key arbitrarily on the device (and without even associating it with a phone number on a central server) it benefits less from the feature.
> Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.[0]
I'll just say that the main issue with SimpleX is that it lies in its marketing material that it has no identifiers. What they really mean is that they're not adding new identifiers in the app, it doesn't mean they're actively removing existing identifiers, that is, your IP address. The client currently routes messages through two hosting providers which reduces incidental metadata collection. But it does fuck all if the hosting providers collaborate unbeknownst to the users.
That being said, SimpleX has really good support for Tor, in that if you just install tor package to Linux over apt or whatever, and configure like two items in the app's proxy settings, the client will automatically switch to SimpleX Onion Service servers instead of routing to clearnet servers through exit nodes. I can respect that.
What I can't respect is the threat model being treated like a fine print that's buried beneath menus: When you claim to be the most private messenger out there you need to act the part.
The notion that SimpleX has the effect of keeping users anonymous where the SMP servers under the domain simplex.im are used, is a total scam.
A SQL query would defeat the purported anonymity in many cases. An ai model would look at the other cases where IPs of VPNs or Tor are used, uncover much, and yawn.
Now another set of servers are operated by Flux. That helps. But you know how BFFs are with each other, inter-team access to data sinks.
These posts on Reddit and this orange reddit over here by maqp are high quality. They should be read thoroughly.
On the other side of this, the ability to change the receiving server with zero-interaction by remote contacts does lay a cornerstone for effectively anonymizing users. The option to add additional servers used by a SimpleX profile is another cornerstone.
But the mainline user interface hasn't been updated to use these effectively.
What I do like about SimpleX is it is, with a massive asterisk, distributed. SimpleX in practice lives somewhere between decentralized and distributed right now. SimpleX as used by the unwashed masses and disregarding everyone else, is decentralized, or quasi-decentralized.
SimpleX is not confined to a centralized permissioned namespace like Signal 501c3's service which is total vendor lock-in, for fools (yes if you are using that service, you have been had).
SimpleX has shirked the manual processes that XMPP+OMEMO users need to proactively do for a distributed experience.
The audited core Haskell code is hard to argue with. Looking forward to a successor in Lean.
But today, both SimpleX and the better XMPP clients are best enjoyed with community-managed container compose files.
I have read in places apparently originated from more than two minds some zero knowledge approaches that do functionally mitigate any usable identifiers, sans where users are of a small crowd and rarely ever change source IPs, so as much as may ever be practicable with current generations of IP (Reticulum with no source addresses looking better and better). Will be cool to see these implemented.
There may also be a way to do multiple redundant server paths that may be more efficient.
Much waiting to be done, things simply throwing an LLM at won't achieve.
I am convinced by the behavior of some degenerates that one of among those things is not a polished iOS app. iOS is a total cancer. iOS, for which no source code is available outside of Apple and its puppeteers, is for slaves. Voluntarily use of iOS, is an explicit admission cybersecurity-illiteracy.
TIL: The official Signal app can now use one account, shard over two devices.
This was my main reason to use Molly over Signal.
https://aboutsignal.com/news/signal-allows-iphones-to-be-lin...
TBH this was my reason not to use Signal at all... same with WhatsApp super annoying linking between mobile and desktop :/
Why can't we use XMPP where you can have multiple device and accounts without required mobile phone? Oh I know - because dumb walled gardens and BigTech not liking it... it's a mirracle we got away with e-mail before they came to power :/
Doing end-to-end cryptography is hard enough to get right. Adding multiple devices to the mix makes it even harder.
So it's an explicit trade-off, made to keep your communication safer. Signal, in general, is uncompromising about privacy and about keeping metadata out of their hands.
YMMV and it's always down to threat model... absurd ammount of information is sent via plain text email
in case of XMPP you have OMEMO which is multi device and works fine-ish (nowadays) though I would still prefer simpler OX (PGP; pefrect-forward-secrecy is an overkill IMHO for majority of people)
just means more places to get your key stolen from.
Just don't talk so nobody will steal your communications.
You can use matrix and gate everything else into it on your rpi
If you think a device with storage mechanism that can simply connect to another computer and view all your keys is safe enough for your communication needs, then it is fine, you don't need to use Signal.
People use Signal because they don't want to be compromised when they just leave their phone / laptop unattended for a couple minutes on a bus or a train. They don't want to be in a situation if one day their laptop gets computer virus and they have to assume all these accounts are compromised and have to restart their digital identity all over again.
It's mostly to the device security... you can have encrypted storage on laptop just fine... making Signal/mobile like some holly grail is weird.
Besides - it's way more probable to lose train than a computer (even my laptop almost never leaves the house)
In situations you described, everything available on said phone/laptop will be compromised, including Signal, no?
On a laptop, yes. That's why it is not a primary device and you can revoke so it won't have continued access to your messages.
On the phone, no. You need to have a few 0-day to break into Secure Enclave to get access to Signal related keys.
Account is compromised as long as it could be accessible to someone for reading, and potentially impersonation. Possibility to revoke access doesn't mean 'uncompromisable', it means 'easier mitigatable'. The real barrier here is practical restriction of access, and OS-level data encryption, and it works equally well (or equally bad) for any software, whether it's XMPP-based or it's Signal.
You know computers have TPM chips yes?
That article only mentions iPhones, for which Molly was never an option anyway.
But, apparently Android is also supported: https://aboutsignal.com/news/signal-allows-android-phones-to...
So glad they finally added this!
Unfortunately linked accounts don't count as primary devices so you will always have to keep the original device active or else they'll eventually delete your account.
I believe Signal last year started allowing you to backup your primary account and transfer it to a new device?
Yes but that's different than linking a device. Moving it to a new device deactivates the old one. You can only have one primary device and you must log in with it every so often or else your account gets deleted.
Wow, they have not done a good job advertising that when I needed that feature.
I’ve been using Beeper to keep using Signal on my older iPhone when I upgraded.
I have the opposite use case where I need to have two Signal accounts on a single phone. Having Molly alongside the official Signal app was always the solution, but I wish Signal would allow switching between profiles, or Android would allow arbitrary user accounts (I don't really want to add Signal to my work profile).
Android 15+ has Private Space which is basically an additional work profile but managed by the system and not a third party app.
https://support.google.com/android/answer/15341885?hl=en
Which is a massive pain to use for stuff like this, and it explicitly recommends against using it with apps that use notifications when you enable it. It shuts down constantly, like as soon as your phone locks (at least for me), and won't process push notifications until the space is opened again.
I really don't get why they don't just give you a thing to install something as many times as you want. It's insane that you still have to use these weird workarounds.
You can configure the private space to lock when: - Every time device locks (default) - 5 minutes after screen timeout - Only after device restarts
The last option would work just fine for you
Given all the commentary it's very clear you don't understand and have taken zero time to enlighten yourself on Private Spaces.
You do realize you can still create a work profile through things like Insular/Island, right?
It's insane people complain about these things when they're legitimately non-issues
I've used work profiles too. Together, that gives you a total of three installs of an app, all with strange (and different) interactions and limitations between them. All of which is quite different than you'd expect for a "let me have two of this app" feature (because it isn't one, though it's frequently propped up like it is).
Again, you're confirming that you don't understand the features. First you complain about Private Spaces locking, and now you're legitimately complaining about having to install an app twice? A) you don't and B) the segmentation is the entire point.
Android work profiles allow you to run multiple isolated copies in parallel - with separate address book and all. Works very well for Signal. I wish there was something similar for iOS.
There are some tools available to make management even more straightforward, like Insular, a fork of Island: https://f-droid.org/packages/com.oasisfeng.island.fdroid/
Beeper allows multiple accounts from various apps in one chat app FYI
I believe you can use Samsung secure folder to do something like this, I haven’t quite tried it yet though.
They do not support Android tablets as a second device. Molly is the only choice. It is why I stopped my annual contributions to them.
This is not true. Signal added support for linking secondary Android phone or tablet in August
Good to know, thanks. Will check.
That has been my main reason for Molly as well. Good they finally understood that people might be using more than 1 phone.
Or have a tablet. That was my main reason for using Molly.
Seems only for iPhone and seccond iPhone, the article does not mention iPadOS
you’ve been able to link an iPad as a secondary device for years
I deployed my own Matrix server for exactly this reason. Now it's too late. I'm not ever going back to Signal.
Have you managed to transfer from Molly to Signal?
Molly backups stopped working (probably due to lack of updates) and I can't seem to transfer between the two apps on the same device.
Someone in that thread notes that when you install the Signal APK from here [1] it "doesn’t get updates tho", but this isn't the case. Signal will update itself; you get a notification to update. Often earlier than the Play Store, probably due to its reputation to randomly delay updates.
[1] https://signal.org/android/apk/
Yes, it notifies of updates (once it did wake me up in the middle of the night), but last time I checked, it does not update itself automatically. Obtanium works, though, but a bigger issue is the extreme power drainage of the websocket.
Signal sends you a notification that says "new version available, tap here to update", but tapping it never did anything for me. I have to re-download the apk their website every time there is an update.
If using GrapheneOS, you need to give permission to write/install packages.
Yeah. Installed Signal as raw apk in GrapheneOS and you just need to open it to install the update. It does not update automatically in background. But anyway, works.
If anyone is interested, I run my own minimalist fork of Molly named Polly.
I just released a stopgap with the fixes: - RingRTC 2.73.0-1, which includes the call-teardown fix (the hangup/hot-mic issue) - Signal's blacklist of the eight compromised eMudhra TLS intermediates
https://github.com/lone-cloud/polly/releases/tag/v8.19.2-6
It's still based on Signal 8.19.2. The build is arm64-only and Android 14+.
Plug: I also maintain my own UnifiedPush distributor app that optionally pairs with a notification gateway: https://git.lonecloud.dev/lone-cloud/prism-android My motivation for Prism was to get Proton Mail email notifications delivered via UP, which requires a self-hosted Prism server.
[flagged]
Sometimes I get the feeling that Signal hates users who aren't total normies. Unified Push, which works flawlessly on Molly, could easily be implemented in the regular client. Just as they could easily offer a Google free version for F-Droid or simply for people who want nothing to do with Google. But they just refuse. Just like it took years for nicknames to be introduced, and registering without a phone number has only recently become possible and only through the Google Play Store.
Don't Stand Out.
When you say "Each user can choose a different notification service" you aren't enhancing privacy you are standing out.
When you say "Each group of users can have their own servers" you aren't enhancing privacy you are standing out.
So yeah, it's only for "total normies" in the sense that if you insist on standing out from those "total normies" that's a problem.
Signal is taking advantage of the inherent camouflage of crowds, once you insist on standing out that's gone and you can't get it back.
Using the preinstalled Google services effectively turns your smartphone into spyware. In the standard Android that comes preinstalled on most smartphones, Google services run with system privileges and can collect all kinds of data including location data. If Signal exclusively supports this, it reinforces dependence on Google and discourages people from using versions of Android that don’t include Google’s spyware.
Then don't do that?
Install vanilla LineageOS or GrapheneOS with no GApps. Then install Signal from https://signal.org/android/apk/
The whole point is that it's unusable without Google services due to battery drain. Meta got it right with WhatsApp and a battery-efficient WebSockets implementation for notifications without Google services, but Signal's implementation is poor.
This is an exaggerated take. I've been running Signal on LineageOS for years across at least 5 different phones in exactly this manner with no Google services installed. I'm currently using a Motorola G84 and charge every 2 days with moderate usage; Signal is my primary communication method with family.
The G84 has a very good battery by default though, judging from its predecessor. It can take some additional strain. Something weaker will suffer more.
I have run Signal on LineageOS or GrapheneOS for nearly a decade, no Google services, and I have always had satisfactory battery life, i.e. ~2 days of normal use.
I bought a PinePhone, so I definitely know what truly unoptimized battery life looks like, lol.
This was never an issue with my Pixel. Using my pixel with graphene without google play services resulted in better battery life than stock.
Signal on GrapheneOS with no Google anything here, and it works great.
That doesn't address the criticism that this thread started with:
Unified Push, which works flawlessly on Molly, could easily be implemented in the regular client.
It's a moot point, as Signal isn't going to support self-hosted notification servers any more than it'll support self-hosted communication servers.
Signal works without GMS or any alternative, at the cost of more phone wakeups. This is much more preferable to everyone whose WiFi or data service you use see you connect to "push.myownname.com", or for you to rely in some rando gatekeeping your message delivery.
> everyone whose WiFi or data service you use see you connect to "push.myownname.com"
Mozilla has one. Hell, Signal _themselves_ could host a UnifiedPush server. Not an excuse to say 'you use Google or our app uses 10x the battery'.
OK, that's a fair point.
But not providing one does seem to follow with their "be a normie as much as possible in order to not stand out" mantra, even if (to me) providing that extra service for non-GMS users seems harmless. Maybe it's not, I don't know.
Anyway, however much more battery it uses, from my experience, it hasn't been an inconvenience, the phone still lasts a couple of days without charging.
There is no reasonable reason why they shouldn't support it. Having my cell phone battery drain faster is a much bigger drawback for me than simply hosting my own push server at home.
I'm not sure if the comment above you is correct, but if it is (meaning Signal would benefit from the anonymity of every client being the same/similar, like TOR), then this would go against that.
That being said, I've never heard this mentioned as a benefit of Signal, and I figured the main benefit was y'know robust and proven E2E encryption.
This argument doesn't make sense, Signal is fundamentally not an anonymity tool. It's a privacy tool.
They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.
"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.
One of the goals of Signal is that they do not know who is talking to whom. Sealed sender and all that. This can possibly break down in certain scenarios with some server-side correlation. But they certainly do have a design goal that the social graph is entirely private.
I am aware of sealed sender, I even mentioned it in my comment. ;)
My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.
To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.
Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.
Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.
Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.
In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)
Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!
Sure, I guess it's more a question of degree.
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)
> When you say "Each group of users can have their own servers" you aren't enhancing privacy you are standing out.
You're also hedging against mandated government backdoors.
A single organisation like signal can easily compelled to add a backdoor (or leave the territory) like the EU is trying to do. Going after thousands of servers individually is a whole different problem.
>You're also hedging against mandated government backdoors.
Let's see the law that allows compelling backdoor into Signal then. AFAIK https://en.wikipedia.org/wiki/Bernstein_v._United_States established code as speech, meaning compelling backdoor is compelled speech, which goes against the first.
https://en.wikipedia.org/wiki/Code_as_speech goes into this in more detail and mentions https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d... where the defense was used.
GP already mentioned the EU as an example.
Yes or Canada
And also, do we really trust the US government on this after Snowden?
The rule of law is over.
The reverse is true, if more app support unified push then those using it will stand out less.
There just is a contention between software freedom and privacy that people don't want to acknowledge sometimes. Signal is firmly on one side of the divide, and their software is open source because it is the convention to have the source public and auditable, not because they are interested in user freedom and respect.
It's not that they're not interested in user freedom and respect. They just have different ideas about what's important. If Signal federates, that will bring to the table all sorts of 3rd party clients who will have say in how Signal does things, yet no duty to comply with the Signal's spec sheet and deploy timely protocol updates and features. Any clients not keeping up are damaging the brand, as was in the case of Matrix clients' poor support for E2EE. Then there's the aspect that the larger the organization managing the spec becomes, the easier it is to infiltrate and clog with bikeshedding.
Signal's strength is its security agility and thoughtful feature design, not federation and availability.
But that is my point, there is a contention and they made their call. It is not wrong for them to do so, there are just plenty of people who prefer the other side.
Stand out from what? Are you seriously arguing that the only things keeping Signal from being banned are that it somehow camouflages itself?
Other users. Anonymity only works if you don't paint a unique identification on your mask.
That said, I would like all users to look degoogled.
Signal isn't anonymous. The server has access to your IP addresses and the server can at will build social graphs about the users.
Where Signal's safety in numbers happens is in normalization of end-to-end encryption. Users who want to protect their message content are not standing out from the rest, unlike in e.g. Telegram where the vendor sees with whom you enable secret chats.
> The server has access to your IP addresses and the server can at will build social graphs about the users.
How could it build a social graph? I think most messages are P2P unless the user activates relaying?
Discovery is important and a hard problem, worth making some trade-offs for. Signal published a good blog post about this, including this passage:
> In order to turn the address book on a device into a social graph for Signal, the Signal client needs to be able to determine which of the device’s contacts are Signal users. [...] The obvious problem with this method is that the hash of a user identifier can almost always be inverted. [...] This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function.
Src.: https://signal.org/blog/private-contact-discovery/
edit: Also, Signal is not peer-to-peer. It is a centralized, client-server architecture.
When they say "social graph for Signal", afaik they don't mean 'on Signal servers' but 'social graph on your phone'. It's a personal social graph that exists on the end-user device.
I don't remember how the hash issue is dealt with, however.
> Signal is not peer-to-peer. It is a centralized, client-server architecture.
It's not a P2P mesh, but Signal's servers are involved only for certain functions. I think communication tx is P2P - to send a message via server (used to hide sender IP address from onlookers and the recipient), you need to enable relaying. Possibly finding the recipient still relies on the server - if I want to send a P2P message to Abel, to what IP address do I send it?
The official signal.org blog post I linked does actually explain how it works. They write that the client sends parts of hashed phone numbers to Signal:
> The client transmits those truncated hashes to the service. The service does a lookup from a set of hashed registered users. The service returns the intersection of registered users. The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.
Also: Signal messages are currently never P2P. They always pass through Signal servers, which see (but apparently not retain) your IP and timing metadata. The Signal WebRTC calls are partially peer-to-peer, that is what the relaying in the Signal settings panel is about.
>I think most messages are P2P unless the user activates relaying?
No they're all routed through the servers. It's only the calls that can be sent P2P and you have to opt in for that. The issue is that leaks your IP address to the contact who may not be trustworthy, so it's not used by default.
(Not to object the degoogeling, but:) To create a Signal account, you have to validate a phone number. So Signal is currently largly about privacy, not anonymity.
FWIW I wouldn't know why to message someone if I didn't know who they were. The same goes for them not knowing who I am. What would we even talk about?
The service operated by the incorporated 501c3 has full visibility into who else a user messages and when. This is not good for privacy.
What the non-low-value users are generally looking for is the option to not opt-in to discard anonymity with any potentially involved third parties such as server operators and network operators, and left at the discretion of the users solely.
Other systems have already solved this. One user can be not anonymous while another can choose to not opt-in to not be anonymous.
The users still know who the user on the other side is.
Ahh okay, that makes more sense! Sorry for the snark.
Not sure I follow or understand your argument. There's so many things with which eg Telegram stands out, but it still appeals to normies.
They could still implement these things in the app and put them behind a switch for users who care about independence more than one specific type of anonymity. Explain the tradeoffs on the settings screen.
The only valid reason to be against an optional feature is the maintenance burden, I don't think it's too much here but I also can't speak for the Signal team.
Anyone who has worked with SQL databases and graph databases can't buy this goofy "camouflage" idea.
If you don't know how computers work, yeah it sounds great. But those who do know how computers work see it for what it really is: a bucket of shit.
[dead]
[dead]
>Signal hates users who aren't total normies.
No it's the other way around. Signal is explicitly designed for normies, which is why so many people use it. I doubt they sat around and thought of ways to screw certain users.
>Just as they could easily offer a Google free version
Easily? There's no easy in maintaining and releasing two different versions of your app, especially for a small non-profit.
It's just two compilation profiles, at least thousands of minuscule open source projects do it
Sure, but adding another target still increases maintenance burden. QA, e2e testing, acceptance testing, release engineering, etc.
That said I also wish they had a degoogled version.
It's just about not using some Google library, not that much more testing would be needed, nor maintainance or "release engineering".
I'd take an untested version over nothing, anyhow.
And I'm not sure that the current version undergoes that much testing, bugs are not very rare.
Hates users who are not total normies and designed explicitly for normies are not opposite. In fact an app that hates not normies would be designed for explicitly for normies.
> Easily? There's no easy in maintaining and releasing two different versions of your app, especially for a small non-profit.
It's literally just another job on your CI. They got a 50 million seed donation in 2017 and reported almost 30 million in revenue in 2024. They are not exactly small. If they were VC founded and not a non profit they would be a unicorn.
>reported almost 30 million in revenue in 2024
You're misreading. In 2024 they had $415k of revenue against $1.4 million in expenses, with $28.7M in assets (which I assume is what you're confusing). Assets have been steadily declining since 2022 as expenses have been consistently higher than revenue.
https://projects.propublica.org/nonprofits/organizations/816...
> They got a 50 million seed donation in 2017 and reported almost 30 million in revenue in 2024. They are not exactly small. If they were VC founded and not a non profit they would be a unicorn.
The donation to Signal and VC investment are very different things: Donations to Signal are for operating costs. VCs invest for the purpose of enabling and owning a share of exponential growth to 'unicorn' status.
> unicorn
Unicorns are billion dollar companies that are rapidly growing. Signal isn't close to that.
One of the most frustrating decisions from them was to stop allowing signal to be a catch-all messenger for encrypted and non-encrypted messages. I was able to onboard so many people, including very non techy relatives, because switching to a secure app for a small subset of people was never something they really wanted to do.
For security and privacy to really win out and raise the bar, it has to be able to happen in the background without the user even realizing it.
Making an app for enthusiasts is fine but Signal is going to remain niche if they can't make it more of an open ecosystem.
Yeah this resulted in a mass exodus of my contacts from Signal. The worst part is some of them never deactivated their Signal accounts, they simply uninstalled it from their devices. For a good while, I was sending messages to the void because Signal thought they were still active users.
I only have 2 people in my contacts that use it now. Every now and then somebody will install it for a couple weeks and ditch it again.
Where once it was a messaging app for everybody, now it is a mailbox they forget to check.
Yeah, the hostility toward F-Droid and wanting to run their app on LineageOS without gapps made me ditch Signal years ago. It seemed like the main gimmick back then was that it was also your SMS app, which IIRC isn't a choice anymore. So what's the draw now? Why would you not use XMPP+OMEMO or Matrix which work everywhere, don't need a phone number (at all, ever), and have free as in freedom clients and servers? It's insane to me.
To put it simply, I need a messenger app to talk to other people. Most people I talk to are not programmers or very tech savvy.
Putting them on Signal requires me to convince them to download an app from the play store, with thr same name. The app is very similar to messenger or whatsapp and they're used to the functionality already. So many of my friends made an account so we can talk.
Anything more involved and they stay on meta's garden. Any successful messaging app needs to prioritize "normies" to get users.
This is exactly it. Signal was promoted in my country because it was not big tech.
People hated Facebook but still wanted WhatsApp. Free, no ads, no Silicon Valley. Privacy or anonymity are irrelevant.
Yet another person confusing "allowed" vs "required"
When I was in middle school, all of my friends used XMPP. None of us pre-teens were especially tech savvy.
Before the smartphone era, non-tech-savvy young people were still pretty tech-savvy compared to modern computer (= phone) users, who rarely step outside a few corporate phone apps and have even lost the concept of the file and the directory. You can't expect the same curiosity and willingness to make an effort from normies today as back in the XMPP era.
I feel like all that is true sometimes, then my 9-year-old neice shows me what she's been doing in Minecraft.
Well I bet you didn't have to convince them to leave messenger back then.
It's not that they are not capable of figuring out something more complex. It's that it's hard to convince non-tech savvy friends to switch apps and it becomes much harder if the alternative needs setup or feels unfamiliar .
did we know it was XMPP though?
I want to express a very different perspective here as a counterpoint: I'm really grateful for the Signal team's work.
Today, I discussed my father's health condition with my family. Signal worked smoothly (even for my aging mother!), and it's free and secure.
Over the past five years, I have donated $500 to the foundation in total. I hope they continue to maintain the app into the far future.
Do you support what the above user contests?
It’s a different perspective. Not everything is a direct argument about the exact thing written. No need to be like that.
You can both appreciate Signal overall and be critical of some aspects.
What the user criticizes is due to sheer choices, which affect some users a lot; for example, numberless registration and full cloud backups can only be purchased with a Google or an Apple account, which clashes a bit with the privacy objectives.
And it's not a problem of not having the infrastructure to support other payment methods, since the donations support all the common ones, and there's now even a cryptocurrency integrated in the platform.
Disallowing and ostracizing other clients is a choice, they spent effort to enforce it (for example by adding mechanisms to recognize the official clients).
I’m not disagreeing with any particular points of the argument, I just don’t think the person needed to respond like that.
Alright
Hear hear. It’s been my observation that HN in particular has become much more combative. It’s full on like the meme where someone says “I like strawberries” and someone else complains “oh, so you hate pineapples?! They’re a fruit too, you know?! My great-grandfather ate pineapples. You’re a monster”¹. Yeah, chill, no one said anything about pineapples, stop assuming things or thinking everyone is against you. Don’t succumb to the tribalism.
¹ Unfortunately, I feel I must point out that I’m (I hope obviously) exaggerating for comedic effect.
But we've always been at war with Strawbania.
What really disturbs me as I’m watching myself engage it more frequently. I’ve left other sites because I didn’t like the side of me that came out. Feeling a little bit like that these days here.
I had the same thought today. I had no fights in HN since years of being on here, but there's much more aggression recently.
antistra
2 years ago when I got a new phone, I had to re-register in both WhatsApp and Signal.
Both send you a code over SMS. I hate giving apps SMS access, so I refuse SMS intercept permission when an app asks for it, and instead I manually enter the received code in the app.
This was possible in WhatsApp, but was not possible in Signal. It won't allow you. You must give it SMS access to read the code. So much for privacy/security/... Only app I use which didn't allow me to manually enter the SMS code.
> It won't allow you. You must give it SMS access to read the code
Just tested with latest version of Signal. Can't reproduce. You can just tap away all the prompts, and paste the code.
[dead]
Hate to say it, but if you don’t trust Signal to read your texts… you’ve already lost - stick with Facebook Messenger.
Memes I share with friends on Signal and verification codes from my bank with my life savings require very different levels of trust.
Why would I give any app permission to read my messages, no matter how secure it claims to be?
I understand you’re being a bit overdramatic to make a point, but no, Signal and Facebook messenger are not the same levels of secure for the user. That’s not the same as “trust them wholly,” but surely you understand they are on very different ends of the spectrum.
I’m pretty sure it’s for security reasons, it allows the app to ensure the code comes from a correct Signal phone number and not from a third party actor. It’s hand holding yes but it’s a trade off in favor of non-technical users.
Somehow all the other apps, including bank apps, do not seem to consider this necessary.
Signal always has excuses, "we can't add usernames because we don't know how to make them secure"
Bank apps do checklist-oriented security, and nobody has put that on the checklist yet.
Banks stand to lose actual money if they screw up. They do a bit more than checklists.
My one bank app makes me enable Play Store security. Another one makes me disable developer mode to use NFC payments.
[dead]
[dead]
> it allows the app to ensure the code comes from a correct Signal phone number and not from a third party actor.
But if they sent you the code, even if a third party actor could somehow see it and hand it to you instead -- so what? What's the difference?
Signal hates anyone who even thinks about using this IM app as the de-facto IM app, or with more than that one person who also tries Singal as an annual ritual in your friend circle. I tried to use the app again after a year or so. Gave it full contact permission and it wasn't able to pick friends who are alreasy on Signal. I was not even able to send them messages using the number. But a friend was able to send it a message to me. After 2-3 days finally the app started showing friend's name that's in contact. Tut there were scary warnings (I know, I know that's for my safery). The whole UX just feels at odd with anything and everything I've used. They manage to look and feel worse than WhatsApp of today and that I'd say is an achievement.
Signal is not good for normies: compare sending a message with Signal to WhatsApp. Didn’t go through? WhatsApp will try try try to resend. Signal tries far less then shows the dreaded red exclamation point. Not great while travelling or with poor reception.
Signal developer here: we should retry with reasonable backoff for 24 hours before showing a delivery failure. If that's not your experience, please file a bug if you get the time!
Thank you for all you do. All of my grandparents joined Signal to message me and they have no issues for the most part. Although, one of them didn't know to press the download icon on photos I sent. I'm not sure why they weren't downloaded automatically.
Also please accept cryptocurrency for buying username-based accounts. The overlap between people that want to buy an account and those that want to use a fully identified payment method is not a lot.
I spend about half of every year traveling the mountains and deserts of the world, often ones with poor infrastructure. I use Signal more than any other messenger app, and I have never had the deliverability issues you complain about; messages do all get through eventually.
> Sometimes I get the feeling that Signal hates users
one would think this is a well known fact already after the PIN nag screen forcing users to use PIN or have half of the screen blocked (at that time we left with family and never returned back) or removal of SMS feature, which would be only reason why to keep Signal in the phone for those few people who use it since you could use it at least to receive SMS
TBH Firefox devs are not much better, I remember waiting years and years for pull down to refresh while they kept playing with features nobody asked for (on related note Vivaldi for Android supports already extensions) or Proton Mail devs requiring Android 10 minimum to install the app, while all other clients (Nine Mail, Gmail, etc) are fine with older Android (I mention it because I was setting up old extremely locked phone for my kid recently, I have A16)
Or this case we encountered, where on iOS Signal apparently corrupts its sqlite DB, leading to loss of all messages.
https://github.com/signalapp/Signal-iOS/issues/5813
Interestingly here, the sqlite DB would be trivially fixable, and messages restorable, with the `sqlite3` CLI.
But there's no way to get at that sqlite DB file. Even if you change Signal's code to add a feature to export the DB, it apparently cannot see your DB, because iOS sandboxes that so that it is only visible to Signal builds signed with the Signal developers' keys.
So that means your messages are all there, on your device, running open-source software, and yet you cannot get them.
This cannot have been the intention of Signal being Free Software. Where is "change it to make it do what you wish (freedom 1)"?
(I do not use iOS myself but have friends suffering this issue. Everybody involved is programmers and yet we seem to be able to do nothing about it.)
So it seems that even though the messages are on the user's device, it really is the Signal developers who "own" that data, and have the exclusive and ultimate control over it.
Makes me wonder:
Does this mean users suffering this need to GDPR-request their data out from Signal?
> Even if you change Signal's code to add a feature to export the DB, it apparently cannot see your DB, because iOS sandboxes that so that it is only visible to Signal builds signed with the Signal developers' keys.
This is not something exclusive to iOS; Android does the same thing.
I'm not sure about Signal, but I had a similar issue with another app, a SQLite db inaccessible. I found that you could take a computer-based full backup and then there are various 3rd party tools that will poke through that backup for whatever "hidden" app data you need. One I previously used is iMazing, but I'm sure there are free open source ones as well.
Best of luck!
No. Turn on backups. Write the encryption key somewhere safe.
Copy the backup off your phone and use https://github.com/bepaald/signalbackup-tools to extract everything.
Something doesn't connect here. I have a workout tracker app I use, and while I can't access the sandbox from the outside, the app has a feature to import/export workout history and it lets me dump a sqlite db copy via iOS share sheets just fine.
You're saying the app has the feature to export its sqlite DB?
If yes, that's exactly what the users in the linked bug report are asking Signal to add to be able to fix this problem themselves.
> Interestingly here, the sqlite DB would be trivially fixable, and messages restorable, with the `sqlite3` CLI.
It seems to me like the app itself should be able to perform this operation and restore data? Why is this not just fixed in the app?
Because Signal developers do not spend time on this.
Which is all well; after all nobody is paying them to do it.
My complaint is that they + iOS simultaneously prevent able users from fixing it themselves, or paying somebody to fix it.
Because lost messages are safe. If the user data is gone, it can’t be stolen!
To be sure this would mean Apple has to allow for 3p installs that have self signing keys that can let one gain visibility into the data of the app(in this case its in the sandboxes), yeah?
An owner of a device in physical possession of it and with the knowledge of all keys and passwords involved, they should be able to get all their personal data stored on it out of it, yes I think so, no matter who signs what on whatever app store.
The whole point of signal is that they cannot provide you with your data - they do not store it.
Further, I have been frustrated with similar design decisions with Signal - but how can they ensure you can export your messages without allowing letter agencies to do the same? Falling back on platform security guarantees is a rather good choice in terms of the economics - Signal need not gatekeep access to their private data - it is android and iOS that do the heavy lifting there. I’d love to move my messages between devices and sims - but I understand why that is not feasible for now.
The number of people using F-droid is tiny.
Non-normies can continue to use PGP like they always have.
/s second paragraph.
Yes it's tiny but it's the kind of people that tend to influence others. Not in using F-Droid, but using signal yes. It could help adoption overall.
Having signal on fdroid and having it build reproducibly would make me trust it.
As it stands it's a proprietary app with a lot o marketing to convince me otherwise.
I've used F-Droid for years. It's simple, has good apps that aren't full of ads, just works. PGP... sucks a lot, I never really got along with it. Maybe an age thing, but hardly anyone I've met uses PGP/GPG. Yet I have many friends/family on Matrix.
I also would like it to have stable supported libraries. But this doesn't seem to be a focus. It's a pitty, we have a Foss solution and it's hard to integrate with it....
As I understand it, Signal falls back to a persistent websocket when Play services are not available. FWIW.
I agree that working around a reliance on FCM by default would be a position that better aligns with the expectations from the freedom & privacy set, though.
Signal hates all users. Go away for a standard 4-week EU summer holiday? We deleted all your data and burned your account.
It’s security!
You need to fix your shill propaganda. It's 4 months i.e. 120 days, not 4 weeks, before they delete your account https://github.com/signalapp/Signal-Server/blob/7f5097bd3317...
Your linked devices get unlinked in 30 days, and lose history older than 45 days
https://support.signal.org/hc/en-us/articles/360007320551-Li...
It explains perfectly why Signal does not want third-party clients.
To the haters: I am not saying that it is perfect, in an ideal world we could have secure third-party clients. I am just saying that it is pragmatic: in our world, we don't.
Signal has forever been a pragmatic approach to private messaging, and it succeeded at that: Signal literally put E2EE on the map!
Signal has a threat model, and they do the best app they can addressing that threat model. Which means that they cannot accept third-party clients or federation. They don't say "you cannot use XMPP or SimpleX or Matrix on the side", they just say "we provide this, if you benefit from it, use it for free".
Still, there is a very vocal minority that takes every opportunity they take to explain how "insane" that is, and how they "cannot imagine how anyone with some kind of intelligence wouldn't be revolted". I believe it is the same posture as those complaining about Android or GrapheneOS not giving root access ("even in the advanced settings"). The fact is that if you want root access on your phone, you should install a system that gives you root access, and not select a system that does not and then complain.
Signal is great at what it does. It's okay to also want something else while acknowledging that Signal is great at what it does.
I don’t understand where this energy that signal doesn’t want 3rd party clients is coming from.
Their open source code is permissive of commercial forks.
Like, if their goal was to block third-party clients, then they would look more like Facebook or Reddit
Under Signal's original leadership, there was definitely a hard stance against third party clients connecting to the network. I think they've been quiet on third party clients since Moxie left.
I think they wouldn't want a third-party client to become mainstream. That a few people bridge matrix to signal is not exactly a problem.
Software license ≠ terms of service.
They can give you the right to reuse their source code for building your own service using your own network (an aspire to give you this right), but still forbid you to connect to their service on their network with third party clients.
In practice, they don't seem to enforce that a lot (anymore).
It's unlikely that their ToS would be enforceable in court. The fact that Apple never tried to sue Beeper speaks to this.
It doesn't necessarily go to court. In the past, there was a project that was a light fork of Signal, LibreSignal, that was Signal but without the google libraries. They have asked the developers to stop distributing a version of it that connected to their network, and the developers stopped the distribution.
I guess they didn't do so for Molly. I suppose a lot of water has passed under the bridge.
You can totally fork their projects! You just can't call yours "Signal" (trademark I guess?) and you can't connect to their servers. Molly seems to be tolerated, somehow? Maybe because it is niche.
But clearly connecting to the Signal servers with an outdated, modified fork is against Signal's goal.
I have my own third-party client called Corvus. However, it's only for the desktop, and uses a native Qt GUI. I haven't gotten the impression that Signal is doing anything to block third-party clients per se. https://github.com/ada-h00k/Corvus
Sure, it doesn't contradict what I said. The number of Signal users connecting through Corvus is probably a rounding error for Signal, it's not worth doing anything against it.
Signal is a non-profit. They won't shut you down because they want to make profit. They may shut you down if they think you lower the quality of their service. I'm pretty sure that with Corvus you're not on their radar because probably almost nobody is using Corvus, right? Or do you have tens of thousands of users?
Right now, it's probably only being used by a small number of people in the lower double digits. However, it's based on signal-cli, which a lot of people use and which Signal apparently has no objection to.
I have been a signal user from very early on, converted most of my family and quite a few friends. I did use Molly to register my second phone (just found I can do that with signal now, so uninstalled Molly and installed signal).I have the impression that the calling experience significantly degraded over the last year, i.e. calls just not ringing at the other end, sometimes even not showing as missed calls, Video calls being very low quality even though both ends are on high quality connections (and switching to other apps yields high quality). Just yesterday I was standing in a queue inside and a friend was outside. We both tried to call each other but the call was just giving ringtone without ringing on the other end. It's become so bad that I'm now considering setting up my own matrix server and transition to that.
Anyone else experiencing the same? I have been wondering if it might have been me using molly, so will test now after going back to signal for second device.
Now should be quite a good time to set up a Matrix server fwiw; we are finally at the tail-end of the journey to Matrix 2.0 (instant sync; auth via OAuth; native multiparty e2ee calling; encryption which operates invisibly). https://matrix.org/blog/2026/10/30/this-week-in-matrix-2026-... gives an overview of where things are at. I'm biased, but by far the easiest and most robust way to run a Matrix stack should be https://github.com/element-hq/ess-helm#ess-community.
As someone that follows This Week In Matrix, is there likely to be a major shuffle in the next few weeks regarding calling configuration for self-hosting? I see that there is work being done, thoug I'm not sure how much that will affect server operators
no, there shouldn't be; MatrixRTC calling has finally (after only 5 years of iteration :) stabilised. The biggest change is renaming the APIs from unstable to stable URL prefixes, but this should be invisible.
Well that's timely, and a bummer. I was just wondering about this yesterday, I use signal on my primary phone and Molly on a secondary phone.
Signal got an update yesterday and when I saw the notification I couldn't remember the last time Molly was updated...
Signal only has one recent CVE, one which lets an attacker keep an audio or video stream open after you hang up. It doesn't disclose e.g. your chats with other users.
To be fair, that sounds pretty bad?
It's not great. But I prefer it over the risk of downloading an APK from signal's website that I don't know how to properly verify the integrity of (there's a key listed on the website, but who knows if it's correct?). (I don't use Google play)
https://github.com/privacyguides/verified-apps-android
Network-connected application developers have as a community, desensitized me to this. They are the Boy Who Cried Wolf. Continuous mandatory updates in the name of security. Guilting you into thinking each update is critical due to "security".
I don't care. It's a hassle, and I don't believe the threats they warn of are something to warrant my attention in the landscape of things I should worry about in my life. Anecdotes don't help. To overload with another analogy: Security is a "think of the children" or "full stop": it's a thought-terminating cliche, and I don't believe people who use it.
Pro tip: Signal is vulnerable too.
citation needed. you have an alternative?
[flagged]
[flagged]
[dead]
[flagged]
> *for 3 months - learn to spell
Don't you mean "learn grammar"?
If you're going to be an insulting pedant, at least be correct about it.
Should take only a few minutes to use an LLM to sync to upstream and build a new APK if you have any of the $20 subscriptions
Signal's rigid anti-fork stance allows it to stay compliant with its 9-figure government contract, which requires it to include a backdoor in final builds that are not reproducible from the official source code.
All these poor, starving users who can't have any freedom unless they compile their own builds don't even have proof that Signal _doesn't do that_. And the worst thing is they probably have no idea there are already free and verifiable alternatives like Delta Chat and SimpleX.
Signal has reproducible builds for Signal Android.
Maybe some of Android users who are naive enough to use Google Play to manage a package like Signal could over time consistently inspect what APK they have and share results.
But reproducible builds for Signal Desktop are "experimental" and "may not work on the public releases yet", which in real terms means Signal Desktop doesn't actually have reproducible builds yet.Maybe reproducible builds of apps for iOS and macOS will happen some day but the people with the necessary competencies to do reproducible builds are unlikely to believe in others using those systems enough to attempt reproducible builds for them.
Even with reproducible builds, whether packages on iOS can be verified seems to be a grey area at best and with no source code for iOS there is no starting point to believe anything iOS tells us.
SimpleX has been inconsistent with integrity of releases. Some releases have the expected GPG signatures but more do not.
For any release to not have at least one GPG signature on the source tarball is a serious concern.
Evgeny, the head of the SimpleX project, is doing much better with Git commits now than he has in the past. But a cursory look at the Git commit history at the link below shows an RSA4096 key that is over three years old.
What many would like to see from the SimpleX project are a combination of signatures on release source tarballs with RSA, ECC, and PQ keys where at least two of those are on hardware wallets.I know there are some have urged Evgeny to use hardware wallets for signing source tarball releases and to be forthcoming that he is using a hardware wallet (something built into a Macbook is not sufficient) but there isn't anything on the SimpleX blog showing this.
_> users who can't have any freedom unless they compile their own builds
Those who don't have cicd don't have any freedom and have questionable security at best. Whether this is how things should be, I'll let others argue that. It's how it is.
The Android client has been reproducible for quite some time, instructions right in the repo.
This is a serious claim - do you have any proof you can offer that this is actually the case?
Signal markets themselves as really secure. It's on them to prove that they are.
No reproducible builds from them when they are now very common is really suspicious.
>Signal's rigid anti-fork stance allows it to stay compliant with its 9-figure government contract, which requires it to include a backdoor in final builds that are not reproducible from the official source code.
[citation needed]
The incorporated 501c3 named Signal is, in IT terms, a vendor. Is it not?
The Signal client software is open source and some of the clients have reproducible builds. The Signal server software is open source, though has a history of being over a year out of date at some points. Other deployments of this server software for production use are rare.
Suppose you configured an instance of the Signal server software and others you know ran also a somewhat modified Signal client that could access that instance of the Signal server software.
But the centralized namespace of the hosted Signal service hosted by the incorporated 501c3 named Signal would not be accessible through that server instance now would it.
And, as dictated by the incorporated vendor of the centralized namespace, and other reasons, in practice, this client would have to run as a separate piece of software. "Another app".
This is vendor lock-in.
The service hosted by the 501c3 named Signal seems widely open yet is a permissioned namespace. A physical location tracking number aka phone number or a credit/debit card is required to access the namespace. This is for slaves. The profane.
This vendor is abusive.And, I don't think this is what Moxie wanted.
Signal 501c3 is a centralized service. XMPP and Matrix are decentralized/federated. SimpleX is distributed.
> And, I don't think this is what Moxie wanted.
Moxie as far as I know is still involved in the project and is the source of decisions such as requiring a phone number. My understanding is he is leaning hard on "encryption for anyone and everyone" over all other considerations such as decentralization.
A common criticism is "huh, not very anarchist of him!" Which, maybe? If decisions like that can get Signal into as many hands as possible, and if Signal can continue to operate in such a way as to have basically nothing to offer governments that demand data other than account join date, I think that's an improvement in material conditions.
Your bio has a pretty frank indication of the maximally decentralized, encrypted alternative, and how user hostile that still is:
> If you want to DM, I am generally open to chat. Generate a https://SimpleX.chat invite and paste it into a file simplex-invite.txt, then run the commands below and include pasted contents of DM.txt in one of your comments in any thread we're both participating in.
[dead]
> I don't think this is what Moxie wanted.
I think this is exactly what he wanted, as these were the complaints levelled against the service when he was still in charge.
From 2018: https://drewdevault.com/blog/Signal/
> Moxie knows about everything I’ve said in this article. He’s a very smart guy and I am under no illusions that he doesn’t understand everything I’ve put forth. I don’t think that Moxie makes these choices because he thinks they’re the right thing to do. [...] Moxie can’t come out and say it openly, but he’s made the decisions he has made because they serve his own interests.
And it looks like it's working. The Signal social network is growing. Revenue is growing (revenue pays for ongoing maintenance). Alternative servers are not sapping user metrics. It's still easy to push both security fixes and eye-catching new features because one central server, and client upgrades are aggressively pushed. Spam is not a plague because registration remains expensive - you need a genuine phone number you control, or Google to vouch for you (who in turn have their own robust defences against account creation).
If it was a free sign up where you just need an IP address to play, spammers would have hundreds of millions of accounts and you'd get as much nuisance friend requests as you get email spam. Most people would leave. You've seen the scraperpocalypse, every sketchy person on the planet has money to fund a million sign ups each from a unique US residential IP (thanks to "smart" TV vendor neglect/corruption allowing residential proxies), IP reputation is worthless.
Personal instances of Signal would hide until spammers found them but you'd better have your own locked down registration because you can't hide forever. Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting, moreso than using Signal's centralised services.
Its tradeoffs all the way down.
>> I don't think this is what Moxie wanted.
> I think this is exactly what he wanted
You think, users should be required to carry a cell phone or make use of a debit card or credit card, in order to message another user, is exactly, what Matthew wanted?
A self-described anarchist who described the original cypherpunks as his teenage heroes?
When XMPP+OTR had already been, among competent people, the prevalent norm for over half a decade when he gave that DEF CON 18 talk?
That is just crazy, man.
In that DEF CON 18 talk, Moxie talked about scope of choice and how the scope of choice changed to "do I want to carry a cell phone, or not?". A notion that Matthew's dream was to impose on the world a demand to carry a cell phone or a debit/credit card transaction on others, such a tax, to enjoy what he and his friends and colleagues already on top of pure Internet Protocol, is on its face absurd.
_
> Spam is not a plague because registration remains expensive
The issue of spam is fully mitigated with an invite token, a 16 byte string ; "is", not "can be", because other systems in production have already been doing this.
The way it works is simple. If Alice wants to receive a message from Bob, Alice can share a connection string username+token to Bob. Then Bob can message Alice and for that time not other users of the hosted centralized namespace.
Very simple concept.
Simple enough for a mediocre dev to implement without an LLM.
The spectre of spam does not justify the demand for "checking in" with your local PSTN tower, nor the friction involved with an uninvolved and unwanted third party named Google (love Google overall but this is such a bastardly and disgusting concept), nor does it justify demanding a debit/credit card transaction become involved.
The spectre of spam does not justify any of this horse shit.
"Hey Bob, here is my username to message me, provided you subject yourself to this horse shit", where such horse shit antithetical in a fundamental way to the values espoused founder of Signal.
The new, grossly degenerated Scope of Choice.
Perhaps some who call themselves "hackers" or software developers may have been actually fooled by this false spectre of spam. I was never among them.
Even worse, the phone numbers, Google Play accounts, debit cards and credit cards, these are cheap. Among the scammer underworld these are a plenty and fungible.
An invite token personally sent by Alice or read aloud by Alice to Bob, is not.
But if somebody wants to harass a specific user on Signal, that's relatively cheap to do.
_
> Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting
Uncle Jeff, AWS, who doesn't tell exactly everyone but a lot of people, not excluding ICE at any given time, knows when you are posting, from where, and to what other users. The last of which is specifically obviated by a separate namespace hosted on a separate server.
On the occasions I have run Signal's server software, I and other users did mitigate these concerns. We do appreciate that others also have these means, or not.
Another messaging system, you may have already read its name actually, has already solved these problems in a way that they are successfully mitigated in a wholly transparent way for casual users.
_
> Alternative servers are not sapping user metrics.
This imperative is not the users' problem and runs counter to the best interests of the users.
_
> Its tradeoffs all the way down.
Right. In Matthew's view, the horse shit is a tradeoff.
I believe there are other tradeoffs available that are ethical, not more ethical, but ethical, and carry much less technical complexity.
> Signal 501c3 is a centralized service. XMPP and Matrix are decentralized/federated. SimpleX is distributed.
Session is a decentralized Signal fork that creates the account on the device without associating it with a phone number.
https://getsession.org/
See also maqp2's comment here regarding Simplex:
https://web.archive.org/web/20250302182017/https://reddit.co...
You should definitely avoid Session. While its decentralized nature is a positive, the developers have implemented many features insecurely and have also removed forward secrecy. There are blog posts by a cryptography expert on this topic: https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
From the page you link (and in which I see nowhere the author designates themself a "cryptography expert", albeit they may be one):
> The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy
I often see this complaint. But it seems to me that, since Session allows users to generate a new private key arbitrarily on the device (and without even associating it with a phone number on a central server) it benefits less from the feature.
> Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.[0]
[0] https://en.wikipedia.org/wiki/Forward_secrecy
Oh look it's me.
I'll just say that the main issue with SimpleX is that it lies in its marketing material that it has no identifiers. What they really mean is that they're not adding new identifiers in the app, it doesn't mean they're actively removing existing identifiers, that is, your IP address. The client currently routes messages through two hosting providers which reduces incidental metadata collection. But it does fuck all if the hosting providers collaborate unbeknownst to the users.
That being said, SimpleX has really good support for Tor, in that if you just install tor package to Linux over apt or whatever, and configure like two items in the app's proxy settings, the client will automatically switch to SimpleX Onion Service servers instead of routing to clearnet servers through exit nodes. I can respect that.
What I can't respect is the threat model being treated like a fine print that's buried beneath menus: When you claim to be the most private messenger out there you need to act the part.
The notion that SimpleX has the effect of keeping users anonymous where the SMP servers under the domain simplex.im are used, is a total scam.
A SQL query would defeat the purported anonymity in many cases. An ai model would look at the other cases where IPs of VPNs or Tor are used, uncover much, and yawn.
Now another set of servers are operated by Flux. That helps. But you know how BFFs are with each other, inter-team access to data sinks.
These posts on Reddit and this orange reddit over here by maqp are high quality. They should be read thoroughly.
On the other side of this, the ability to change the receiving server with zero-interaction by remote contacts does lay a cornerstone for effectively anonymizing users. The option to add additional servers used by a SimpleX profile is another cornerstone.
But the mainline user interface hasn't been updated to use these effectively.
What I do like about SimpleX is it is, with a massive asterisk, distributed. SimpleX in practice lives somewhere between decentralized and distributed right now. SimpleX as used by the unwashed masses and disregarding everyone else, is decentralized, or quasi-decentralized.
SimpleX is not confined to a centralized permissioned namespace like Signal 501c3's service which is total vendor lock-in, for fools (yes if you are using that service, you have been had).
SimpleX has shirked the manual processes that XMPP+OMEMO users need to proactively do for a distributed experience.
The audited core Haskell code is hard to argue with. Looking forward to a successor in Lean.
But today, both SimpleX and the better XMPP clients are best enjoyed with community-managed container compose files.
I have read in places apparently originated from more than two minds some zero knowledge approaches that do functionally mitigate any usable identifiers, sans where users are of a small crowd and rarely ever change source IPs, so as much as may ever be practicable with current generations of IP (Reticulum with no source addresses looking better and better). Will be cool to see these implemented.
There may also be a way to do multiple redundant server paths that may be more efficient.
Much waiting to be done, things simply throwing an LLM at won't achieve.
I am convinced by the behavior of some degenerates that one of among those things is not a polished iOS app. iOS is a total cancer. iOS, for which no source code is available outside of Apple and its puppeteers, is for slaves. Voluntarily use of iOS, is an explicit admission cybersecurity-illiteracy.
<insert laughing emoji>
[flagged]