Voice-Recorder icon indicating copy to clipboard operation
Voice-Recorder copied to clipboard

Option to encrypt recordings by default

Open Lppsoeht opened this issue 1 year ago • 11 comments
trafficstars

Checklist

  • [X] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
  • [X] I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
  • [X] I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
  • [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
  • [X] This issue contains only one feature request.
  • [X] I have read and understood the contribution guidelines.
  • [ ] I optionally donated to support the Fossify mission.

Feature description

Toggle to set to encrypt voice recordings by requiring a password to access the app's data

Why do you want this feature?

People need to be able to at least discourage third parties from accessing recordings.

Additional information

Lppsoeht avatar Jul 23 '24 10:07 Lppsoeht

How encrypting audio files should work? Do you know any examples of how it's done by other apps? 

 require password/biometrics to access the app's data

Could you split it into separate request, so here we would only focus on encrypting files?

Aga-C avatar Jul 23 '24 10:07 Aga-C

People need to be able to at least discourage third parties from accessing recordings.

I fail to see the purpose of such feature: phone storage is encrypted by default and anyone caring about privacy/security should be using a strong password/PIN to unlock the phone.

If by third parties you mean other apps on your phone (meaning you don't trust them), then I'm not sure whether you should be using your phone for voice recordings at all...

chesio avatar Jul 23 '24 10:07 chesio

How encrypting audio files should work? Do you know any examples of how it's done by other apps? 

require password/biometrics to access the app's data

Could you split it into separate request, so here we would only focus on encrypting files?

Standard gpg encryption, using a master password or biometrics. Examples: openkeychain app

Lppsoeht avatar Jul 23 '24 10:07 Lppsoeht

More generally speaking, I think also apps like gallery and notes should focus on implementing real encryption when "hiding"/"locking" medias. By following desktop old school way of protecting information.

Lppsoeht avatar Jul 23 '24 10:07 Lppsoeht

Whats even the point of this issue? Someone please close this.

Bonboon229 avatar Sep 15 '24 16:09 Bonboon229

Whats even the point of this issue? Someone please close this.

Pardon me, who exactly are u to dictate that? Take care.

Lppsoeht avatar Sep 15 '24 23:09 Lppsoeht

If by third parties you mean other apps on your phone (meaning you don't trust them), then I'm not sure whether you should be using your phone for voice recordings at all...

@chesio, what's is the logical jump from distrusting applications to not record voice messages in my phone? I could disable/not use those hypothetical unsafe apps, I could use other user profiles, I could encrypt files. Android offers plenty of options. Encrypting a voice message without even saving once the original file into device global storage once would be good for many people.

There are many ways for an attacker to steal a password, and it could be even as simple as shoulder surfing. Also, the so called "secure element" isn't in all devices and/or is not that secure. Mostly depending on time, phone hardware and software version android's encryption could be bruteforced or bypassed. And the attacker doesn't have to be in the right side of the law to do that.

The original repo's name was simplemobiletools, therefore the only reason I see to not accept this feature for most of FossifyOrg apps is to keep them simple and straightforward. And if it'll be that way that's okay.

Lppsoeht avatar Sep 15 '24 23:09 Lppsoeht

@Lppsoeht I would say my personal threat model would make me use a dedicated hardware for voice recording if I found myself not trusting my phone to save recordings unencrypted on the fly as you request. But I reckon that every person has a different threat model and related needs.

Mostly depending on time, phone hardware and software version android's encryption could be bruteforced or bypassed.

Yeah, because proper encryption is hard to implement. Tons of "secure" conversations have been released over years, not because they were decrypted, but because the encryption was not implemented correctly or simply the device has been hacked in a way that made possible to circumvent the encryption. I do trust Fossify devs to have a good knowledge of Android development, but would I trust them with implementing strong encryption? I don't think so. But again, it's up to every person's personal threat model which encryption tools he/she trusts or not.

The original repo's name was simplemobiletools, therefore the only reason I see to not accept this feature for most of FossifyOrg apps is to keep them simple and straightforward.

That was what initially got me to comment on this feature request. One of main reasons I liked Simple Mobile Tools was that the apps were simple and without feature bloat that would take unnecessary storage and drain battery more quickly. So feature requests like this make me little aware :-)

chesio avatar Sep 16 '24 06:09 chesio

I see it a bit differently. It would be ok for me if there would be an encryption, but the problem is, that this should be a standard audio file format, that other apps can also open (after providing a password, like password encrypted zip). Does any standard file format like this exists? I don't know any. And if there's no standard audio file format like this, that I could open with VLC, MPV or any other player, Fossify Voice Recorder shouldn't do its own format creating a vendor lock-in.

tswistak avatar Sep 16 '24 07:09 tswistak

Yeah, because proper encryption is hard to implement. Tons of "secure" conversations have been released over years, not because they were decrypted, but because the encryption was not implemented correctly or simply the device has been hacked in a way that made possible to circumvent the encryption. I do trust Fossify devs to have a good knowledge of Android development, but would I trust them with implementing strong encryption? I don't think so. But again, it's up to every person's personal threat model which encryption tools he/she trusts or not.

I mean, you wouldn't have to trust Fossify devs, android provides the tools, the code would be auditable so...

The original repo's name was simplemobiletools, therefore the only reason I see to not accept this feature for most of FossifyOrg apps is to keep them simple and straightforward.

That was what initially got me to comment on this feature request. One of main reasons I liked Simple Mobile Tools was that the apps were simple and without feature bloat that would take unnecessary storage and drain battery more quickly. So feature requests like this make me little aware :-)

If implemented correctly, this feature would need to be active to drain battery, but yeah sadly I can see this as a reason to drop the feature.

Lppsoeht avatar Sep 16 '24 10:09 Lppsoeht

I have thought about this before (it is tempting) and I'm still conflicted whether or not to implement encryption in Fossify apps. Tibor even considered it once for the File Manager but I don't remember why it was postponed.

People need to be able to at least discourage third parties from accessing recordings.

An alternative to encryption is to (optionally) save recordings to in-app storage which isn't accessible by third party apps (as long as you don't root your device). We have a similar option in Fossify Contacts.

A note on security: Fossify/Simple apps weren't exactly designed with security in mind since it was mostly about keeping things simple. We rely on the platform for security. Any protection/lock is designed to keep the general population away, it won't stop someone with skills and time. Not long ago, there wasn't even a lockout period for passwords (see https://github.com/SimpleMobileTools/Simple-Commons/pull/1824). If and when encryption is implemented (properly), the algorithm used and its implementation by the platform will be the main factor (and the password in case of password based key derivation which is what we'll likely use to keep things user friendly).

I'll leave this open for now and reevaluate later.

naveensingh avatar Sep 16 '24 12:09 naveensingh

Closing in favor of https://github.com/FossifyOrg/Voice-Recorder/issues/100

naveensingh avatar Mar 16 '25 19:03 naveensingh