Notify even if Molly is locked

[muellerto]

Is there an existing request for this?

• [X] I have searched the existing issues

Feature description

From time to time my Molly instance gets locked. Then I have to specify my password to unlock it. OK, I must not use this password but I do, it's a propagated feature.

The problem with this locking mechanism is that Molly seems to be rather dead when it's locked. You get messages on and on and don't even notice it at all. Others send you e-mails asking if everything is OK, and you must answer, yes, all good, but my Molly was locked. This is not good: a messenger who stealthy excludes himself from communication.

So my suggestion is: When Molly is locked

• it should still beep with every new message and
• it should at last show a permanent notification telling that there are messages.

Another good idea would be to have a permanent notification while Molly is locked but not while Molly is unlocked because the first case leads to communication problems and the user must solve this manually, the second case is quite normal.

I had this two times now.

BTW: an open question is also why this self locking must be. What gets better this way? Where is more security or privacy when the user must specify his password again and again? (And also the damned PIN when you don't switch this finally off.) The user wants to receive and send messages, 24x7, and rather not to satisfy the special needs of the app he uses.

[HyperCriSiS]

I am considering moving to molly but I would prefer unlocking with biometrics. Is this possible?

[matchboxbananasynergy]

Notifications with a locked database are already implemented, but only when using FCM or UP for notifications, not websockets.

[muellerto]

Notifications with a locked database are already implemented, but only when using FCM or UP for notifications, not websockets.

I use just the ordinary Molly-FOSS.

But, hey, when you have a feature which disables notifications in a build configuration you shouldn't offer it this way. At last you should inform the user that this will happen from time to time, so he can have an eye on that.

Just did an update to 6.44 from today, result: locked again. So I unlocked it now the second time on a single day.

[BHydden]

You don't have to use the database lock feature if you don't like it. Just go into Settings > Privacy and turn off database encryption or increase the device lockout timer to a period you're likely to use the phone within.

[BHydden]

I am considering moving to molly but I would prefer unlocking with biometrics. Is this possible?

Not for the full database encryption, but if you set it up well you only need to do that once per phone reboot.

You can use biometrics to open the app regularly though if you wish

[genericusername87]

I am considering moving to molly but I would prefer unlocking with biometrics. Is this possible?

Not for the full database encryption, but if you set it up well you only need to do that once per phone reboot.

You can use biometrics to open the app regularly though if you wish

You could also save the password for the molly database in a password manager which supports autofill and biometric unlocking.

[easthvan]

I am considering moving to molly but I would prefer unlocking with biometrics. Is this possible?

Not for the full database encryption, but if you set it up well you only need to do that once per phone reboot.

You can use biometrics to open the app regularly though if you wish

You could also save the password for the molly database in a password manager which supports autofill and biometric unlocking.

Why isn't the passphrase saved to TPM like SimpleX does it? This way the phone lock can get the key from the TPM when the user opens the client. Also. I disabled auto lock but set password for database but the client still locks the database randomly and I do not get notifications for days! It's quite bad as it is now.

[valldrac]

Why isn't the passphrase saved to TPM like SimpleX does it? This way the phone lock can get the key from the TPM when the user opens the client.

Molly always uses the TPM to encrypt the database, even if the passphrase is disabled. The passphrase encryption is an extra layer of security beyond what apps like SimpleX provide. If you don't need this extra layer on top of TPM, just skip the passphrase.

[easthvan]

Thanks for this explanation!

Three of us in the family and one of my business partner were all hating this feature as it was frustrating, annoying because even if auto lock is disabled, the app locks it's database and stops receiving notifications for days... I was wondering too whether this pass is for TPM save or not.. now I'm freely disabling it than

[muellerto]

That this case is closed now is not good at all since the current behavior is really frustrating. The consequence is not to use this feature or not to use the entire app. But this behavior is still there. And still people will stumble upon it. And still people are getting frustrated.

I can't imagine that notifying about the locked state is that complicated. Ten thousands of apps notify about every damned crap. But a really important information about a breakdown of the entire app cannot be shown. At last the user should be informed that this can happen when he uses this feature and he has such a version of Molly which can't notify when it's locked. This information can be given in a message box or whatever, a very simple thing.

OK, case closed, it's your app.

[valldrac]

The passphrase lock is designed to protect Molly's user data, assuming the phone's security has been completely compromised. So, if the app could receive, decrypt, and read messages to show notifications without needing your passphrase, then any attacker who controls the phone could also do the same.

The cool thing about a passphrase lock is that even if all the security fails, your data will still be protected with strong encryption resistant to dictionary attacks. But, of course, you need to realize if your device has been compromised (like, if it was seized), and avoid entering the passphrase never again in that case.

Currently, you can get notifications via FCM or UnifiedPush while Molly is locked because the Signal Server sends a ping to the app using a 3rd-party service, like Google or your chosen UnifiedPush provider. That's why the notification you receive is generic, saying "You may have a message". Molly simply acknowledges this ping and shows the generic notification. This process doesn't require accessing user data, or authenticating to the server, so you don't need to provide your passphrase. Unfortunately, implementing this with Websockets isn't feasible at the moment.

If you're curious about how those other hundreds of apps handle it, I can tell you. Essentially, they either leak metadata to their push notification providers, or they cache user secrets in their device's memory, which leaves them vulnerable if someone manages to hack the phone while the app is capable of displaying notifications (in AFU lock state). You could say Android security is decent for safeguarding this cache, but like any system, it's still prone to vulnerabilities and exploits. That's why this passphrase feature exists - to prevent those scenarios.

Hope that clears up what's behind this feature.

We're planning to fix the documentation to explain all this stuff and more that leads to misunderstandings. Just asking for a bit of patience.

[easthvan]

The passphrase lock is designed to protect Molly's user data, assuming the phone's security has been completely compromised. So, if the app could receive, decrypt, and read messages to show notifications without needing your passphrase, then any attacker who controls the phone could also do the same.

The cool thing about a passphrase lock is that even if all the security fails, your data will still be protected with strong encryption resistant to dictionary attacks. But, of course, you need to realize if your device has been compromised (like, if it was seized), and avoid entering the passphrase never again in that case.

Currently, you can get notifications via FCM or UnifiedPush while Molly is locked because the Signal Server sends a ping to the app using a 3rd-party service, like Google or your chosen UnifiedPush provider. That's why the notification you receive is generic, saying "You may have a message". Molly simply acknowledges this ping and shows the generic notification. This process doesn't require accessing user data, or authenticating to the server, so you don't need to provide your passphrase. Unfortunately, implementing this with Websockets isn't feasible at the moment.

If you're curious about how those other hundreds of apps handle it, I can tell you. Essentially, they either leak metadata to their push notification providers, or they cache user secrets in their device's memory, which leaves them vulnerable if someone manages to hack the phone while the app is capable of displaying notifications (in AFU lock state). You could say Android security is decent for safeguarding this cache, but like any system, it's still prone to vulnerabilities and exploits. That's why this passphrase feature exists - to prevent those scenarios.

Hope that clears up what's behind this feature.

We're planning to fix the documentation to explain all this stuff and more that leads to misunderstandings. Just asking for a bit of patience.

Thanks! 🙏

But we my Molly on stock P7 auto locks when the auto lock is OFF? After like a day or so or locks the db and you don't realize it it just after days... it cases frustration and lost communication with contacts and not only for me but two of my contacts complain this. You gotta do some change, maybe some auto reminders when it locked! Please place an always there silent notification in the status bar with a symbol on top as well when it's LOCKED!

[valldrac]

But we my Molly on stock P7 auto locks when the auto lock is OFF?

Sometimes Molly have bugs that make it crash, which causes Molly to lock. We're working on fixing this issue. It could also happen if you switch to another user profile in Android.

It would really help if we could identify and clear these bugs, so please share the debug log when happen to you. You can find the log in Settings > Help.

[easthvan]

Regardless of this please put a default state notification in the status bar when the lock is engaged so that the user see when it's locked

[muellerto]

Regardless of this please put a default state notification in the status bar when the lock is engaged so that the user see when it's locked

Yes, yesterday you gave me a thumb down but THIS is exactly what I wanted, nothing else.

[muellerto]

The passphrase lock is designed to protect Molly's user data, assuming the phone's security has been completely compromised.

First of all, thanks a lot for the explanation. Put this post onto your website.

But your first sentence contains also a part of the problem: "assuming the phone's security has been completely compromised." Privacy is good and needed, I welcome features supporting this a lot. But it should not handicap you. Look, my device gets 12 OS updates per year always followed by a reboot. Molly gets 12 updates per year, so Molly will be restarted 12 times. So I have 24 planned situations where the database gets locked. I also reboot my device from time to time manually because of other reasons, so after all I have a locked database about 40 or 50 times a year. And every single time Molly is then dead and I must recognize this myself. - In the last 14 years I owned a smart phone I never had a problem like "has been completely compromised". This doesn't mean that it can't happen in the next hour, not at all, but it means that the chances are very different. A reboot or restart of the app is hundreds of times more probably than any attack.

Currently, you can get notifications via FCM or UnifiedPush while Molly is locked because the Signal Server sends a ping to the app using a 3rd-party service, like Google or your chosen UnifiedPush provider. That's why the notification you receive is generic, saying "You may have a message". Molly simply acknowledges this ping and shows the generic notification. This process doesn't require accessing user data, or authenticating to the server, so you don't need to provide your passphrase. Unfortunately, implementing this with Websockets isn't feasible at the moment.

Idea: there could be a second headless app which provides a notification as long as Molly's database is locked. This app could be installed as "addon" for people who use just Molly FOSS, I would do this. When Molly's database gets unlocked this app terminates and Molly acts as normal. Note: there's no real need for notifications about received messages (would be nice but is not a must). There's only one static text really needed which says "Molly is locked." This is the important missing information. This app must not know anything about what's in the database, it must only know the current lock state.

[valldrac]

And every single time Molly is then dead

There have been more crashes lately, mainly because Signal switching to usernames, adding a privacy-number feature, and refactoring the backup system. Sorry about that. If you find any crashes, please report the bug along with the debug log.

In the last 14 years I owned a smart phone I never had a problem like "has been completely compromised"

Most people don't need to use this feature. We'll improve the onboarding screen to make it clear that unless you're facing particular threats, there's no need to turn on passphrase encryption.

Idea: there could be a second headless app which provides a notification as long as Molly's database is locked

You can notice that Molly is locked because you don't see the "Molly is unlocked" notification, and the little open padlock icon is missing in the top bar.. Did you possibly hide it?

But we can still add the option to show a notification when Molly is locked, without needing another app. It's just that most users I had talked to like the idea of Molly being quiet and unnoticed when locked.

[easthvan]

You can notice that Molly is locked because you don't see the \"Molly is unlocked\" notification, and the little open padlock icon is missing in the top bar.. Did you possibly hide it?

The status bar too part is for cases when you need the attention on the user on some alert or so. when the chat app stops working (database locked) that's such a case when you need to warn the user. Those who are in a cute danger of being arrested or their phone seized or robbed etc might disable the notification under the settings or disable Molly notification for the lock screen altogether.

[muellerto]

You can notice that Molly is locked because you don't see the "Molly is unlocked" notification, and the little open padlock icon is missing in the top bar.. Did you possibly hide it?

Of course I did hide it. An all the time visible notification telling me that everything is fine is for nothing: it occupies a lot of space (you can't even remove it there) and it makes it more difficult to see other (perhaps important) notifications. - What the user needs is an urgent and permanent notification for the rare case when nothing is fine, this is the core of that entire issue. The user must solve this situation manually, otherwise nothing works, but to be able to do this he must at last know that this happened.

But we can still add the option to show a notification when Molly is locked, without needing another app. It's just that most users I had talked to like the idea of Molly being quiet and unnoticed when locked.

Yes. Yeeeeesss!