The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effectively. Building Signal isn't exactly straightforward (just due to Android/iOS crud). We need something like build attestation from reproducible builds to be extendable to slightly different source codes.
Other than that, love it. Now to add iOS backups and cross platform imports... And strip out gifs (or at least make them disabled for me). And force by default unknown callers to go via a relay...
So many wishlist items which are probably wasted effort because they will bit rot without being accepted by Signal.
does signal not accept pull requests or something? currently there's two signal forks on the frontpage, would be much better to upstream the effort if that's viable
>The main problem with projects like these is that I don't know (without manually checking myself) whether they are actually tracking the Signal source code effectively.
That's my main complaint with Signal - lots of widgets. More code to audit and keep an eye on.
Signal is my go-to messenger. I use it exclusively, and have advocated others to move to it. There are many sore points with Signal that are well known, but Molly has pointed out a significant one.
I simply do not trust the OS exclusively to keep the messages secure at rest. The fact that I could use a passphrase, swipe pattern, or other mechanism to encrypt the database separately from Android was a boon, and I'm greatly saddened that they have removed that feature.
Perhaps a second layer of encryption doesn't really matter all that much. If Android's security is as bad as I think it is, then a second layer might just amount to security by obscurity. But it's the principle of things.
angry_octet raises an excellent point. I wish this would return as a mainstream feature.
From what I understand, Signal messages should really only be considered encrypted in flight. At either end the massage could be picked up by an insecure device (custom keyboard, keylogger, screenshots, etc.), and a determined hacker will be able to compromise any casual user’s phone.
Still, there’s value in encrypting in-flight messages.
I'm super curious if someone can explain the threat model here in more detail. Some of these mitigations seem reasonable, some reasonable-but-very-esoteric, some mostly unreasonable. But maybe I am misunderstanding.
Going through the feature list:
> Protects database with passphrase encryption
Modern Android supports FDE, so this seems like it's no gain for most cases. For users who don't have FDE, I guess it makes sense as long as you aren't concerned about evil maid attacks?
(FWIW, Signal's philosophy—here and on RAM protections—seems to be that this is the province of the host OS. I agree!)
> Locks down the app automatically after you go a certain time without unlocking your device
I don't know what this means—is it the below (i.e. purging decryption keys from RAM on inactivity) or something else?
> Securely shreds sensitive data from RAM
The threat model here seems to be malicious code that can read the device's RAM.
I think it's best to leave these kinds of mitigations to the host OS (i.e., if there is malicious code that can read your RAM, you're _probably_ SOL), but I guess there are probably some attacks (e.g. hardware or local-device attacks) that can dump RAM or something? What are common examples?
> Allows you to delete contacts and stop sharing your profile
> Clears call notifications together with expiring messages
> Disables debug logs
Molly dev here. For security, the app is helpful in case the device is stolen or searched. In short, it tries to defeat smartphone forensics.
The scenario is that someone grab the device and wants to read the chats, contacts, or access any information stored in the app. And you realize or suspect that. For example, because you lost the phone, or because it was left out of sight in an unsafe place.
Under the big assumption that the device was clean of malware when Molly was locked there are no technical means to access the data without the password. This is the goal. If there was any security guarantee it would be this one.
When Molly is locked, the database is closed, and the only way to open it again is by entering the password. While locked, the app cannot display notifications. I guess this is the main blocker why Signal has not implemented password encryption yet. I have some ideas to fix this in a secure way, but it would require to modify all Signal clients not just Molly.
To lock the app, there are two options. Either you tap "lock" in the menu, or you set up a timeout. This timer starts counting down with the Android screen lock. Therefore, it should be adjusted by considering the time you expect an attacker could bypass the Android lock screen, and gain root access to the device, and the period of time you want to be able to receive notifications. There are more lock triggers in the roadmap, like the action of connecting an USB cable... many exploits works through USB.
I agree that in a perfect world with zero vulns, all this should be handled by the OS. But even that, there are use cases for Molly. Should your fingerprints or a weak pattern give access to everything stored in your phone? Let me tell you someone's else analogy, "The keys to my front door shouldn’t also unlock my safe. You can rifle through my cutlery, but not my banking records."
It seem like this is a form of layered defence. Android FDE should take care of this use case, but if there is some widespread flaw in Android disk encryption then this would be another layer that attackers would have to penetrate.
Most chat servers simply know who contacts whom. This is an inherent problem (or strategic advantage) in being a chat server. Signal tries to hide the information from themselves by using Intel SGX. So, while SGX may not be perfect, its better than nothing.
why cannot signal foss server be built to be installed like any other sane service on a server and apps that just support custom urls? its not rocket science
The main signal developer (Moxie Marlinspike) is strongly against this architecture and won't accept either 3rd-party apps using the Signal servers, nor the main Signal client using 3rd-party servers.
[+] [-] angry_octet|5 years ago|reply
Other than that, love it. Now to add iOS backups and cross platform imports... And strip out gifs (or at least make them disabled for me). And force by default unknown callers to go via a relay...
So many wishlist items which are probably wasted effort because they will bit rot without being accepted by Signal.
[+] [-] asddubs|5 years ago|reply
[+] [-] Strongylodon|5 years ago|reply
That's my main complaint with Signal - lots of widgets. More code to audit and keep an eye on.
More users is good, but stickers and stuff.. meh.
Maybe teach zoomers how to use emoticons ;-)
[+] [-] antpls|5 years ago|reply
I didn't try, but I don't see how it could be more straightforward than just launching a docker container
[+] [-] bjt2n3904|5 years ago|reply
I simply do not trust the OS exclusively to keep the messages secure at rest. The fact that I could use a passphrase, swipe pattern, or other mechanism to encrypt the database separately from Android was a boon, and I'm greatly saddened that they have removed that feature.
Perhaps a second layer of encryption doesn't really matter all that much. If Android's security is as bad as I think it is, then a second layer might just amount to security by obscurity. But it's the principle of things.
angry_octet raises an excellent point. I wish this would return as a mainstream feature.
[+] [-] faitswulff|5 years ago|reply
Still, there’s value in encrypting in-flight messages.
[+] [-] md_|5 years ago|reply
Going through the feature list:
> Protects database with passphrase encryption
Modern Android supports FDE, so this seems like it's no gain for most cases. For users who don't have FDE, I guess it makes sense as long as you aren't concerned about evil maid attacks?
(FWIW, Signal's philosophy—here and on RAM protections—seems to be that this is the province of the host OS. I agree!)
> Locks down the app automatically after you go a certain time without unlocking your device
I don't know what this means—is it the below (i.e. purging decryption keys from RAM on inactivity) or something else?
> Securely shreds sensitive data from RAM
The threat model here seems to be malicious code that can read the device's RAM.
I think it's best to leave these kinds of mitigations to the host OS (i.e., if there is malicious code that can read your RAM, you're _probably_ SOL), but I guess there are probably some attacks (e.g. hardware or local-device attacks) that can dump RAM or something? What are common examples?
> Allows you to delete contacts and stop sharing your profile > Clears call notifications together with expiring messages > Disables debug logs
[+] [-] valldrac|5 years ago|reply
The scenario is that someone grab the device and wants to read the chats, contacts, or access any information stored in the app. And you realize or suspect that. For example, because you lost the phone, or because it was left out of sight in an unsafe place.
Under the big assumption that the device was clean of malware when Molly was locked there are no technical means to access the data without the password. This is the goal. If there was any security guarantee it would be this one.
When Molly is locked, the database is closed, and the only way to open it again is by entering the password. While locked, the app cannot display notifications. I guess this is the main blocker why Signal has not implemented password encryption yet. I have some ideas to fix this in a secure way, but it would require to modify all Signal clients not just Molly.
To lock the app, there are two options. Either you tap "lock" in the menu, or you set up a timeout. This timer starts counting down with the Android screen lock. Therefore, it should be adjusted by considering the time you expect an attacker could bypass the Android lock screen, and gain root access to the device, and the period of time you want to be able to receive notifications. There are more lock triggers in the roadmap, like the action of connecting an USB cable... many exploits works through USB.
I agree that in a perfect world with zero vulns, all this should be handled by the OS. But even that, there are use cases for Molly. Should your fingerprints or a weak pattern give access to everything stored in your phone? Let me tell you someone's else analogy, "The keys to my front door shouldn’t also unlock my safe. You can rifle through my cutlery, but not my banking records."
[+] [-] rkangel|5 years ago|reply
[+] [-] kitkat_new|5 years ago|reply
[+] [-] jayp1418|5 years ago|reply
[+] [-] jerry1979|5 years ago|reply
[+] [-] blendergeek|5 years ago|reply
[+] [-] 2Gkashmiri|5 years ago|reply
[+] [-] lucideer|5 years ago|reply
[+] [-] spuz|5 years ago|reply
[+] [-] gergely|5 years ago|reply