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.
Because everybody (except Telegram funnily enough) is prioritizing security over user convenience.
Most apps on the market are E2E by default these days, and that introduces a whole host of complications. It's the wrong tradeoff for 95+ percent of users. If you can only afford 1 device and only switch to a new one when the old device breaks, E2E is a disaster in the making. For the overwhelming majority of users, making sure that they have access to their messages when they switch devices is far more important than being protected from the NSA. This is something most signal advocates are completely unwilling to talk about.
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.
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.
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.
>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.
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.
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.
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".
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.
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).
$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.
* Do you not trust the Signal Organisation? They've aren't able to subvert their encryption on the servers, and have publicly stated that they will leave a region before integrating client-side scanning. I for one believe them, since it's their raison d'être.
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.
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.
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.
No, and I don't want to rely on f-droid for anything important due to their shoddy security practices (+ as a sibling comment says there's no official signal binaries on fdroid)
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).
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.
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.
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.
Readit News
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.
Most apps on the market are E2E by default these days, and that introduces a whole host of complications. It's the wrong tradeoff for 95+ percent of users. If you can only afford 1 device and only switch to a new one when the old device breaks, E2E is a disaster in the making. For the overwhelming majority of users, making sure that they have access to their messages when they switch devices is far more important than being protected from the NSA. This is something most signal advocates are completely unwilling to talk about.
[1] https://gitlab.com/whisperfish/whisperfish
[2] https://github.com/whisperfish/presage
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.
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.
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.
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.
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.
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
Also a great point :) And thank you for the reference.
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".
Happy user for many years now, thanks for the support!
https://signal.org/android/apk/
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).
Deleted Comment
Deleted Comment
- 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.
* Do you know of anything better?
* Do you not trust the Signal Organisation? They've aren't able to subvert their encryption on the servers, and have publicly stated that they will leave a region before integrating client-side scanning. I for one believe them, since it's their raison d'être.
/s
But these alternatives are all niches compared to Signal. Which is to say something considering that Signal itself is a niche compared to Whatsapp.
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/
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.
3rd party repositories ship whatever.
For apps i do install from f-droid repos (official or otherwise) i prefer https://github.com/Droid-ify/client
AFAIK signal only blocks due to security patches. Which it's on a much longer timeframe than a few weeks.
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.
Deleted Comment
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.