Crowdfunding to implment call recording?

Toasty

Hey guys,

As you may know that GrapheneOS currently does not have and does not plan to add the call recording feature. And as far as I know there are no open source way to do it without rooting (which according to my knowledge breaks the GOS's security model).
I believe the GOS devs have stated that the only way for call recording to be included in GOS is if someone submit a good piece of code to the GOS project. A dev also stated that if someone really wants the feature, they can code themselves or hire someone to do it.
To me I'd rly love to see this feature however I don't have the expertise to code it myself (I'm just a regular user) and I don't see it'd be a viable option financially to hire someone purely by myself :/
But I am definitely down to contribute say roughly 30 bucks.
So just wondering: how many of us are interested in chipping in a bit to get this feature implemented (to say, hire someone xD)?

Graphite

Toasty far as I know there are no open source way to do it without rooting

Not open source, but ACR.app does work without root. It uses Accessibility to record the mic during a call. So really needs speakerphone during a call or a very quiet room.
Since it's not using a VOIP relay, I just deny network permissions. So being closed source doesn't bother me too much.

intelligence

Toasty GrapheneOS currently does not have and does not plan to add the call recording feature. And as far as I know there are no open source way to do it without rooting (which according to my knowledge breaks the GOS's security model).

Absolutely there is a way to do this without "rooting". NONE of the call recording applications that are available actually use root! The mistake you are making is in understanding the nature of the elevated privileges required and how that relates to Magisk.

The reality is that how programs are installed determines what kind of privileges they have access to. If an application is installed as a privileged system application (which means that the APK is installed in /system/priv-app/), then it gains access to an additional set of privileges that a regular user-installed application won't have access to, and THESE privileges are sufficient to enable call recording.

Magisk has a way of placing an application in the privileged location without actually modifying the filesystem. THAT is what is being used to make call recording work. It does NOT grant root privileges to the call recording application!

So if you want to make call recording work on GrapheneOS without Magisk, you need only place the application in the privileged location DURING SYSTEM BUILD.

BCR is a very concise and open source call recording application that could easily be audited for safety and included. GrapheneOS has come up with a huge heaping pile of excuses against including it, such as "the GPLv3 license is not compatible with GrapheneOS" -- which is totally nonsense since GrapheneOS has a TON of GPL components already! The kernel itself is GPLv2, which is close. There are also a bunch of GPLv2 and GPLv3 components in /external/

breathless19

I would be down to contribute as well. Sometimes customers purposefully call my personal cell phone instead of calling my business line (which is recorded), and not having customer interactions recorded can be potentially devastating. My only option now is to use CubeACR, and I'm not thrilled about their privacy policy.

Graphite

I'm willing to contribute.

However, I have a feeling that 3rd party code won't be accepted for this feature. The core dev team has a very high bar. Not only must the code be well done, but the person(s) must commit to maintaining it. I doubt that we can crowdfund continuous maintenance.

Toasty

Yea plus seems like not many people interested in funding this feature in the first place :/

Graphite

Toasty

Yeah, it's not high on priority. Especially with apps that work reasonably well, the legal grey area, it's a tough sell that the OS should do it natively.

I think fixing the Backup solution should be something we should help fund.

spiral

Graphite
Absolutely agree about the backup

aguttfx

I absolutely want this feature! This is a killer feature for me.
I know it's not a lot but I will contribute USD 100 to its development, this offer expires if not claimed within 2 years from today.

Conditions:

can't depend on specific dialer.
Recordings have to be from the original audio stream, not some workaround via the accessibility API or switching to speaker and recording the mic.
The stream should be the original audio stream or reencoded with a high quality codec like AAC.
Bonus points if the audio recording has separate tracks for mic and for remote audio.
Recodings have to be sorted by remote phone number and timestamped.
Bonus points if if the recordings can be sorted depening on if they were made with SIM1 or SIM2.
Should not crash or bug out. Even if output is changed e.g. from internal speaker to Bluetooth and back.
The code for the API should be open source of course and licensed so it can be used and improved if necessary

Basically I wish it would work like the old Call Recording APIs and apps ( https://stackoverflow.com/a/6688569 ) before Google systematically broke their functionality.

aguttfx

PS: 6. Can't have a mandatory requirement to announce its presence or the fact that it is recording via audio or other (meta)data to remote parties including to the network or the remote caller.

For reference: this app https://play.google.com/store/apps/details?id=com.killermobile.totalrecall&hl=en&gl=US implemented all this and worked great before Google broke Android's corresponding APIs.

BalooRJ

aguttfx This would kill any potential implementation as it would violate states that have two-party consent laws to recording phone calls.

timyysoo

Add another 50 dollars with @aguttfx

timyysoo

timyysoo is there a way to pay with ideal?

f13a-6c3a

Money money money

matchboxbananasynergy

intelligence BCR is a very concise and open source call recording application that could easily be audited for safety and included. GrapheneOS has come up with a huge heaping pile of excuses against including it, such as "the GPLv3 license is not compatible with GrapheneOS" -- which is totally nonsense since GrapheneOS has a TON of GPL components already! The kernel itself is GPLv2, which is close. There are also a bunch of GPLv2 and GPLv3 components in /external/

It's not "nonsense". You're misunderstanding how things work. GPLv2 is nothing like GPLv3. In fact, the Linux kernel is GPLv2, as well as Vanadium.

Are the GPLv3 stuff you supposedly found in the OS, or are they third party tools to build the OS?

Regardless, for the call recording stuff, the approach of including an app like BCR is not one that the project is going to take. If a minimal way to include this functionality in the dialer app was submitted which could be maintained going forward, it may be considered.

GrapheneOS

intelligence Being installed as a privileged app only makes an app run in the priv_app domain instead of untrusted_app. It doesn't provide privileged permissions unless the app both requests them in the manifest and has them whitelisted in the privileged permission whitelists within the OS. Privileged apps can't simply do anything with privileged permissions.

GPLv3 components will not be included in GrapheneOS. There are no GPLv3 components included in GrapheneOS. Not everything within the AOSP source tree is included in the OS. A substantial portion of the AOSP source tree provides development and testing tools including the Android SDK, NDK, etc. It also has sample code and much more. GNU toolchain used to be used to build the OS and kernels, and that's still around. There has never been GPLv3/LGPLv3/AGPLv3 code included in AOSP and likely never will be any. GrapheneOS won't be including it either. It would make the licensing of the overall OS more restrictive in a way that we don't want to do, since we want it to be a drop in alternative to AOSP for companies to be able to use.

Auditing a large existing application would not be easy and the result of a review of the code would likely be that it has issues which prevent us from including it.

intelligence Anything included in GrapheneOS cannot be GPLv3. It's fine for it to be GPLv3 as a standalone application not included in the OS. We could package a GPLv3 app in our app repository but we won't include one in the OS.

intelligence

matchboxbananasynergy I misunderstand nothing. There is absolutely no reason whatsoever for a STANDALONE application to be disqualified as a result of GPLv3.

If it was a patch to an existing application it would be a different story, because then the licenses would have to be compatible, but the call recording program is completely standalone and isn't even linked to other libraries.

matchboxbananasynergy

As a follow-up, I should also make it clear that even if this did happen, and someone was paid to include this functionality into GrapheneOS, there is absolutely no guarantee that it would be accepted into the project, as it would hinge on the implementation being minimal, sound, and easy to maintain, which isn't a given.

de0u

matchboxbananasynergy I'm wondering if (and I realize maybe not!) it might be possible to provide potential contributors, for this or other features, some parameters... Maybe "We can't review features with more than 3kloc of code, pure Kotlin only, must not depend on any packages GrapheneOS doesn't already use, must be tested on all supported devices, must pass these static testers, must be tested in work profiles & secondary profiles, ..."?

Blastoidea

What are we doing here, trying to buy our pet “feature”?

intelligence

GrapheneOS Being installed as a privileged app only makes an app run in the priv_app domain instead of untrusted_app. It doesn't provide privileged permissions unless the app both requests them in the manifest and has them whitelisted in the privileged permission whitelists within the OS. Privileged apps can't simply do anything with privileged permissions.

Recording calls is one of those things that being privileged allows.

GrapheneOS Auditing a large existing application would not be easy and the result of a review of the code would likely be that it has issues which prevent us from including it.

SMALL application. BCR is very small.

GrapheneOS GPLv3 components will not be included in GrapheneOS.

That's a major problem and a very poor position for you to try to support since it makes absolutely NO sense.

GrapheneOS

Paying someone to implement and maintain call recording for years would take a significant amount of money, not dozens of people contributing $20-$50. Getting an existing implementation into shape would only be the start. If it's based on AOSP Dialer, then it will need to deal with AOSP Dialer changing over time. If it's not based on AOSP Dialer, that brings new issues since most dialers aren't a fully compatible replacement without lost functionality so that's less likely to be the approach. They also wouldn't benefit from improvements in new major AOSP releases like AOSP Dialer, which is still maintained to an extent. The best approach would likely be extending AOSP Dialer. People making commitments to donate after something is implemented won't be taken into account at all. We don't accept those kinds of feature bounties.

aguttfx

GrapheneOS

How about we restore the old Android APIs ( https://stackoverflow.com/a/6688569 ) for call recording that worked great for years before Google purposely broke them.

The users could then reuse the myriad of already existing old recorder apps. No changes to maintain in the caller app or in the settings. No GUI to adapt. No additional recording file logic to implement. No root privileges required. "Just" make some legacy APIs public again. Maybe modernize them by requiring a permission that the user can give for extra security. Have you considered this?

GrapheneOS

intelligence

Recording calls is one of those things that being privileged allows.

It's a privileged permission and GrapheneOS enforces privileged permission whitelisting as required by the standard Android security model.

SMALL application. BCR is very small.

It's quite large in the sense we're talking about. Small is a few thousand lines of code like Auditor.

That's a major problem and a very poor position for you to try to support since it makes absolutely NO sense.

We've explained why that's the case. GPLv3 imposes additional restrictions which AOSP avoids including forbidding making devices with an immutable root of trust. This is a problem because we don't want to forbid making a device with GrapheneOS without support for unlocking. What if we want to sell a special variant of a GrapheneOS device without support for that to reduce attack surface, particularly since it's something many companies prefer? It's not anywhere close to the lowest hanging fruit for verified boot attack surface but it is attack surface.