I've used Molly for over a year. Overnight it lost the device registration and will not contact the servers to re-register. The backup feature also does not work which left me dead in the water for several days with no fix. I switched back to signal and had to start a new database. It was a disaster. YMMV
Sounds pretty much like my experience with the official Signal app. It is a mess too and I only use Signal/Molly because I have friends who use it.
But sadly the competitors are as bad, just in different ways. Why has nobody yet managed to build a good IM client? It does not seem like we have come far from what we had back in the Pidgin days.
Signal seems to work alright for me, although I felt the desktop app gets a bit annoying because of too many frequent updates happening to the app, which I believe is based on Electron.
But besides this, there is really a strong need for a web client, just like Telegram or WhatsApp. If only the protocol can be extended in such a way that it allows for integrating into a web app, that would be incredibly great.
I have been particularly impressed with the device migration experience. I have an 18gb db, and even the time my device died I managed to get things over correctly.
Conversations has an issue where the main tool for reading a backup on a computer (ceb2txt (so, say, I can properly and correctly archive a text dump archive of a person I loved who died)), will not work for me. I filed a support request and there's been no movement on it whatsoever and it genuinely seems like nobody gives a shit. Restoring a backup even with all the images and media files in the correct place with the correct filenames will then refuse to show any filenames.
This is par for the course with chat backups, though.
Messenger - Bad - No way to save chat responses of people you have talked to. This means you only ever have one side of a conversation, making it meaningless.
Twitter DMs - Bad - See Messenger.
Jami - Ehhhh - Saves a git local repository of messages. The only problem is message syncing is effing abysmal.
Dino (XMPP) - Bad - Does not allow backing anything up, this is "intentional". Depending on which protocol you use, as soon as you move to another device all the messages you _had_ are retroactively converted to Cannot Decrypt. They're my effing messages!
Discord - Good - Discord History Tracker (tedious to use but slurps everything up into a sqlite3 database that is itself, an official archival format)
WhatsApp - Good - Dumps a text record + files/images/etc. onto the phone's filesystem. This is reasonably easy to archive.
Signal - Mediocre - If you have an old Signal backup from 2018? That you could only transfer off your phone by deleting old messages? lmao you're effed. Load up a version from ten years ago, gradually update it and then maybe, MAYBE you can extract the sqlite3 archive? These days you have a .signalbackup or whatever which is an encrypted archive, and I assume that there's a tool to decrypt it, but uhhhhhh. Last I tried to use it it required way more RAM than I had accessible.
Telegram, which ostensibly claimed to provide e2e but really only did in very specific circumstances? My right wing uncle is still bitter about that. Then there's the rolling over the founder did after getting pulled up by Interpol.
Very few of the protocols supported by Pidgin were encrypted, unless you used the OTR plugin. That makes it a lot easier to support things like chat history.
The deathblow for Signal was that I was in a group and some group messages just got lost for some members completely unnoticed. So you could never be sure if you missed something or someone.
I'm using WhatsApp again, now since years and had never issues, it just works.
The Whisperfish [1] project (a Signal messenger for Sailfish OS) maintains an independent Signal client library written in Rust [2]. It works quite well - unless Signal decides to change their protocols or kick non-standard clients.
hiq's comment was not about Whisperfish but about the presage library.
My comment can be read as "Whisperfish wrote their own implementation of the signal protocol" - which is wrong. (Sorry, can't edit it anymore)
With presage, Whisperfish has a high-level Rust library that wraps the official libsignal libraries (which are also written in Rust) and makes it much easier to write clients. The official Signal repo only contains Java/Typescript/Swift wrappers. As presage is rather obscure, I thought that some HN readers might appreciate the link.
I'll also just add: it's probably not a good idea to use any modifications to an E2EE messenger unless you are comfortable with those privacy/security guarantees possibly being violated by the 3rd party code.
The only exception to this would be if I really trusted the goals of the 3rd party, like Graphene.
As they say in the Github readme, FCM and Google Maps.
FCM doesn't technically require a blob — it's just that Google wants you to think it does. I reverse engineered their library and it turned out to be a criminally over-engineered wrapper around two broadcast receivers. So, the Mastodon app is proudly the first app ever to both support FCM push notifications, and be 100% open-source.
Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.
Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.
>As they say in the Github readme, FCM and Google Maps.
Thanks, I didn't notice that. Reading this, I'm kind of surprised that Signal doesn't offer an OpenStreetMaps build as it seems like it'd be more inline with their philosophy.
Oo, do you have a link for your implementation? I will soon be looking at creating a library to support FCM (android push notifications) in Android apps written in Rust. And having a simpler interface with the OS (esp. if it therefore doesn't require building a non-syste library) would be incredibly helpful.
Thanks! It looks like that repo is GPL though, which I respect but isn't going to work for my usage (where I'm trying to build a generic UI toolkit that can be used by all sorts of applications including closed source ones).
It's just two broadcast receivers (one for receiving the push token, another for receiving actual notifications), and one broadcast sender to ask GSF to give you a token. This code is so trivial it's not even worth separating into a library.
The first one is where you get notifications. The parameters you sent from the server will simply be your intent extras.
The second one is where you get push tokens. There will be a "registration_id" extra string which is your token. It may start with "|ID|1|" (the "kid" parameter from the request, not quite sure what it does), in which case you need to remove that part.
You want to refresh your push token every time your app gets updated and also just periodically if you haven't done it in a while. I do it every 30 days.
Their comment would technically be proprietary code since there's no license alongside it, but grishka wrote the original implementation of the reverse engineered code in that mastodon commit in the first place. So I'd imagine it's free game to use it as a reference (IANAL)
Grishka expresses that the code is trivial. Trivial inventions are not covered by patents. I believe, therefore, that a license for trivial code is not necessary.
But if someone knows better I would appreciate any correction. Legal matters are seldom clear or logical. Your jurisdiction may vary, etc etc.
Patent != copyright. You can patent an algorithm (e.g., Adaptive Replacement Caching, which was scheduled to go into public domain this year but unfortunately got renewed successfully) but when it gets to the level of an actual specific implementation, it's a matter of copyright law.
It's why black-box clones where you look at an application and just try to make one with the same externally-observable behavior without looking at the code is legal (as long as you don't recycle copyrighted assets like images or icons) but can be infringing if you reuse any of the actual source code.
This was an issue that got settled early on and got covered in my SWE ethics class in college, but then more recently was re-tried in Oracle v Google in the case of Google cloning the Java standard library for the Android SDK.
I have no idea how copyright applies here. StackOverflow has a rule in their terms of use that all the user-generated content there is redistributable under some kind of creative commons license that makes it easy to reuse. Perhaps HN has a similar rule? Not that I'm aware of, though.
I reverse-engineered the notification infrastructure in Android, but for me it was the desire to be able to use customer-provided Google API keys ("google-services.json").
The protocol itself was easy, but my problem was that Google Play Services have a special permission to exempt itself from power management. And more importantly, grant that permission temporarily to the individual apps when they have a notification. I don't think I ever found out how to work around this.
OTOH it's nice to have an alternative client. If E2EE messenger system is going to lock itself down hard, trying to "protect" itself from the user even harder than third party adversaries, then I personally see no point - might as well use Whatsapp.
I miss the times IM software respected, or at least didn't fight hard to defeat, the end-user's freedom to computing on their own device, which includes viewing and sending messages through whatever interface they see fit, including indirectly as part of a script/automation. But that was all before E2EE era, hell, before mobile dominance.
> might as well use Whatsapp.
- still scrapes metadata
- run by company who's entire objective is to profile you
Stop being so ridiculous. You can criticize Signal (and there's plenty to critique) but that's just silly. What, should we also just use telegram where E2EE is off by default?
You know signal is open source, right? That's why Molly exists. They can run their own servers too.
Now I wish you could do both. Talk in both signal and the decentralized molly servers. I wish signal had a mesh like feature since it's way harder to snoop on conversations if you have to be physically near. I even wish Signal made the signal sticker site accessible from inside the app. There's tons of things they should do but let's not pretend that just because they're not perfect that we should use apps from a company whose motto might as well be "be evil".
> - run by company who's entire objective is to profile you
And? Pick your poison. Being profiled by Meta isn't high enough on my threat board to be worth switching to E2EE as a countermeasure; in fact, I only use E2EE because Meta forced it on me with Whatsapp (new network effects) and by enabling it in Messenger (old network effects).
But that's besides the point. The point is, I did not expect such an alignment of outcomes between user-hostile corporations and grassroots OSS developers, as both fight to saturate the IM space with network effects-driven apps that disenfranchise end users "because security".
I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification? All more ways to protect the integrity of the network and ensure the user isn't accidentally stripping E2EE by doing something silly like perusing their messages in ways not prescribed by the developer?
> What, should we also just use telegram where E2EE is off by default?
I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).
Firebase, GMS (Google Mobile Services). The Alphabet Corporation is part of many security and privacy conscious users' threat model, and these users aren't generally thrilled about leaking even limited message metadata like timing to their adversary, particularly when that adversary is known to cooperate with global passive adversaries.
There are actually two builds of Molly: Molly and Molly-FOSS. IIRC Molly uses regular Firebase, which can be faster and more reliable but comes with the above tradeoffs, while Molly-FOSS uses UnifiedPush.
Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code, but given you seem to trust GrapheneOS, it's worth noting that they've formally endorsed Molly: https://xcancel.com/GrapheneOS/status/1769277147569443309
> Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code
Also a great point :) And thank you for the reference.
UnifiedPush not works if you not use Molly exclusively on one device. So of you sync between Signal on Win desktop and Android device, your battery drain faster.
been using this for years.. it doesn't have the GCM crap and hence works on de-googlified custom ROMs as well. Surprised how many people don't seem to know about it.
> Surprised how many people don't seem to know about it.
I'm pretty sure people just want to be angry. I mean look at how many people are arguing that updating is... bad. I cannot and will not take those people seriously. It's just such a laughable position.
There's also a great feature with this too. If you don't update for long enough then my chats won't transmit to a vulnerable device, such as one that is running too old of a version. Now that's a great feature
I'm not sure why they're doing it; anyhow, I'd at least avoid doing the initial installation through that repo, you're trusting an additional party for no gain that I could think of (updates are ok because the signature needs to match the one of the installed version).
Android Signal does not support being a companion tablet app to a primary phone Signal. So you have to use Molly if you want to have Signal on your Android tablet. It has been reliable for me in that role since the Pixel Tab came out and I switched from an iPad.
$50 says this is some nation state trying to sow seeds of discord into the Signal user base. Signal is actually becoming so well adopted most of my friends are on it now. Trying to convince them all to use yet another app is going to be pretty tough, especially since there isn’t really any decent evidence that Signal is insecure.
Why should we be trusting this centralized service? I regret getting my family onto Signal as I would love to get there somewhere where we control our data & aren’t reliant on US-based service. When you look at the EU’s Chat Control law that’s trying to be pushed, the easiest target is going to be big, centralized services in jurisdictions friendly to the EU—it’s gonna be real hard doing this with a decentralized protocol. Signal deserves just as much criticism as any other thing operating out of California.
- Signal is built in such a way that you do not need to trust the server. They’ve invented several novel encryption protocols beyond the messaging protocol that protects group membership and privacy.
- they’re open source and people like me regularly read parts of their code and in some cases use their code elsewhere. Also several undergraduates and PhD’s have written research papers on the signal protocol. It’s also the subject of a lot of security research (there was a good talk at defcon this year that found some minor privacy issues with signal notifications)
- no one has built a decentralized e2ee messaging app that’s actually secure and has privacy anything like the bar Signal sets. Matrix are getting close, they’ve recently made some encouraging changes, but it will take some time to verify.
- Moxie the founder of Signal gave a talk about the challenges of building something like signal in a decentralized environment -
https://youtu.be/1W5fuqySBnE
- Signal is a nonprofit. They have stated repeatedly they will shutdown the app in regions or countries that make backdoors required by law.
Signal has always seen some controversy, usually centered around centralization. Also the MOB cryptocurrency, the use of phone numbers, contact discovery,... It has led to the promotion of alternatives such as Matrix and third party applications such as Molly.
But these alternatives are all niches compared to Signal. Which is to say something considering that Signal itself is a niche compared to Whatsapp.
My main grievances with the Signal app are mainly centered around UI and UX, and features. Without trying to be mean, I think it's plain ugly and clunky. Features like live location or persistent multi-device messages etc will probably never be implemented with the current strategy of Signal.
The fact that this "improved" version does not show a single screenshot of the UI on their own website, signals to me (pun intended) that this app will address none of my wishes.
I searched so long for a single screenshot, looking at the app stores (in my browser) and Github with no success.
It really is weird not to show a single screenshot when the 4th listed feature is design ("Material You | Extra theme that follows your device palette").
What client app are you using for Matrix? I really love the idea of switching over to it, or something similar, after Discord's IPO. We tried Revolt, which is now apparently called Stoat Chat, but the 2 killer features with Discord are its screen sharing & noise cancelling. Some of the screen sharing "extras" I could do without, but using Element we found that background noise cancelling is awful. You can hear every seat readjustment, things in other rooms in the person's background, loud breathing, people eating...it's awful.
One thing that would be really nice from a new user perspective would be to have some screenshots so people can visually see the interface. Just giving some "get new users" feedback, not criticizing at all.
Does it lock me out of the app like signal if I don't update the app every few weeks? I'm looking for an app that never needs to be updated; Oh, I guess that is email.
I think the distinction here is they want an app that never NEEDS to be updated, not one that never DOES get updates (which is fair – I'm happy if things just work and are not changed every 2 weeks).
For a security app, it's pretty rational to need to be updated. One of the most common patterns in basically every technological attack is to take a freshly discovered vulnerability and target devices that haven't been updated yet.
It sounds good in theory but signal updates are beyond excessive, sometimes multiple times a day but almost certainly every few days.
Most of the time there is zero explanation for the update. They are just training their users to auto accept updates with no thought about why, which in itself is a security risk.
If signal really is pushing these updates for "security" then it must be one of the most insecure apps ever built. I legitimately can't think of another app or program that updates more frequently... Maybe youtube-dl?
> It sounds good in theory but signal updates are beyond excessive
Those are two different arguments.
Updating too frequently is not equivalent to "doesn't need to be updated." I can agree that they update a bit too frequently but that's nowhere near the argument about never updating.
A program cannot be secure if it does not update. Full stop.
> Most of the time there is zero explanation for the update
There's always a changelog.
If you, unlike most people, are interested it is all open source
That requires the programmer to be omniscient and clairvoyant.
You can get pretty close if you're in a static environment like a machine that never connects to the internet and the hardware never changes and no other software on the machine changes, but neither a phone nor a communication platform allow for that.
The decision to update or not shouldn't be taken away from users.
Frequent updates have the downside of more frequent breakage and of course extra bandwidth usage. Let users make the trade off between those downsides and the risk of zero days.
> update or not shouldn't be taken away from users.
So turn off auto-update? You can do this everywhere except iOS.
> Let users make the trade off between those downsides and the risk of zero days.
Those trade-offs are that if your version is too old (protocol has been updated several times and you are out of the lifetime) then you can no longer communicate with those who have updated as you will make their communications insecure.
If you don't want to update, that's fine. But your preference for not updating doesn't get to override my preference for secure communication. It is literally the whole point of Signal... if you don't want security and privacy then don't use Signal, that's your choice and no one is forcing you to use the app.
The problem is that you're not only putting yourself at risk when you don't update.
You're putting everyone who you've talked to at risk. I don't know about you, but I prefer not having to worry about whether I'm communicating with someone whose installation can easily be pwned by any halfway incompetent attacker.
> a update that I not personally security reviewed
Great, can you give me a summary of the updates for the Linux Kernel, Android Kernel, iOS kernel, libssl, and all the drivers that updated this week on my arch machine?
> Sorry, thats not a argument.
Neither is pretending you're reviewing hundreds of thousands of lines of code a week.
This is Hacker News man, some of us actually understand how computers work.
Then signal must be very insecure, poorly coded app in first place, that needs to updated every or every other day. They also don't give any explanation of what that updates are.
Signal blocks not only the specific app from working if it's not updated, but disables your whole account if you can't update the mobile app.
I had to live without a phone for about a year. First my phone broke and I couldn't repair it or buy a new one, then I lost my phone number due to unpaid fees. I kept using the Linux Electron app, updating it as often as possible.
I saw this message on the Linux app after a while:
> Open Signal on your phone to keep your account active
I couldn't open Signal on my phone or install a new Android Signal app even on an Android VM because I wouldn't be able to get the new app verified without access to the phone number I registered with.
I wrote an email to the support team and got this reply:
> Using Signal for iOS or Android as your primary device in order to link and use Signal for Desktop was always a requirement as a QR code must be scanned to link a device. The primary device must remain active during this usage. There is no way around this.
> Otherwise your account will be deactivated, and you will need to reinstall and register for Signal using an up-to-date version of the application.
And as to when that deactivation would happen, they replied:
> We're unable to provide a specific timeline. We recommend registering for a Signal account on a smartphone and linking your Desktop to that smartphone within the next few weeks.
From their link it seems like there's an actual technical reason behind this. I'm not sure if it's true, but it feels a bit suspect.
So, after a couple of months of seeing this message in the Linux app, I woke up with a deactivated Signal account. I asked some of my Signal contacts to use Matrix until I get a new phone number. It seems much better in this regard - it's not mobile first and it doesn't require ongoing access to a phone number. The basic features are all there, even if there a few minor annoyances and bugs in the clients here and there.
How can I as user differentiate between a security update and a update thats infected by some government trojan? I only have a 'Install or you can't use again'-Button.
weird, I have never been pwned via email which has been updated 0 times in the last 20 years. I guess Signal is just so poorly made it needs to be constantly re-written every 2 weeks.
Email has been updated many times in the last 20 years. All of the major sender authentication protocols (SPF, DKIM, DMARC) were created and deployed over the last 20 years. Email is also famously insecure and lacking a standard way of managing encryption - so the reason you never see updates is because the features signal is changing do not exist in email at all.
SPF, DKIM, DMARC are all about server reputation. They don't count as any sort of update to email and don't affect the protocol. These days regular non E2EE email is as secure as any other messaging protocol that relies on trusted servers. Since it is federated over multiple servers it is better than systems with just one server. You can choose who to trust and can even host it yourself.
Compare with Signal where there is only one allowed server entity and hardly anyone verifies identities making man in the middle attacks trivial.
Signal's official Android app does not support being linked, only the iOS and desktop apps support that. This is why I use Molly.
I would ideally want to not have one device being the master and the rest linked to it (e.g. Element can do that for Matrix) but that might be a too big change. And as far as I know Molly does not try to solve that.
There's a deliberate nit in Signal that you can't have it on both an Android phone and a no-sim Android tablet; both take turns trying to seize the role. Apparently Molly can handle both.
i use it only because it happens to have a convenient 'supply trust chain' on GrapheneOS: (built-in) App Store -> Accrescent[0] -> Molly (seems to ship the 'FOSS' version)
i don't use any of the enhancements, but it does receive notifications over the websocket it keeps open in the background vs only waking up on an FCM push notification like the regular app
i wonder if the supply chain risk of having a second entity (that signs the apks!) involved is really worth it to anyone... hope signal can be published on Accrescent or similar someday :p
To be clear, Signal is not available from F-Droid. The above link is about a fourth party publishing a Signal build in an f-droid-compatible repository.
The local database used by Signal to organize every message, every contact, every profile photo, every attachment, every group, basically every dynamic piece of data you interact with in the app.
Signal is basically a UI layer for a database. The in-transit encryption is genuinely good enough to be textbook study material for cryptographers, but the at-rest encryption became a joke the moment they stopped using your pin to encrypt the local DB and requiring it to open the app.
As someone who's been enthusiastic about Signal since it was TextSecure and RedPhone, the changes made over the years to broaden the userbase have been really exciting from an adoption perspective, and really depressing from a security perspective.
TL;DR of Molly is that it fixes/improves several of those security regressions (and adds new security features, like wiping RAM on db lock) while maintaining transparent compatibility with the official servers, and accordingly, other people using the regular Signal client.
Signal is an end-to-end encrypted messaging app. People continue to breathlessly mentioning the lack of database encryption as a problem, but that never made it a real security issue: its job is not, and has never been, dissuading an attacker who has local access to one of the ends, especially because that is an incoherent security boundary (just like the people who were very upset about Signal using the system keyboard which is potentially backdoored - if your phone is compromised, of course someone will be be able to read your Signal messages).
Database encryption isn't comparable to the keyboard drama. Protecting against malware in your keyboard can be done by using a different meyboard and is of course out of scope.
But if my phone gets taken and an exploit is used to get root access on it, I don't want the messages to be readable and there's nothing I can do about it. It's not like I can just use a different storage backend.
It's also a very simple solution - just let me set an encryption password. It's not an open-ended problem like protecting from malware running on the device when you're using it.
If someone has root access to your apparently unencrypted phone, then they can just launch the Signal app directly and it'll decrypt the database for them.
Which is to say this is an incoherent security boundary: you're not encrypting your phone's storage in a meaningful way, but planning to rely on entering a pin number every time you launch Signal to secure it? (Which in turn is also not secure because a pin is not secure without hardware able to enforce lock outs and tamper resistance...which in this scenario you just indicated have been bypassed).
Any modern Android is encrypted at rest, but if your phone is taken after first unlock, they get access to the plaintext storage. That's the attack vector.
A passphrase can be long, not just a short numeric PIN. It can be different from the phone unlock one. It could even be different for different chats.
> Upon boot, the user must provide their credentials before any part of the disk is accessible.
> While this is great for security, it means that most of the core functionality of the phone is not immediately available when users reboot their device. Because access to their data is protected behind their single user credential, features like alarms could not operate, accessibility services were unavailable, and phones could not receive calls.
I'm sure they could have found a better approach, instead of file based encryption, but must have been nice to simplify engineering overhead and giving 3 letter agencies, at the same time, something that simplifies their work.
Depends on quite a few other factors, but if someone with a GrayKey or Cellebrite appliance gets your phone, there's a good chance they can get in both in BFU and AFU states, even if locked. Once unlocked (or broken into), stock Signal offers you zero protection, while Molly forces them to start a brute force attack against the password you gave Molly.
This is less true for fully patched GrapheneOS devices than it is for fully patched iOS and other Android devices, but this space is basically a constantly evolving cat and mouse game. We don't get a press release when GrayKey or Cellebrite develop a new zero day, so defense in depth can be helpful even for hardened platforms like GOS.
> As someone who's been enthusiastic about Signal since it was TextSecure and RedPhone, the changes made over the years to broaden the userbase have been really exciting from an adoption perspective, and really depressing from a security perspective.
As always, it depends on your threat model.
I use signal because I value my privacy and don't trust Facebook. Not because I'm an activist. So I'm in the target group for Signal's new behavior and I welcome it (especially since to use it to share personal information that I don't want Facebook or advertisers to get, I need my parents and in-laws to use it as well, so it must be user friendly enough).
I wish they continue moving forward in that direction by the way and allow shared pictures to be stored directly on the phone's main memory (or at least add an opt-in setting for that), because the security I get from it not being is zero and the usability suffers significantly.
You're absolutely right that the appropriate level of security does depend on someone's threat model, but I do want to point out that you don't need to be an activist to benefit from privacy.
I'm a really big fan of the airport bathroom analogy. When you use the restroom in the airport, you close the stall door behind you.
You're not doing anything wrong, you have nothing to hide, and everyone knows what you're doing. But you take actions to preserve your privacy anyway, and that's good.
Everyone deserves privacy, and the psychological comfort that comes with it. Dance like nobody's watching, encrypt like everyone is :)
That's not the point the GP was making. They meant "I'd rather give up a bit of privacy for a big increase in usability, as I'm not in the group of people that needs extreme privacy". I happen to agree with them, I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
> I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
This is a much better way of saying what I wanted, thank you.
I mentioned some of the pragmatic constraints of fully trusting typical Android / iOS FDE to fully protect the confidentiality of Signal messages in another comment above that I would encourage you to read.
That said, Molly definitely isn't designed for the average person's threat model, that's totally true, but it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't, but rather as journeys, where every step in the right direction is a good one.
I'd always encourage everyone to question their own assumptions about security and never stop learning, it's good for your brain even if you ultimately decide that you don't want to accept the tradeoffs of an approach like the one Molly takes towards at-rest encryption.
I assume its your comment about if the phone is compromised they still need to bruteforce the signal db.
I find that unconvincing. If your phone is hacked, your phone is hacked. I think its bad to make assumptions that an attacker can compromise your phone but not log keystrokes. I'm not super familiar with state of the art of phone malware and countermeasures, but i think anything trying to be secure in the face of a compromised platform is like trying to get toothpaste back in the tube.
> it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
Threat models are just as much about ensuring you have all your bases covered as ensuring you don't spend effort in counterproductive ways.
> IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't
I agree. I think security is relative to the threat you are trying to defend against. There are no absolutes.
> but rather as journeys, where every step in the right direction is a good one.
Here is where i disagree. Just because you take a step does not mean you are walking forward.
A poorly thought out security measure can have negative impacts on overall system security.
Going through customs, in most countries their policies allow them to search, image, or confiscate your phone, but not evilmaid it or rubberhose you. For some travelers, that's their threat model.
There will likely never be federation between Signal's official servers and any other servers. Signal introduces privacy features semiregularly; we all saw with Matrix how difficult that is in a highly-federated environment.
This is huge. There's been 3rd party Signal library for this for years -- and for some reason I can't determine, the developers have opted NOT to do this.
this is why molly.im was a lifesaver for me.. trying to move a family member from VIBER to SIGNAL and ran into the annoying roadblock of not being able to link an Android tablet to an Android phone like Viber can - but molly does it fine.
I’ve never trusted signal. Signal desktop does not seem reproducible . It’s not clear to me how its infrastructure is deployed. The servers buffer messages to a large degree
Is there a specific part you're referring to? For those of us who don't read or write Java frequently, it's not clear whether it's worth it to spend time reading the code without at least having some sense of whether you might be making a compelling point or not.
You need to be more specific. Lots of security-conscious apps wipe their memory. Memory contains, among other things, the decrypted text and private keys for the app. RAM is known to hold data longer than you'd want, and it can be swapped out onto persistent storage like the internal SSD. If you don't know that wiping memory is a basic and common feature for apps like this, then you're not qualified to have an opinion. Now if you think wiping the memory is ineffective, inefficient, or superceded by a bigger issue, then we might have something to talk about.
Phone numbers aren't required now. But there are flaws in Signal. Your phone usage can be tracked in high resolution through constant pinging of malformed status messages. I can't find the paper right now but researchers found that they could track their own data about when the phone was on, unlocked, and had Signal on the screen. That can be correlated between users, to see who is talking to who. It can be used to try to ambush you while the phone is unlocked. You don't even have to have a connection to the spies, if I remember right. Signal devs have done nothing about this issue since being notified like a year ago.
Edit: Found it! "Careless Whisper:
Exploiting Silent Delivery Receipts to Monitor
Users on Mobile Instant Messengers" https://arxiv.org/abs/2411.11194
It has various improvements and you can also use your private signal server.
I believe it also lets you backup your data! How about that for digital sovereignty.
Are Signal developers trustworthy enough? What about this push for "cloud backups"? There are other flaws in Signal too like being able to monitor people's phone usage and stuff through the notification system. I can't find it now but Signal and WeChat have the same issues, and both received a disclosure. Only WeChat did anything about it. Sad...
Edit: Found it! "Careless Whisper:
Exploiting Silent Delivery Receipts to Monitor
Users on Mobile Instant Messengers" https://arxiv.org/abs/2411.11194
There is nothing legally stopping people from forking the signal app and distributing it (even configured to talk to the official signal.org servers) so long as they don’t use the Signal trademarks.
Also, as others pointed out, Moxie isn’t part of Signal any longer and hasn’t been for a while.
I've used Molly for over a year. Overnight it lost the device registration and will not contact the servers to re-register. The backup feature also does not work which left me dead in the water for several days with no fix. I switched back to signal and had to start a new database. It was a disaster. YMMV
Sounds pretty much like my experience with the official Signal app. It is a mess too and I only use Signal/Molly because I have friends who use it.
But sadly the competitors are as bad, just in different ways. Why has nobody yet managed to build a good IM client? It does not seem like we have come far from what we had back in the Pidgin days.
I’ve used Signal across many devices for years with zero problems.
Signal seems to work alright for me, although I felt the desktop app gets a bit annoying because of too many frequent updates happening to the app, which I believe is based on Electron.
But besides this, there is really a strong need for a web client, just like Telegram or WhatsApp. If only the protocol can be extended in such a way that it allows for integrating into a web app, that would be incredibly great.
I have been particularly impressed with the device migration experience. I have an 18gb db, and even the time my device died I managed to get things over correctly.
conversations (xmpp) and deltachat work pretty well in my experience.
Dino (XMPP, https://dino.im) is a great desktop client to talk to other XMPP clients, in particular Conversations, due to its broad support of XEPs.
Conversations has an issue where the main tool for reading a backup on a computer (ceb2txt (so, say, I can properly and correctly archive a text dump archive of a person I loved who died)), will not work for me. I filed a support request and there's been no movement on it whatsoever and it genuinely seems like nobody gives a shit. Restoring a backup even with all the images and media files in the correct place with the correct filenames will then refuse to show any filenames.
This is par for the course with chat backups, though.
Messenger - Bad - No way to save chat responses of people you have talked to. This means you only ever have one side of a conversation, making it meaningless.
Twitter DMs - Bad - See Messenger.
Jami - Ehhhh - Saves a git local repository of messages. The only problem is message syncing is effing abysmal.
Dino (XMPP) - Bad - Does not allow backing anything up, this is "intentional". Depending on which protocol you use, as soon as you move to another device all the messages you _had_ are retroactively converted to Cannot Decrypt. They're my effing messages!
Discord - Good - Discord History Tracker (tedious to use but slurps everything up into a sqlite3 database that is itself, an official archival format)
WhatsApp - Good - Dumps a text record + files/images/etc. onto the phone's filesystem. This is reasonably easy to archive.
Signal - Mediocre - If you have an old Signal backup from 2018? That you could only transfer off your phone by deleting old messages? lmao you're effed. Load up a version from ten years ago, gradually update it and then maybe, MAYBE you can extract the sqlite3 archive? These days you have a .signalbackup or whatever which is an encrypted archive, and I assume that there's a tool to decrypt it, but uhhhhhh. Last I tried to use it it required way more RAM than I had accessible.
What about Telegram?
Telegram, which ostensibly claimed to provide e2e but really only did in very specific circumstances? My right wing uncle is still bitter about that. Then there's the rolling over the founder did after getting pulled up by Interpol.
I'm not sure why anyone would trust Telegram.
Very few of the protocols supported by Pidgin were encrypted, unless you used the OTR plugin. That makes it a lot easier to support things like chat history.
Shouldn't your client have no problem saving a chat history? It is, by definition, able to read every message you send and receive.
I used the OTR plugin a lot.
Beeper is pretty good. I daily drive it on multiple protocols.
I love beeper and have been using it for a very long time at this point, but I wouldn’t go as far as calling it a good client.
Whatsapp mentions don’t work (just show the name of the mention to the other users), and polls or albums don’t work.
Messenger disconnects every couple of days at this point.
Pasting links won’t always expand.
Attachments are always hit or miss.
So many small other things. Still love it.
The deathblow for Signal was that I was in a group and some group messages just got lost for some members completely unnoticed. So you could never be sure if you missed something or someone. I'm using WhatsApp again, now since years and had never issues, it just works.
The Whisperfish [1] project (a Signal messenger for Sailfish OS) maintains an independent Signal client library written in Rust [2]. It works quite well - unless Signal decides to change their protocols or kick non-standard clients.
[1] https://gitlab.com/whisperfish/whisperfish
[2] https://github.com/whisperfish/presage
To be clear this library depends on libsignal.
Whisperfish appears to be an app, not a library.
hiq's comment was not about Whisperfish but about the presage library. My comment can be read as "Whisperfish wrote their own implementation of the signal protocol" - which is wrong. (Sorry, can't edit it anymore)
With presage, Whisperfish has a high-level Rust library that wraps the official libsignal libraries (which are also written in Rust) and makes it much easier to write clients. The official Signal repo only contains Java/Typescript/Swift wrappers. As presage is rather obscure, I thought that some HN readers might appreciate the link.
> Contains no proprietary blobs, unlike Signal
What "proprietary blobs" does Signal have?
I'll also just add: it's probably not a good idea to use any modifications to an E2EE messenger unless you are comfortable with those privacy/security guarantees possibly being violated by the 3rd party code.
The only exception to this would be if I really trusted the goals of the 3rd party, like Graphene.
> What "proprietary blobs" does Signal have?
As they say in the Github readme, FCM and Google Maps.
FCM doesn't technically require a blob — it's just that Google wants you to think it does. I reverse engineered their library and it turned out to be a criminally over-engineered wrapper around two broadcast receivers. So, the Mastodon app is proudly the first app ever to both support FCM push notifications, and be 100% open-source.
FCM = Firebase Cloud Messaging, a messaging and notification service run by Google. https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging
Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.
Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.
>As they say in the Github readme, FCM and Google Maps.
Thanks, I didn't notice that. Reading this, I'm kind of surprised that Signal doesn't offer an OpenStreetMaps build as it seems like it'd be more inline with their philosophy.
The app doesn't even recognize geo:.. links, which makes degoogling rather hard.
Oo, do you have a link for your implementation? I will soon be looking at creating a library to support FCM (android push notifications) in Android apps written in Rust. And having a simpler interface with the OS (esp. if it therefore doesn't require building a non-syste library) would be incredibly helpful.
Looks like this is the first commit where it was added: https://github.com/mastodon/mastodon-android/commit/a0cbf0fa...
Thanks! It looks like that repo is GPL though, which I respect but isn't going to work for my usage (where I'm trying to build a generic UI toolkit that can be used by all sorts of applications including closed source ones).
It's just two broadcast receivers (one for receiving the push token, another for receiving actual notifications), and one broadcast sender to ask GSF to give you a token. This code is so trivial it's not even worth separating into a library.
Here's how you request a push token:
Here are the two receivers: The first one is where you get notifications. The parameters you sent from the server will simply be your intent extras.The second one is where you get push tokens. There will be a "registration_id" extra string which is your token. It may start with "|ID|1|" (the "kid" parameter from the request, not quite sure what it does), in which case you need to remove that part.
You want to refresh your push token every time your app gets updated and also just periodically if you haven't done it in a while. I do it every 30 days.
Coming from the npm world, I see enough code for at least two libraries.
But seriously, write this as a blog post, more people need to know about this, and I'd like to have something "authoritative" to send references to.
Did you just invent a way to circumvent the GPL? Brilliant! j/k ofc
Their comment would technically be proprietary code since there's no license alongside it, but grishka wrote the original implementation of the reverse engineered code in that mastodon commit in the first place. So I'd imagine it's free game to use it as a reference (IANAL)
Grishka expresses that the code is trivial. Trivial inventions are not covered by patents. I believe, therefore, that a license for trivial code is not necessary.
But if someone knows better I would appreciate any correction. Legal matters are seldom clear or logical. Your jurisdiction may vary, etc etc.
Patent != copyright. You can patent an algorithm (e.g., Adaptive Replacement Caching, which was scheduled to go into public domain this year but unfortunately got renewed successfully) but when it gets to the level of an actual specific implementation, it's a matter of copyright law.
It's why black-box clones where you look at an application and just try to make one with the same externally-observable behavior without looking at the code is legal (as long as you don't recycle copyrighted assets like images or icons) but can be infringing if you reuse any of the actual source code.
This was an issue that got settled early on and got covered in my SWE ethics class in college, but then more recently was re-tried in Oracle v Google in the case of Google cloning the Java standard library for the Android SDK.
I have no idea how copyright applies here. StackOverflow has a rule in their terms of use that all the user-generated content there is redistributable under some kind of creative commons license that makes it easy to reuse. Perhaps HN has a similar rule? Not that I'm aware of, though.
This is a copyright question not patent one.
If you need something permissively licensed, I believe microG also has implementation of the notification protocol: https://github.com/microg/GmsCore/blob/cb9be8f682d7649dae23b...
It's Apache 2.
Please consider supporting https://unifiedpush.org/ in addition to/instead of FCM.
I reverse-engineered the notification infrastructure in Android, but for me it was the desire to be able to use customer-provided Google API keys ("google-services.json").
The protocol itself was easy, but my problem was that Google Play Services have a special permission to exempt itself from power management. And more importantly, grant that permission temporarily to the individual apps when they have a notification. I don't think I ever found out how to work around this.
OTOH it's nice to have an alternative client. If E2EE messenger system is going to lock itself down hard, trying to "protect" itself from the user even harder than third party adversaries, then I personally see no point - might as well use Whatsapp.
I miss the times IM software respected, or at least didn't fight hard to defeat, the end-user's freedom to computing on their own device, which includes viewing and sending messages through whatever interface they see fit, including indirectly as part of a script/automation. But that was all before E2EE era, hell, before mobile dominance.
You know signal is open source, right? That's why Molly exists. They can run their own servers too.
Now I wish you could do both. Talk in both signal and the decentralized molly servers. I wish signal had a mesh like feature since it's way harder to snoop on conversations if you have to be physically near. I even wish Signal made the signal sticker site accessible from inside the app. There's tons of things they should do but let's not pretend that just because they're not perfect that we should use apps from a company whose motto might as well be "be evil".
> - still scrapes metadata
> - run by company who's entire objective is to profile you
And? Pick your poison. Being profiled by Meta isn't high enough on my threat board to be worth switching to E2EE as a countermeasure; in fact, I only use E2EE because Meta forced it on me with Whatsapp (new network effects) and by enabling it in Messenger (old network effects).
But that's besides the point. The point is, I did not expect such an alignment of outcomes between user-hostile corporations and grassroots OSS developers, as both fight to saturate the IM space with network effects-driven apps that disenfranchise end users "because security".
I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification? All more ways to protect the integrity of the network and ensure the user isn't accidentally stripping E2EE by doing something silly like perusing their messages in ways not prescribed by the developer?
> What, should we also just use telegram where E2EE is off by default?
I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).
> What, should we also just use telegram where E2EE is off by default?
There are plenty of others, all with their pros and cons.
Ultimately,the network effect is usually the hardest parameter to overcome.
Ironically, the only person who mentionned wanting to use signal instead of whatsapp in my network circle is my 71y old mother.
You should listen to your mother.
edit: lol, i assumed you were the OP. ignore me
Firebase, GMS (Google Mobile Services). The Alphabet Corporation is part of many security and privacy conscious users' threat model, and these users aren't generally thrilled about leaking even limited message metadata like timing to their adversary, particularly when that adversary is known to cooperate with global passive adversaries.
There are actually two builds of Molly: Molly and Molly-FOSS. IIRC Molly uses regular Firebase, which can be faster and more reliable but comes with the above tradeoffs, while Molly-FOSS uses UnifiedPush.
Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code, but given you seem to trust GrapheneOS, it's worth noting that they've formally endorsed Molly: https://xcancel.com/GrapheneOS/status/1769277147569443309
> Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code
Also a great point :) And thank you for the reference.
UnifiedPush not works if you not use Molly exclusively on one device. So of you sync between Signal on Win desktop and Android device, your battery drain faster.
This app's killer feature for me is that it's actually available on F-Droid, unlike its upstream.
Happy user for many years now, thanks for the support!
APKs are available btw
https://signal.org/android/apk/
That's not enough.
been using this for years.. it doesn't have the GCM crap and hence works on de-googlified custom ROMs as well. Surprised how many people don't seem to know about it.
Self-updating too!
That’s a bug, not a feature. I don’t wish to give OWS permanent RCE on my devices.
So don't update. Problem solved...
There's also a great feature with this too. If you don't update for long enough then my chats won't transmit to a vulnerable device, such as one that is running too old of a version. Now that's a great feature
There is also a signal build in the fdroid repo of the Guardian Project
which is easily enabled in f-droid: settings > repositories > toggle it on
"fdroid repos" have little to do with what people consider F-Droid, they can host any whatsoever binary.
In fact, that's not a build by the Guardian Project, but (when I tried) a redistribution of Signal's https://github.com/signalapp/Signal-Android/releases builds.
I'm not sure why they're doing it; anyhow, I'd at least avoid doing the initial installation through that repo, you're trusting an additional party for no gain that I could think of (updates are ok because the signature needs to match the one of the installed version).
Didn’t know this was in there, thanks!
The killer feature for me is that molly-im also supports UnifiedPush for notifications instead of just websocket and FCM like upstream Signal.
Good to know - that would make my life a little easier.
I don't want a new chat app, I want an unified protocol and bring my own client
Android Signal does not support being a companion tablet app to a primary phone Signal. So you have to use Molly if you want to have Signal on your Android tablet. It has been reliable for me in that role since the Pixel Tab came out and I switched from an iPad.
$50 says this is some nation state trying to sow seeds of discord into the Signal user base. Signal is actually becoming so well adopted most of my friends are on it now. Trying to convince them all to use yet another app is going to be pretty tough, especially since there isn’t really any decent evidence that Signal is insecure.
Why should we be trusting this centralized service? I regret getting my family onto Signal as I would love to get there somewhere where we control our data & aren’t reliant on US-based service. When you look at the EU’s Chat Control law that’s trying to be pushed, the easiest target is going to be big, centralized services in jurisdictions friendly to the EU—it’s gonna be real hard doing this with a decentralized protocol. Signal deserves just as much criticism as any other thing operating out of California.
- Signal is built in such a way that you do not need to trust the server. They’ve invented several novel encryption protocols beyond the messaging protocol that protects group membership and privacy.
- they’re open source and people like me regularly read parts of their code and in some cases use their code elsewhere. Also several undergraduates and PhD’s have written research papers on the signal protocol. It’s also the subject of a lot of security research (there was a good talk at defcon this year that found some minor privacy issues with signal notifications)
- no one has built a decentralized e2ee messaging app that’s actually secure and has privacy anything like the bar Signal sets. Matrix are getting close, they’ve recently made some encouraging changes, but it will take some time to verify.
- Moxie the founder of Signal gave a talk about the challenges of building something like signal in a decentralized environment - https://youtu.be/1W5fuqySBnE
- Signal is a nonprofit. They have stated repeatedly they will shutdown the app in regions or countries that make backdoors required by law.
Because they’re multi-region AWS!
/s
It is a Signal client that uses same servers (i.e Users of Molly and Signal's official app can message and call each othera normally).
Signal has always seen some controversy, usually centered around centralization. Also the MOB cryptocurrency, the use of phone numbers, contact discovery,... It has led to the promotion of alternatives such as Matrix and third party applications such as Molly.
But these alternatives are all niches compared to Signal. Which is to say something considering that Signal itself is a niche compared to Whatsapp.
If so they are certainly doing it ambitiously by fixing longstanding issues in Signal.
My main grievances with the Signal app are mainly centered around UI and UX, and features. Without trying to be mean, I think it's plain ugly and clunky. Features like live location or persistent multi-device messages etc will probably never be implemented with the current strategy of Signal.
The fact that this "improved" version does not show a single screenshot of the UI on their own website, signals to me (pun intended) that this app will address none of my wishes.
I searched so long for a single screenshot, looking at the app stores (in my browser) and Github with no success.
It really is weird not to show a single screenshot when the 4th listed feature is design ("Material You | Extra theme that follows your device palette").
Came here to comment exactly this. Even opened github expecting to see something...
Really? Signal does everything I want from a messaging app. I can't imagine what could be better about its GUI. But I'm no GUI designer.
Does it add back the killer feature of SMS fallback?
If not, I'll stick with Matrix. It's got privacy at least as good as signal, with Discord's UX.
No, Matrix privacy is in no way comparable with signal.
What client app are you using for Matrix? I really love the idea of switching over to it, or something similar, after Discord's IPO. We tried Revolt, which is now apparently called Stoat Chat, but the 2 killer features with Discord are its screen sharing & noise cancelling. Some of the screen sharing "extras" I could do without, but using Element we found that background noise cancelling is awful. You can hear every seat readjustment, things in other rooms in the person's background, loud breathing, people eating...it's awful.
One thing that would be really nice from a new user perspective would be to have some screenshots so people can visually see the interface. Just giving some "get new users" feedback, not criticizing at all.
Does it lock me out of the app like signal if I don't update the app every few weeks? I'm looking for an app that never needs to be updated; Oh, I guess that is email.
Why do you want an app that never gets updated? You want bugs to persist and security issues to persist?
AFAIK signal only blocks due to security patches. Which it's on a much longer timeframe than a few weeks.
I think the distinction here is they want an app that never NEEDS to be updated, not one that never DOES get updates (which is fair – I'm happy if things just work and are not changed every 2 weeks).
For a security app, it's pretty rational to need to be updated. One of the most common patterns in basically every technological attack is to take a freshly discovered vulnerability and target devices that haven't been updated yet.
It sounds good in theory but signal updates are beyond excessive, sometimes multiple times a day but almost certainly every few days.
Most of the time there is zero explanation for the update. They are just training their users to auto accept updates with no thought about why, which in itself is a security risk.
If signal really is pushing these updates for "security" then it must be one of the most insecure apps ever built. I legitimately can't think of another app or program that updates more frequently... Maybe youtube-dl?
Updating too frequently is not equivalent to "doesn't need to be updated." I can agree that they update a bit too frequently but that's nowhere near the argument about never updating.
A program cannot be secure if it does not update. Full stop.
There's always a changelog.If you, unlike most people, are interested it is all open source
I would suggest looking at the actual commits and not just the release notes. Libsignal usually has more info about the security Probably because they do so silently.You can get pretty close if you're in a static environment like a machine that never connects to the internet and the hardware never changes and no other software on the machine changes, but neither a phone nor a communication platform allow for that.
The decision to update or not shouldn't be taken away from users.
Frequent updates have the downside of more frequent breakage and of course extra bandwidth usage. Let users make the trade off between those downsides and the risk of zero days.
If you don't want to update, that's fine. But your preference for not updating doesn't get to override my preference for secure communication. It is literally the whole point of Signal... if you don't want security and privacy then don't use Signal, that's your choice and no one is forcing you to use the app.
The problem is that you're not only putting yourself at risk when you don't update.
You're putting everyone who you've talked to at risk. I don't know about you, but I prefer not having to worry about whether I'm communicating with someone whose installation can easily be pwned by any halfway incompetent attacker.
It's the same when I install a update that I not personally security reviewed. Sorry, thats not a argument.
This is Hacker News man, some of us actually understand how computers work.
Then signal must be very insecure, poorly coded app in first place, that needs to updated every or every other day. They also don't give any explanation of what that updates are.
I’d love to red team your workplace.
Signal blocks not only the specific app from working if it's not updated, but disables your whole account if you can't update the mobile app.
I had to live without a phone for about a year. First my phone broke and I couldn't repair it or buy a new one, then I lost my phone number due to unpaid fees. I kept using the Linux Electron app, updating it as often as possible.
I saw this message on the Linux app after a while:
> Open Signal on your phone to keep your account active
I couldn't open Signal on my phone or install a new Android Signal app even on an Android VM because I wouldn't be able to get the new app verified without access to the phone number I registered with.
I wrote an email to the support team and got this reply:
> Using Signal for iOS or Android as your primary device in order to link and use Signal for Desktop was always a requirement as a QR code must be scanned to link a device. The primary device must remain active during this usage. There is no way around this.
> For more information and recovery steps please see our faq page here: https://support.signal.org/hc/articles/8997185514138-Re-conn...
> Otherwise your account will be deactivated, and you will need to reinstall and register for Signal using an up-to-date version of the application.
And as to when that deactivation would happen, they replied:
> We're unable to provide a specific timeline. We recommend registering for a Signal account on a smartphone and linking your Desktop to that smartphone within the next few weeks.
From their link it seems like there's an actual technical reason behind this. I'm not sure if it's true, but it feels a bit suspect.
So, after a couple of months of seeing this message in the Linux app, I woke up with a deactivated Signal account. I asked some of my Signal contacts to use Matrix until I get a new phone number. It seems much better in this regard - it's not mobile first and it doesn't require ongoing access to a phone number. The basic features are all there, even if there a few minor annoyances and bugs in the clients here and there.
How can I as user differentiate between a security update and a update thats infected by some government trojan? I only have a 'Install or you can't use again'-Button.
Enjoy getting pwned by zero-click exploits that have been widely patched elsewhere and disclosed publicly, I guess?
weird, I have never been pwned via email which has been updated 0 times in the last 20 years. I guess Signal is just so poorly made it needs to be constantly re-written every 2 weeks.
Email has been updated many times in the last 20 years. All of the major sender authentication protocols (SPF, DKIM, DMARC) were created and deployed over the last 20 years. Email is also famously insecure and lacking a standard way of managing encryption - so the reason you never see updates is because the features signal is changing do not exist in email at all.
SPF, DKIM, DMARC are all about server reputation. They don't count as any sort of update to email and don't affect the protocol. These days regular non E2EE email is as secure as any other messaging protocol that relies on trusted servers. Since it is federated over multiple servers it is better than systems with just one server. You can choose who to trust and can even host it yourself.
Compare with Signal where there is only one allowed server entity and hardly anyone verifies identities making man in the middle attacks trivial.
PGP/GNUPG has worked well for me for nearly three decades.
You're running 2005 versions of your mail-daemon in prod?
please include a screenshot of your app somewhere on your website or repo. why would I download an app if I don't even know what it looks like?
It looks like signal
> multi-device
Can someone explain, is this different from adding (up to 5) devices to your Signal account? Are these devices all "primary" or something?
Signal's official Android app does not support being linked, only the iOS and desktop apps support that. This is why I use Molly.
I would ideally want to not have one device being the master and the rest linked to it (e.g. Element can do that for Matrix) but that might be a too big change. And as far as I know Molly does not try to solve that.
There's a deliberate nit in Signal that you can't have it on both an Android phone and a no-sim Android tablet; both take turns trying to seize the role. Apparently Molly can handle both.
Yeah, that is why I started using Molly.
I just saw a blog post they’re working on this in the official app, though! Finally. Fingers crossed.
Are you sure about that?
I used both desktop and android with no issues.
Your android is the master and desktop is a slave to it, no?
I have multiple android devices and I can only log into signal on one. I can have as many desktop slaves as I want tho.
100% I checked again 3 days ago when setting up Signal on a new Android device. It still does not support it while Molly does.
i use it only because it happens to have a convenient 'supply trust chain' on GrapheneOS: (built-in) App Store -> Accrescent[0] -> Molly (seems to ship the 'FOSS' version)
i don't use any of the enhancements, but it does receive notifications over the websocket it keeps open in the background vs only waking up on an FCM push notification like the regular app
i wonder if the supply chain risk of having a second entity (that signs the apks!) involved is really worth it to anyone... hope signal can be published on Accrescent or similar someday :p
[0] https://accrescent.app/
supply trust chain and GrapheneOS in the same sentence?
> vs only waking up on an FCM push notification like the regular app
FWIW you can actually do the FOSS version of this now with UnifiedPush support (rolled out in Molly a while back).
It's a massive saver on battery life but it does require that you have a server set up to forward notifications to your unifiedpush distributor.
can you install fdroid from the graphene store? signal is available in there: https://news.ycombinator.com/item?id=46082592
To be clear, Signal is not available from F-Droid. The above link is about a fourth party publishing a Signal build in an f-droid-compatible repository.
> Protects database
What database?
This page is clearly written for developers that are already familiar with it.
From this I can already predict this project is going nowhere.
>What database?
The local database used by Signal to organize every message, every contact, every profile photo, every attachment, every group, basically every dynamic piece of data you interact with in the app.
Signal is basically a UI layer for a database. The in-transit encryption is genuinely good enough to be textbook study material for cryptographers, but the at-rest encryption became a joke the moment they stopped using your pin to encrypt the local DB and requiring it to open the app.
As someone who's been enthusiastic about Signal since it was TextSecure and RedPhone, the changes made over the years to broaden the userbase have been really exciting from an adoption perspective, and really depressing from a security perspective.
TL;DR of Molly is that it fixes/improves several of those security regressions (and adds new security features, like wiping RAM on db lock) while maintaining transparent compatibility with the official servers, and accordingly, other people using the regular Signal client.
Signal is an end-to-end encrypted messaging app. People continue to breathlessly mentioning the lack of database encryption as a problem, but that never made it a real security issue: its job is not, and has never been, dissuading an attacker who has local access to one of the ends, especially because that is an incoherent security boundary (just like the people who were very upset about Signal using the system keyboard which is potentially backdoored - if your phone is compromised, of course someone will be be able to read your Signal messages).
Database encryption isn't comparable to the keyboard drama. Protecting against malware in your keyboard can be done by using a different meyboard and is of course out of scope.
But if my phone gets taken and an exploit is used to get root access on it, I don't want the messages to be readable and there's nothing I can do about it. It's not like I can just use a different storage backend.
It's also a very simple solution - just let me set an encryption password. It's not an open-ended problem like protecting from malware running on the device when you're using it.
If someone has root access to your apparently unencrypted phone, then they can just launch the Signal app directly and it'll decrypt the database for them.
Which is to say this is an incoherent security boundary: you're not encrypting your phone's storage in a meaningful way, but planning to rely on entering a pin number every time you launch Signal to secure it? (Which in turn is also not secure because a pin is not secure without hardware able to enforce lock outs and tamper resistance...which in this scenario you just indicated have been bypassed).
Any modern Android is encrypted at rest, but if your phone is taken after first unlock, they get access to the plaintext storage. That's the attack vector.
A passphrase can be long, not just a short numeric PIN. It can be different from the phone unlock one. It could even be different for different chats.
Isn't the phone filesystem encrypted?
Used to be supported in Android (and how I had my phones setup before). Since Android 13 it's no longer possible https://source.android.com/docs/security/features/encryption...
Their justification here https://source.android.com/docs/security/features/encryption is that
> Upon boot, the user must provide their credentials before any part of the disk is accessible.
> While this is great for security, it means that most of the core functionality of the phone is not immediately available when users reboot their device. Because access to their data is protected behind their single user credential, features like alarms could not operate, accessibility services were unavailable, and phones could not receive calls.
I'm sure they could have found a better approach, instead of file based encryption, but must have been nice to simplify engineering overhead and giving 3 letter agencies, at the same time, something that simplifies their work.
Depends on quite a few other factors, but if someone with a GrayKey or Cellebrite appliance gets your phone, there's a good chance they can get in both in BFU and AFU states, even if locked. Once unlocked (or broken into), stock Signal offers you zero protection, while Molly forces them to start a brute force attack against the password you gave Molly.
This is less true for fully patched GrapheneOS devices than it is for fully patched iOS and other Android devices, but this space is basically a constantly evolving cat and mouse game. We don't get a press release when GrayKey or Cellebrite develop a new zero day, so defense in depth can be helpful even for hardened platforms like GOS.
> As someone who's been enthusiastic about Signal since it was TextSecure and RedPhone, the changes made over the years to broaden the userbase have been really exciting from an adoption perspective, and really depressing from a security perspective.
As always, it depends on your threat model.
I use signal because I value my privacy and don't trust Facebook. Not because I'm an activist. So I'm in the target group for Signal's new behavior and I welcome it (especially since to use it to share personal information that I don't want Facebook or advertisers to get, I need my parents and in-laws to use it as well, so it must be user friendly enough).
I wish they continue moving forward in that direction by the way and allow shared pictures to be stored directly on the phone's main memory (or at least add an opt-in setting for that), because the security I get from it not being is zero and the usability suffers significantly.
You're absolutely right that the appropriate level of security does depend on someone's threat model, but I do want to point out that you don't need to be an activist to benefit from privacy.
I'm a really big fan of the airport bathroom analogy. When you use the restroom in the airport, you close the stall door behind you.
You're not doing anything wrong, you have nothing to hide, and everyone knows what you're doing. But you take actions to preserve your privacy anyway, and that's good.
Everyone deserves privacy, and the psychological comfort that comes with it. Dance like nobody's watching, encrypt like everyone is :)
That's not the point the GP was making. They meant "I'd rather give up a bit of privacy for a big increase in usability, as I'm not in the group of people that needs extreme privacy". I happen to agree with them, I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
> I get more benefit from a fairly-private messaging app my friends can use than from an extremely-private messaging app nobody in my social circle can use.
This is a much better way of saying what I wanted, thank you.
Yes, but this was not about the database, really.
Meh, most phones have full disk encryption. For the average person, encryption at rest in signal doesn't provide very much.
No they don't. The current releases for android and iOS both use file based encryption on most supported phones.
I mentioned some of the pragmatic constraints of fully trusting typical Android / iOS FDE to fully protect the confidentiality of Signal messages in another comment above that I would encourage you to read.
That said, Molly definitely isn't designed for the average person's threat model, that's totally true, but it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't, but rather as journeys, where every step in the right direction is a good one.
I'd always encourage everyone to question their own assumptions about security and never stop learning, it's good for your brain even if you ultimately decide that you don't want to accept the tradeoffs of an approach like the one Molly takes towards at-rest encryption.
I assume its your comment about if the phone is compromised they still need to bruteforce the signal db.
I find that unconvincing. If your phone is hacked, your phone is hacked. I think its bad to make assumptions that an attacker can compromise your phone but not log keystrokes. I'm not super familiar with state of the art of phone malware and countermeasures, but i think anything trying to be secure in the face of a compromised platform is like trying to get toothpaste back in the tube.
> it's also worth noting that just because someone isn't aware of a certain risk in their threat model, that doesn't mean they will never benefit from taking steps to proactively protect themselves from that risk.
Threat models are just as much about ensuring you have all your bases covered as ensuring you don't spend effort in counterproductive ways.
> IMO, security and privacy are best conceptualized not as binary properties where you either have it or you don't
I agree. I think security is relative to the threat you are trying to defend against. There are no absolutes.
> but rather as journeys, where every step in the right direction is a good one.
Here is where i disagree. Just because you take a step does not mean you are walking forward.
A poorly thought out security measure can have negative impacts on overall system security.
Going through customs, in most countries their policies allow them to search, image, or confiscate your phone, but not evilmaid it or rubberhose you. For some travelers, that's their threat model.
I find it hard to believe they would be able to compel you to unlock your phone but not compel you to unlock an individual app.
What about the server portion? that's the thing I would like to have forked / open source.
Good news! https://github.com/signalapp/Signal-Server
But is there federation between instances of this and the official signal servers?
There will likely never be federation between Signal's official servers and any other servers. Signal introduces privacy features semiregularly; we all saw with Matrix how difficult that is in a highly-federated environment.
No. But iirc Molly can connect to a federated version. You just have to pick. It's one or the other
Well, obviously not. Official Signal does not support federation.
Says it's on F-Droid and it isn't. Search turns up no results
Try scanning the QR-code. It works.
Seems interesting, but are there any screenshots?
it looks just like signal with a purple theme
The Signal discourages the use of Molly.
one more reason to use Molly
That's great news but I just switched to iOS.
So, you still need a phone number? It doesn’t mention anywhere that’s not a requirement
An iOS version would be lovely in the future!
this is great. having a few screenshots would be sweet.
What are the advantages of this?
It supports linking two Android devices.
This is huge. There's been 3rd party Signal library for this for years -- and for some reason I can't determine, the developers have opted NOT to do this.
Yeah, the Signal team's roadmap seems very strange to me as an outsider. There are some low hanging fruits which they just seem to refuse to fix.
And given how in this case Molly could fix it it cannot have been that hard to fix.
this is why molly.im was a lifesaver for me.. trying to move a family member from VIBER to SIGNAL and ran into the annoying roadblock of not being able to link an Android tablet to an Android phone like Viber can - but molly does it fine.
If you use Signal on your Android phone, can you link with Molly on another Android device (tablet) without Signal complaining?
I just tried it on a 2nd phone and it seems to work.
I’ve never trusted signal. Signal desktop does not seem reproducible . It’s not clear to me how its infrastructure is deployed. The servers buffer messages to a large degree
Extra privacy features and named after UK slang for MDMA, hrm.
Molly is the American slang, Mandy is the UK slang for MDMA.
I'd just wish Molly had a live-tracking feature, similar to Telegram-FOSS.
But not sure if even the upstream Signal client has this.
Why would privacy apps have this feature?
to share your location with trusted people when e.g. you are in a dangerous situation.
or to set up a timed SOS signal if you don't disarm it within a given deadline.
https://github.com/mollyim/mollyim-android/blob/285650e38613...
I'm pretty unconvinced that this is a sane or useful thing to do.
Is there a specific part you're referring to? For those of us who don't read or write Java frequently, it's not clear whether it's worth it to spend time reading the code without at least having some sense of whether you might be making a compelling point or not.
You need to be more specific. Lots of security-conscious apps wipe their memory. Memory contains, among other things, the decrypted text and private keys for the app. RAM is known to hold data longer than you'd want, and it can be swapped out onto persistent storage like the internal SSD. If you don't know that wiping memory is a basic and common feature for apps like this, then you're not qualified to have an opinion. Now if you think wiping the memory is ineffective, inefficient, or superceded by a bigger issue, then we might have something to talk about.
Hi
Now we just need to drop the phone number requirements and signal would be "done" for all practical purposes
Phone numbers aren't required now. But there are flaws in Signal. Your phone usage can be tracked in high resolution through constant pinging of malformed status messages. I can't find the paper right now but researchers found that they could track their own data about when the phone was on, unlocked, and had Signal on the screen. That can be correlated between users, to see who is talking to who. It can be used to try to ambush you while the phone is unlocked. You don't even have to have a connection to the spies, if I remember right. Signal devs have done nothing about this issue since being notified like a year ago.
Edit: Found it! "Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers" https://arxiv.org/abs/2411.11194
> Phone numbers aren't required now.
Signal still requires a phone number for registration.
They also require running the app on a "real phone" for registration. Most emulators put you in captcha hell
Damn, what a shame... Another vote for Session, I guess. Idk what flaws that one has but it seems to be the leading alternative to Signal.
Unfortunately...
What is the point of this? Just use the regular signal app. It may be more safe, but are the developers trustworthy enough?
It has various improvements and you can also use your private signal server. I believe it also lets you backup your data! How about that for digital sovereignty.
Signal also lets you backup your data, for a small subscription
Wasn't aware you could run your own signal server. How do you go about setting one up?
Are Signal developers trustworthy enough? What about this push for "cloud backups"? There are other flaws in Signal too like being able to monitor people's phone usage and stuff through the notification system. I can't find it now but Signal and WeChat have the same issues, and both received a disclosure. Only WeChat did anything about it. Sad...
Edit: Found it! "Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers" https://arxiv.org/abs/2411.11194
Can't wait to see how the lawsuit goes. Moxie is infamously protective of Signal.
Moxie hasn't been affiliated with Signal for years. He stepped back years ago.
The Signal Android app is AGPL licensed. What should the lawsuit be about?
Signal used to threaten people for trademark infringement because the word "signal" was in the protocol on the wire.
I think they've relaxed this quite a bit more recently
There is nothing legally stopping people from forking the signal app and distributing it (even configured to talk to the official signal.org servers) so long as they don’t use the Signal trademarks.
Also, as others pointed out, Moxie isn’t part of Signal any longer and hasn’t been for a while.