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.
Wire was able to implement a fully E2E-encrypted messenger with proper multi-device support almost a decade ago, long before it became mainstream. Fully FOSS too, including the server. For some reason it never became popular. They don't have proper desktop clients (just the usual Electron mess), but then, which one of them does except for Telegram?
My memory is really fuzzy, but I recall back when the new IM apps were all coming out and competing for the small share of people wanting to test them, either the Wire app or using the Wire service had a hard cost ($5 USD?) (no free-to-test tier, you had to pay to use). I believe history has shown a vast majority of folks will choose free (even with ads, sadly) over a hard cost for IM. Signal talked a better game and offered everything for free.
I mean, E2E is the entire point of Signal. if you don't think E2E is important then Signal is the wrong app. Personally given the current political climate I think having the technical knowledge to understand what E2E is and not wanting E2E is bonkers. High chance of people getting killed or jailed in the US for mainstream political positions in the near future.
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.
Which is pretty odd as WhatsApp allegedly uses the very same E2E encryption and has no problem implementing a web client. I really don't see the point of Electron if it doesn't allow you to provide a web client.
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.
Why do you need a message history? The only use I can think of, if someone uses it against you in court. I don't remember looking up anything in history.
I look up old iMessages, emails, group chat comments, and so forth constantly, often finding valuable gems of wit, reference-material, recommendations, or media that I dimly remember from years or even decades ago.
Signal and other messaging apps offer a 'search' bar across all sessions & history, so I doubt I'm the only one.
It's hard for me to imagine being so present-focused such a history wouldn't be personally useful.
Or, so worried about "someone [using] it against [me] in court" that I'd need more than the occasional auto-expiration, and specifically my messenger "protecting" me with intermittently-enforced loss-of-histories (on just theft/loss/hard-failure of primary device).
I really hate that the desktop app unlinks after a relatively short period of time. I rarely use Signal, so few of my friends are there, so I have to relink the desktop app almost every time I open it. I wouldn't mind scanning a qr code every now and then, but then the history refuses to sync because security. So far I haven't find how to change it.
The Android app is stable enough, but the UX of having to look at the phone while typing a reply on a normal keyboard is annoying. This is why I prefer Telegram every time.
Anecdotes of occasional problems, even at a low or unquantified rate, are valid & useful evidence that something negative is happening.
Anecdotes that sometimes those problems don't occur are nearly worthless. Of course that's true - the original anecdotal
complaint already implicitly relies on, & grants, the idea that there's some default, "hoped for" ideal from which their experience has fallen short.
To chime in, "never had your problems" thus adds no info. Yes, people lucky enough not to hit those Signal limits that cause others to lose data exist, of course. But how does that testimony help those with problems? Should their frustration be considered less important or credible, because of your luck?
The as-if portrayal is one way your anecdote will be perceived, even if that wasn't your intent.
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.
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.
Maybe you don't believe Durov's statement[0] about it. But is there any actual evidence anywhere that they've ever violated the secrecy of non-e2e private groups or messages for anyone? I've yet to find any.
That wasn’t the original question though. Twitter and Messenger are also untrustworthy. Telegram’s message export is very good compared to all the other options.
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.
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.
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.
In case there are any doubts, consider this code and its description public domain.
But then I'm not sure how much code is enough to be considered copyrightable. Is "2*2" copyrightable? Clearly not, because it's too trivial. Where is the line?
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.
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".
> - 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 :).
You're being pretty disingenuous and we've talked enough over the years for me to know you know you are being too. So why?
> I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification?
No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.
But does Signal comply with government warrants? Yes, absolutely. But they don't get many requests because they designed their program to assume Signal is an adversary to the user[2]
> 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 :).
Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. Over SMS about 10 times a week (though a bit more than half are auto blocked), over phone I get at least 5 calls a week but sometimes I get that in a day, over WhatsApp I get a few a month. So I don't really buy your argument, but I'm only a sample size of one. But I also know there's no technical reason for your argument either. I'm also pretty sure we've had this conversation in the past, so what's up? You're one of the most active HN users[3], you're easy to remember.
>> I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification?
> No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.
Never was a fan of Moxie, and I'm not going to read Twitter backlog right this moment to confirm what Meredith thinks, but my reasoning here is pretty simple: remote attestation and developer verification are tools that enable what Signal seems to want, which is to be its own walled garden with only one app from one official source - this is necessary for them to deliver on the promises of privacy and security they make.
>>> 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 :).
> Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. (...)
Here I meant Telegram, not Signal. I don't get any spam on Signal at all, but then hardly anyone in my circles uses it. WhatsApp, maybe few times a year. Telegram, all the time, and I only keep it because my local Hackerspace moved over to it from IRC, + it's actually useful for some automation here and there.
People have different preferences; not everyone sees privacy from powers that be as the only requirement. I for one care more about my freedom of computing on my own device; I'm not that worried about my shitposting remaining private. I don't like the push for E2EE messaging in its current form, because I see incentives of both megacorps and OSS devs align against my own. I speak up, because messaging is inherently network-effects based, and I don't want to end up in a situation where all communication goes through end-user-opaque black boxes, regardless of whether they're corporate or community-made.
> I'm also pretty sure we've had this conversation in the past, so what's up?
I know your username and remember us having some back-and-forth on various topics, but I don't recall this particular one.
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.
There are a few reasons for that.
1. The link to APK cannot be found on the official site[0], so it needs to be looked up in a search engine.
2. Even when downloading from the site, they try to scare you away with a warning [1]. The reason for warning could be avoided by hosting their own F-droid repo, but they refused it, claiming you can download APK and not listening to reason[2].
Though for people using F-droid can still get Signal through the Guardian repository [3]
Thing about the signal APK and the Guardian one is that, it still have the so called "crap" in the final APK, it just runs a background service when required google services are not detected, causing battery drain for many[4].
The drain could also be avoided by supporting UnifiedPush (it can fall back to FCM when it's detected), but they don't want to do that either[5].
> 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).
$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.
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.
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.
They use the phone to do their person vetting. It helps reduce bots because you have to have phone numbers[0]. It's not perfect but it does create a barrier to entry. That's unfortunately how security works, there's nothing impenetrable, there are only things that make certain things harder. The best security is where something is impracticable, not impossible (e.g. brute forcing a large password is not impossible, but it is impracticable). But at the same time you run into problems like that.
[0] They also use it as a means to help with the social graph. Building a social graph is pretty difficult and you don't want to do it completely from scratch. This is the same reason social media wants you to import your phone contacts and email contacts. The difference is that the "side benefit" to that is that they get data harvesting rather than security.
| > We're unable to provide a specific timeline.
> I'm not sure if it's true, but it feels a bit suspect.
It's because Signal doesn't track metadata. The reason they can't tell you a specific date is that they don't know how to associate your physical name with your Signal account. The information is unavailable to them! Which is the whole point of Signal.
Honestly, the best solution to this would have been to buy a cheap phone or something like a VOIP number. I don't know your situation but it seems like it is not that easy to go a year without a phone number. I definitely think Signal should do better in this but I don't think the result is unreasonable. It brings up an edge case they probably didn't consider but having a phone number "abandoned" for a year sounds like it is a very low probability situation. Being reliant on phone numbers they also have to garbage collect, right? Because a phone number is not a unique identification to a person for their life. So while I do agree your situation sucks and is very frustrating I hope you can recognize that it is (from my best guess) a very unlikely situation. That the phone number is being sat on but unused and that the squatting is happening by a legitimate person rather than a scammer.
They can do better, for sure, but I don't think I'd judge a platform harshly by the results of an extremely odd outlier situation.
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.
> update thats infected by some government trojan?
Or even just a hacker!
Unfortunately you don't. But this is true for ANY app.
Fortunately, Signal is open source. So you can go read the lines of code. Unfortunately this is a lot of work. But fortunately if you believe a certain checkpoint is secure (your current install) you only need to read the new things. You can also build from source if you don't trust the app store.
Fortunately with open source you also get the benefit of others. Maybe you don't look through everything, but there's definitely other people looking through some things. And with something like Signal, you can be pretty certain that there will be a big uproar if something devious is pushed.
You always need trust, unfortunately. But with closed source you have to trust one entity and get no way to verify. With open source you have to trust very few and can even verify yourself.
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.
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.
> 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.
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.
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.
Some of the details might of changed since publication. My current understanding is that Signal doesn't even bring up the idea of identity verification if a user has not previously done it. So if anything, things have gotten worse.
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)
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.
There is no way to use the Signal app on a device without a camera (USB cameras are even explicitly blocked!), and sync it with another computer. I use a Daylight computer as my primary mobile machine, which does not have a camera. The Molly app is the only way I am able to use Signal on multiple devices.
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.
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.
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.
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.
> 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.
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.
I don't think this makes a lot of sense because, if the password is quick and easy to type, it can probably be cracked by any such device in the time it takes for a single keystroke. A long and complex password might hold up okay, but for it to actually be secure, you would have to type in the whole password on a phone keyboard every single time you opened the app, which sounds like a terrible experience.
I think, if you were actually willing to do that, it would probably be about as convenient and at least as effective to leave the device powered off and rely on the device full disk encryption and hardware security to protect the data at rest, only powering it on occasionally to check or send messages, then immediately powering back off.
You do not have to type the whole password every time you open the app, only when the database is locked. You can manually lock from an unlocked state whenever you want, even from other contexts (the button to lock it is available in the background notification) or configure an automatic timeout (which is granular down to the second) to lock the database.
> 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.
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.
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").
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.
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
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
And you can use your Session ID to post or reply to posts at https://www.LokiList.com (best viewed with javascript disabled) for anonymous casual encounters.
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.
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.
"If you wish to use the same phone number for both Molly and Signal, you must register Molly as a linked device. Registering the same number independently on both apps will result in only the most recently registered app staying active, while the other will go offline."
Yeah, pretty sure that's what me and the other comment meant. Linked device, like using Signal on Desktop. Or Signal on iPad. Linking wasn't available on Signal for Android for some reason.
Specifically I'm using Signal as the main device, with Molly as the linked device on 2nd phone.
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
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.
Oracle, Nintendo and Apple have all tried this "copyrighted text / logo / poem" thing, never works out for them. For interoperability you're allowed to replicate those parts.
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.
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.
Wire was able to implement a fully E2E-encrypted messenger with proper multi-device support almost a decade ago, long before it became mainstream. Fully FOSS too, including the server. For some reason it never became popular. They don't have proper desktop clients (just the usual Electron mess), but then, which one of them does except for Telegram?
https://github.com/wireapp/wire-server , etc.
My memory is really fuzzy, but I recall back when the new IM apps were all coming out and competing for the small share of people wanting to test them, either the Wire app or using the Wire service had a hard cost ($5 USD?) (no free-to-test tier, you had to pay to use). I believe history has shown a vast majority of folks will choose free (even with ads, sadly) over a hard cost for IM. Signal talked a better game and offered everything for free.
I moved all my friends to Wire about a decade ago. Pretty, but the actual user experience was awful. We moved to Telegram and since then to Signal.
I didn't actually know Wire was FOSS.
How do they handle message recovery when all your devices have been lost (and possibly when you've forgotten your password)?
That's (almost) incompatible with E2E encryption. You could do it via "social proof" or server-side secure enclaves and pins, but that's about it.
Who cares? this stuff is all ephemeral messaging. People frequently don't have and can't find them if they do, even absent any security.
Maybe in google profile backup, where all your data is stored.
Why would they need history of their shitposts? It loses actuality in a day, maximum in a week.
This is correct and applies to security in general. Security is one facet of reliability.
I mean, E2E is the entire point of Signal. if you don't think E2E is important then Signal is the wrong app. Personally given the current political climate I think having the technical knowledge to understand what E2E is and not wanting E2E is bonkers. High chance of people getting killed or jailed in the US for mainstream political positions in the near future.
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.
Which is pretty odd as WhatsApp allegedly uses the very same E2E encryption and has no problem implementing a web client. I really don't see the point of Electron if it doesn't allow you to provide a web client.
> Which is pretty odd
I have always assumed no Signal web client was a choice made to improve security.
It’s easier to make cross platform?
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.
If the device with an 18GB message history was truly 'dead', how did you transfer the history over?
Why do you need a message history? The only use I can think of, if someone uses it against you in court. I don't remember looking up anything in history.
I look up old iMessages, emails, group chat comments, and so forth constantly, often finding valuable gems of wit, reference-material, recommendations, or media that I dimly remember from years or even decades ago.
Signal and other messaging apps offer a 'search' bar across all sessions & history, so I doubt I'm the only one.
It's hard for me to imagine being so present-focused such a history wouldn't be personally useful.
Or, so worried about "someone [using] it against [me] in court" that I'd need more than the occasional auto-expiration, and specifically my messenger "protecting" me with intermittently-enforced loss-of-histories (on just theft/loss/hard-failure of primary device).
Because of family phonos shared between me an my siblings, and between me and my wife.
All our communication is over signal, so it is a nice record to have.
[dead]
I've been using it since it was called TextSecure.
I had no issues at all since it's called Signal. I have no idea what people do with it to cause problems at all.
It would still be interesting to find out.
I've been on Android only btw.
I really hate that the desktop app unlinks after a relatively short period of time. I rarely use Signal, so few of my friends are there, so I have to relink the desktop app almost every time I open it. I wouldn't mind scanning a qr code every now and then, but then the history refuses to sync because security. So far I haven't find how to change it.
The Android app is stable enough, but the UX of having to look at the phone while typing a reply on a normal keyboard is annoying. This is why I prefer Telegram every time.
I've got Signal on 2 computers, 1 of which I only run it occasionally. I've never had to reconnect it.
I'm not sure what's going on for you, but it seems really abnormal.
It automatically unlinks the desktop app if you don't open it for 30 days.
There is now at least a reminder on the phone app that will prompt you a few days before one of your desktop apps is about to get unlinked.
I wouldn't call 30 days "a short period of time"...If I hadn't used it for 30days, I'd uninstall it.
"I've been lucky not to have devices lost/stolen/bricked. Why can't other people just be lucky like me?"
The comment I replied to was providing annecdata about a bad experience. I was doing the opposite, to balance.
Your portrayal of my comment is not even close.
Anecdotes of occasional problems, even at a low or unquantified rate, are valid & useful evidence that something negative is happening.
Anecdotes that sometimes those problems don't occur are nearly worthless. Of course that's true - the original anecdotal complaint already implicitly relies on, & grants, the idea that there's some default, "hoped for" ideal from which their experience has fallen short.
To chime in, "never had your problems" thus adds no info. Yes, people lucky enough not to hit those Signal limits that cause others to lose data exist, of course. But how does that testimony help those with problems? Should their frustration be considered less important or credible, because of your luck?
The as-if portrayal is one way your anecdote will be perceived, even if that wasn't your intent.
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.
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.
Oh, I agree. it's just, they mentioned things like Twitter DM, Messenger and forgot Telegram...
Exactly what "rolling over" would that be?
Maybe you don't believe Durov's statement[0] about it. But is there any actual evidence anywhere that they've ever violated the secrecy of non-e2e private groups or messages for anyone? I've yet to find any.
[0] https://t.me/durov/342
That wasn’t the original question though. Twitter and Messenger are also untrustworthy. Telegram’s message export is very good compared to all the other options.
+1 for Deltachat
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.
SMS works just fine for me, but international calling is a killer, it's 2025 you would think this would be free by now.
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.
I haven't dropped molly for a long time. But it feels like the right thing here.
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
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.
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.
This is also what UnifiedPush lib to use FCM does (https://codeberg.org/UnifiedPush/android-embedded_fcm_distri...)
Which is documented in this gist: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...
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.
Here is a blog post to use the play services, without the proprietary lib and API: https://unifiedpush.org/news/20250131_push_for_decentralized...
And there is this gist for the app side, if you need something to share: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...
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.
In case there are any doubts, consider this code and its description public domain.
But then I'm not sure how much code is enough to be considered copyrightable. Is "2*2" copyrightable? Clearly not, because it's too trivial. Where is the line?
A long standing question, I think Joel mentioned such a question once on the Stackoverflow blog.
Thanks, Grishka.
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.
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.
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".
> 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
> - 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 :).
You can't send messages on WhatsApp w/o giving Meta read access to all of your contacts. Nice of you to give up your friends.
You're being pretty disingenuous and we've talked enough over the years for me to know you know you are being too. So why?
No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.But does Signal comply with government warrants? Yes, absolutely. But they don't get many requests because they designed their program to assume Signal is an adversary to the user[2]
Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. Over SMS about 10 times a week (though a bit more than half are auto blocked), over phone I get at least 5 calls a week but sometimes I get that in a day, over WhatsApp I get a few a month. So I don't really buy your argument, but I'm only a sample size of one. But I also know there's no technical reason for your argument either. I'm also pretty sure we've had this conversation in the past, so what's up? You're one of the most active HN users[3], you're easy to remember.[0] https://signal.org/blog/uk-online-safety-bill/
[1] https://x.com/mer__edith
[2] https://signal.org/bigbrother/
[3] For anyone interested https://news.ycombinator.com/leaders
>> I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification?
> No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.
Never was a fan of Moxie, and I'm not going to read Twitter backlog right this moment to confirm what Meredith thinks, but my reasoning here is pretty simple: remote attestation and developer verification are tools that enable what Signal seems to want, which is to be its own walled garden with only one app from one official source - this is necessary for them to deliver on the promises of privacy and security they make.
>>> 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 :).
> Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. (...)
Here I meant Telegram, not Signal. I don't get any spam on Signal at all, but then hardly anyone in my circles uses it. WhatsApp, maybe few times a year. Telegram, all the time, and I only keep it because my local Hackerspace moved over to it from IRC, + it's actually useful for some automation here and there.
People have different preferences; not everyone sees privacy from powers that be as the only requirement. I for one care more about my freedom of computing on my own device; I'm not that worried about my shitposting remaining private. I don't like the push for E2EE messaging in its current form, because I see incentives of both megacorps and OSS devs align against my own. I speak up, because messaging is inherently network-effects based, and I don't want to end up in a situation where all communication goes through end-user-opaque black boxes, regardless of whether they're corporate or community-made.
> I'm also pretty sure we've had this conversation in the past, so what's up?
I know your username and remember us having some back-and-forth on various topics, but I don't recall this particular one.
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/
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.
There are a few reasons for that.
1. The link to APK cannot be found on the official site[0], so it needs to be looked up in a search engine.
2. Even when downloading from the site, they try to scare you away with a warning [1]. The reason for warning could be avoided by hosting their own F-droid repo, but they refused it, claiming you can download APK and not listening to reason[2].
Though for people using F-droid can still get Signal through the Guardian repository [3]
Thing about the signal APK and the Guardian one is that, it still have the so called "crap" in the final APK, it just runs a background service when required google services are not detected, causing battery drain for many[4].
The drain could also be avoided by supporting UnifiedPush (it can fall back to FCM when it's detected), but they don't want to do that either[5].
[0] https://signal.org/download/
[1] https://signal.org/android/apk/
[2] https://community.signalusers.org/t/how-to-get-signal-apks-o...
[3] https://guardianproject.info/fdroid/
[4] https://github.com/signalapp/Signal-Android/issues/9729
[5] https://community.signalusers.org/t/use-gcm-fcm-alternatives...
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
That's not enough.
The killer feature for me is that molly-im also supports UnifiedPush for notifications instead of just websocket and FCM like upstream Signal.
There is also a signal build in the fdroid repo of the Guardian Project
"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).
which is easily enabled in f-droid: settings > repositories > toggle it on
Didn’t know this was in there, thanks!
Good to know - that would make my life a little easier.
$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 server certifies public key of your contact. How many times have you verified security numbers of your contacts?
Two questions:
* 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.
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.
Let's not forget not releasing the server software for several years.
If so they are certainly doing it ambitiously by fixing longstanding issues in Signal.
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.
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.That change log for android sucks - the same content for 20 releases or so...
You'll need to trawl through the actual commits it appears: https://github.com/signalapp/Signal-Android/commits/main/
Yes BUT I ALSO SAID
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.
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.
They use the phone to do their person vetting. It helps reduce bots because you have to have phone numbers[0]. It's not perfect but it does create a barrier to entry. That's unfortunately how security works, there's nothing impenetrable, there are only things that make certain things harder. The best security is where something is impracticable, not impossible (e.g. brute forcing a large password is not impossible, but it is impracticable). But at the same time you run into problems like that.
[0] They also use it as a means to help with the social graph. Building a social graph is pretty difficult and you don't want to do it completely from scratch. This is the same reason social media wants you to import your phone contacts and email contacts. The difference is that the "side benefit" to that is that they get data harvesting rather than security.
It's because Signal doesn't track metadata. The reason they can't tell you a specific date is that they don't know how to associate your physical name with your Signal account. The information is unavailable to them! Which is the whole point of Signal.Honestly, the best solution to this would have been to buy a cheap phone or something like a VOIP number. I don't know your situation but it seems like it is not that easy to go a year without a phone number. I definitely think Signal should do better in this but I don't think the result is unreasonable. It brings up an edge case they probably didn't consider but having a phone number "abandoned" for a year sounds like it is a very low probability situation. Being reliant on phone numbers they also have to garbage collect, right? Because a phone number is not a unique identification to a person for their life. So while I do agree your situation sucks and is very frustrating I hope you can recognize that it is (from my best guess) a very unlikely situation. That the phone number is being sat on but unused and that the squatting is happening by a legitimate person rather than a scammer.
They can do better, for sure, but I don't think I'd judge a platform harshly by the results of an extremely odd outlier situation.
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.
Unfortunately you don't. But this is true for ANY app.
Fortunately, Signal is open source. So you can go read the lines of code. Unfortunately this is a lot of work. But fortunately if you believe a certain checkpoint is secure (your current install) you only need to read the new things. You can also build from source if you don't trust the app store.
Fortunately with open source you also get the benefit of others. Maybe you don't look through everything, but there's definitely other people looking through some things. And with something like Signal, you can be pretty certain that there will be a big uproar if something devious is pushed.
You always need trust, unfortunately. But with closed source you have to trust one entity and get no way to verify. With open source you have to trust very few and can even verify yourself.
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.
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.
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.
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.
Is this the 2025 equivalent of "give me your IP address"? LOL.
Age/SecuritySkills/Location
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.
Any reference to the trivial mitm attacks which signal has suffered?
This is mostly about the usability issues that make such attacks work so well on Signal:
https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
This adds some detail about how Signal can do MITM attacks:
https://sequoia-pgp.org/blog/2021/06/28/202106-hey-signal-gr...
Some of the details might of changed since publication. My current understanding is that Signal doesn't even bring up the idea of identity verification if a user has not previously done it. So if anything, things have gotten worse.
PGP/GNUPG has worked well for me for nearly three decades.
You're running 2005 versions of your mail-daemon in prod?
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/
> 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.
f-droid ships libre software only.
3rd party repositories ship whatever.
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)
For apps i do install from f-droid repos (official or otherwise) i prefer https://github.com/Droid-ify/client
supply trust chain and GrapheneOS in the same sentence?
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.
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.
No, Matrix privacy is in no way comparable with signal.
There is no way to use the Signal app on a device without a camera (USB cameras are even explicitly blocked!), and sync it with another computer. I use a Daylight computer as my primary mobile machine, which does not have a camera. The Molly app is the only way I am able to use Signal on multiple devices.
Whaaat? Signal on Linux working here; no video stream nor camera device installed.
On Linux and what?
I use Signal on Linux, and Molly on my tablet. The issue I ran into was in trying to use Signal on both.
Debian and Gentoo
But Molly still cannot use UnifiedPush if you use multiple devices. So it is still dependent on proprietary google push services.
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.
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
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.
Well, obviously not. Official Signal does not support federation.
No. But iirc Molly can connect to a federated version. You just have to pick. It's one or the other
> 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.
[dead]
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.
> 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.
> 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.
Isn't the phone filesystem encrypted?
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.
I don't think this makes a lot of sense because, if the password is quick and easy to type, it can probably be cracked by any such device in the time it takes for a single keystroke. A long and complex password might hold up okay, but for it to actually be secure, you would have to type in the whole password on a phone keyboard every single time you opened the app, which sounds like a terrible experience.
I think, if you were actually willing to do that, it would probably be about as convenient and at least as effective to leave the device powered off and rely on the device full disk encryption and hardware security to protect the data at rest, only powering it on occasionally to check or send messages, then immediately powering back off.
You do not have to type the whole password every time you open the app, only when the database is locked. You can manually lock from an unlocked state whenever you want, even from other contexts (the button to lock it is available in the background notification) or configure an automatic timeout (which is granular down to the second) to lock the database.
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.
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.
Cellbrite exists...
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").
Just installed it, it looks exactly the same, just a bit more purple theme
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.
[dead]
Came here to comment exactly this. Even opened github expecting to see something...
So, you still need a phone number? It doesn’t mention anywhere that’s not a requirement
I don't want a new chat app, I want an unified protocol and bring my own client
Seems interesting, but are there any screenshots?
it looks just like signal with a purple theme
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.
The name immediately makes me think of 1990s raves, since it’s a nickname for ecstasy (the drug). I guess that’s a generational thing.
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
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 make it easy to meet friends/family in crowded places
Its not permanent, you just enable it for a few minutes until you find each other
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.
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.
And you can use your Session ID to post or reply to posts at https://www.LokiList.com (best viewed with javascript disabled) for anonymous casual encounters.
Unfortunately...
For very limited practical purposes. Others would include proper multi device support
Says it's on F-Droid and it isn't. Search turns up no results
It's in a third party repo that you need to add first
Try scanning the QR-code. It works.
What are the advantages of this?
It supports linking two Android devices.
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.
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.
[dead]
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 got logged out of Signal after setting up Molly
Now reading this on the GitHub page:
"If you wish to use the same phone number for both Molly and Signal, you must register Molly as a linked device. Registering the same number independently on both apps will result in only the most recently registered app staying active, while the other will go offline."
Yeah, pretty sure that's what me and the other comment meant. Linked device, like using Signal on Desktop. Or Signal on iPad. Linking wasn't available on Signal for Android for some reason.
Specifically I'm using Signal as the main device, with Molly as the linked device on 2nd phone.
The fact that Signal gets bad publicity or "improved" alternatives pop up tells me that they are a real threat to the mainstream apps.
That's great news but I just switched to iOS.
The Signal discourages the use of Molly.
one more reason to use Molly
An iOS version would be lovely in the future!
this is great. having a few screenshots would be sweet.
Extra privacy features and named after UK slang for MDMA, hrm.
Molly is the American slang, Mandy is the UK slang for MDMA.
What is the point of this? Just use the regular signal app. It may be more safe, but are the developers trustworthy enough?
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
[dead]
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
No, it won't let me backup my data. It lets them backup my data and I still cannot access it outside of the Signal app.
Wasn't aware you could run your own signal server. How do you go about setting one up?
[dead]
[dead]
[flagged]
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
Oracle, Nintendo and Apple have all tried this "copyrighted text / logo / poem" thing, never works out for them. For interoperability you're allowed to replicate those parts.
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.