GrapheneOS telephone app and microphone access

23Sha-ger

The phone app will obviosuly have a hard coded microphone permission. You wont see it in activity or the dashboard, since mic access means to other apps, not system ones.

Emmy

23Sha-ger I wondered that, too, but why then does it ask for microphone unblocking? Also, after some use (not sure what triggers it...), the phone app reverts to not using the microphone when access is blocked, so at the very least it doesn't seem overly consistent...

GrapheneOS

Emmy This thread is based on a misunderstanding that dialer apps are accessing the microphone to implement carrier-based phone calls, which is not how the functionality works. Carrier-based calls are implemented by the OS and the dialer app is a way to manage the calls. The dialer app is not recording and sending audio but rather managing the OS carrier-based calling implementation. This is why call recording can't be implemented by a non-system dialer app beyond a partial workaround via an accessibility service. The OS doesn't provide support for directly accessing the audio for carrier-based calls. It's not the dialer app using the microphone and speakers directly.

23Sha-ger It doesn't have a hard-wired Microphone permission but rather it's not using the microphone itself for call functionality. It's managing calls, not implementing them.

schweizer schweizer BoredHusky schweizer Curious No, it's not broken but rather you're misunderstanding what these apps provide. This is not a bypass of a permission. Users not understanding how something works does not make it a security vulnerability.

Emmy

I should add that all of the above is about blocking/unblocking the microphone globally from the pull-down control center menu, not fiddling with individual phone app permissions.

To sum up:

Block microphone in top menu control center
Reboot device, unlock, don't change microphone access
Place call, ignore microphone pop-up
Observe other end hearing your voice despite blocked microphone and without microphone status indicator

DeletedUser495

Emmy it may seem to you like permission control implementation for system apps does not behave in the same way as for other third party apps. What is your actual concern? You can still set Phone microphone permission to Ask every time just to ensure it does not remain active after use.

schweizer

Emmy To sum up:

Block microphone in top menu control center
Reboot device, unlock, don't change microphone access
Place call, ignore microphone pop-up
Observe other end hearing your voice despite blocked microphone and without microphone status indicato

I can confirm this issue even with Fossify Phone.

So even a non system app can bypass the microphone block.

After restart I checked that microphone was still disabled. I checked after the call that after clicking abort on the popup the microphone was still disabled.

GOS 2025102601
Fossify Phone v1.7.3

Emmy

DeletedUser495 Well, the concern obviously is that if there's an inconsistency it diminishes trust - e.g. does it work as expected elsewhere?

If the phone app doesn't require microphone unblock, it shouldn't ask for it. If it does, it shouldn't work without unblocking.

Most definitely, it shouldn't work without unblocking for some time after reboot and then later start to not work with blocked microphone...

DeletedUser495

Emmy remember it is a system app so it would not behave exactly as other installed apps do.

You likely have Microphone for Phone app set "Allow while using the app" while global Microphone toggle setting overrides it. In my view nothing unexpected happens here, I would welcome correction if I am wrong.

Emmy

DeletedUser495 Well, my point is it

never logs microphone use in privacy dashboard
always requests microphone access when calling while global microphone block is on (first inconsistency here - if it requests microphone, it should log it in dashboard!)
sometimes (but not always!) overrides the global microphone block when starting an outgoing call and ignoring pop-up, in these cases with no microphone status indicator
some other times (but not always) adheres to global microphone block when pop-up is ignored at start of outgoing call, in these cases after unblocking microphone it does set the microphone status indicator

It should either always do the one or always do the other, in my view. At least that's what I would expect.

Sindbad

Valid finding in my point of view, even iOS shows microphone access during a call.
Since all apps in GrapheneOS should be restricted in the same way, I don't see the reason why a system app with microphone access should not show that specific permission access. In worst case microphone access is active without the user recognizing. Also to me it sounds more like a bug than an intended software behavior.

Emmy

Can't reproduce today, and can't figure out why. Weird!

BoredHusky

Emmy I can confirm the same problem as well. This is clearly a bug and makes you question what else only works.. sometimes.

schweizer

Wow! It is even weirder. I use Fossify Phone as my phone app and microphone usage is never logged even with this non system app. This is definitely broken.

DeletedUser495

Regardless of whatever bugs you may be experiencing it is usually expected the other side be able to hear you when you call them. Anytime before or during the phone call you can flip the global toggle to achieve desired effect. Is this forum getting too nerdy for me or should I reflect upon myself?

BoredHusky

DeletedUser495 Yes, so true! All these nerds ma-an. I mean, I don't care if my car only works sometimes, or my bike, who needs reliability? Why strive for excellence when almost decent is decent enough?

mrket

DeletedUser495 Anytime before or during the phone call you can flip the global toggle to achieve desired effect.

As written in the first post, half the point of this thread is that the global toggle is not reliable when it comes to phone calls. It also calls into question whether there are other instances in which it doesn't work but are less apparent.

I also noticed yesterday during a call that the other side could hear me even though mic access was blocked (and I accidentally didn't unblock it); this was not after a boot, just a random phone call received after using the phone for a bit.
A few days ago it seemed to work, the phone was updated since but I'm on the alpha channel and there have been a few updates lately so it's hard to pinpoint on which version it worked (I also don't perform many phone calls so it's hard to say whether this is related to a recent update).
I only use the default phone app.

schweizer

DeletedUser495 Anytime before or during the phone call you can flip the global toggle to achieve desired effect.

When I read this I get the impression you did not get it. You flip the mic toggle to off before the call. Despite the toggle remains off your mic is enabled during a call. You may say this is a feature but then we would not need the mic off toggle at all.

When a (third party) app can bypass OS permissions this is a serious security issue. If you can bypass microphone possibly you can bypass other permissions as well.

A random app (possibly with network access) activating microphone when you do not expect it is a nightmare. Many are concerned about the camera but the microphone is actually more privacy sensitive.

DeletedUser495

BoredHusky I am afraid you didn't quite get me. None of us is perfect, neither you and I know myself only too well.

Emmy

Well... is it something that should be reported? If yes, where to?

DeletedUser495

schweizer I am not here to argue with anyone. My experience is exactly opposite and what you witness may have nothing to do with permission control which otherwise works as expected but with your actual setup.

Emmy

DeletedUser495 my setup is as per default

Curious

Emmy
Ideally put up a report here:
https://github.com/GrapheneOS/os-issue-tracker/issues
with as much details as possible and ideally a step by step moves to replicate the issue for the team or if this is considered a high security problem there is a contact email for that matter on contact page.

I would pin this on issue tracker with exactly what you did, what you used, the scenario, so team can try to replicate the way it happend to you and they then can go from there and verify if something is off or not.