GrapheneOS telephone app and microphone access

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.

BoredHusky

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

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.

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.

Emmy

GrapheneOS Thanks for the explanation. It's a wee bit confusing in that case that the dialer app (?) asks for microphone unblocking when a carrier based call is placed. And on at least some carrier based calls, the microphone status indicator lights up, even though the use isn't shown on privacy dashboard afterwards.

I obviously very much trust you folks it's all fine security wise, but how is that (mic request but no mic use, mic status light but no mic dashboard entry) not at least somewhat inconsistent?

Also, what would make the mic block sometimes be adhered to and sometimes not? That at least feels a bit inconsistent, too.

schweizer

GrapheneOS Well if the phone apps do not need microphone permission to use the microphone, why ask the user to grant that permission when the user has disabled it?

At least pls rephrase that prompt. I.e. mic is enabled for SIm based phone calls anyways. Do you wish to mute your mic now?

Remember there are SIP phone apps as well. As far as I can see the mic is locked for those apps which is just the opposite behaviour than for SIM based calls. No user will expect that behaviour.

I could live with removing the global mic permission toggle. But if the function remains there it should do what an average user expects from it. If many users misunderstand the way a program works then the program is not self explaining.

bellaph

GrapheneOS

I don't really get how this affects the system wide setting to turn off the microphone permission, or is this bypassed by the "carrier-based calling implementation"? And if so, why doesn't it show up anywhere that the microphone has been used by the carrier based call implementation? Is that a system service (The "telephony service")?

When I look at the Microphone permission it says "Device Microphone is blocked Microphone data may still be shared when you call an emergency number". But this is not correct if the microphone data is shared by all carrier-based calls, and seems worrying when the user isn't notified by this at all.

I'm kind of surprised if this is actually expected behavior. Or maybe I'm just misunderstanding it. Hopefully this could be explained and clarified further.

DeletedUser495

@schweizer @Emmy if you look in Settings > Apps > All apps > Show system > and search for "Phone", you will find that Phone is not the only app that handles and manages telephony. You can revoke microphone for main interface Phone app, but Phone services will still have it enabled. Permission control still behaves as expected, this is not a bug.

Emmy

DeletedUser495

Mic request but no mic use, mic status light but no mic dashboard entry seems inconsistent.

Sometimes adhering to mic block and sometimes not seems a bit inconsistent, too.

Maybe not quite a bug, but at least not self-explanatory.

DeletedUser495

Emmy if you can't trust an app, don't use it. Problem it is not mine.

Emmy

DeletedUser495 that isn't the point at all, is it? It should be obvious to any user what the OS does in terms of permissions and mic use, and while the system is secure, it's not doing obvious and easily reproducible things here in this scenario. And I guess it's probably AOSP rather than GOS where this comes from, anyway.

So, while probably not a worry, it's still something which would look and feel more consistent in an ideal world.

And that should be allowed to speak up about, no?

DeletedUser495

Emmy well, if you can't find more important topics or pressing issues to talk about, like proper human diet or why big food and big pharma want us all sick and paying up, be my guest.

schweizer

DeletedUser495 if you can't find more important topics

DeletedUser495 don't blame GrapheneOS for what AOSP somehow gets wrong.

I do not understand why you take this so personal. And once you say it is unimportant then you say there is a problem. Nobody forces you to post here.

Apart from removing the global mic permission feature (which would free dev ressources) there is another way to make it work better:

Instead of asking the user to unblock mic permission when in fact this does not change anything, the dialer could just mute the mic in the dialer when global mic permission is off.

Many conference call programs work like this. If you stopped your last conference with mic disabled it will start with disabled mic in the next call. So this is a behaviour many users are familiar with. If you want to talk just unmute the mic.

DeletedUser495

So, I have looked into this on my son's 8a with stock. Made an obligatory phone call with the stock dialer app, had to enable microphone in order to place a call. Checked after in permission manager. Surprise, no record of microphone access. Please, don't blame GrapheneOS for what AOSP somehow gets wrong.

Emmy

DeletedUser495 nobody is blaming GOS for anything. As I don't have a stock device, I can't observe stock behaviour.
Again, there's an inconsistency here which I am merely observing and reporting. Surely that must be allowed.
@GrapheneOS have provided a partial explanation for some of the observations, but parts (why does the OS carrier call with mic toggled off sometimes override mic access but sometimes not) are still a mystery, not only to me. And yes, it's most probably an AOSP issue.

« Previous Page Next Page »