GrapheneOS telephone app and microphone access

Emmy

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

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

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.

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

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.

DeletedUser495

schweizer funny thing is that in almost 3 years of using GrapheneOS I have not once experienced this "buggy" behaviour the three of you bang on about. I don't touch permissions of system dialer and solely use global microphone toggle and it works exactly as intended.

Unfortunately I have nothing to add to the discussion, since I could not replicate your issues. I hope you can find the cause of your anomaly, source of which as it is by now my trademark answer lies somewhere in your setup. Of course I have to take it personal, when I am directly dragged in a construed conflict caused by not so sensitive remarks. Good day to you.

Curious

@GrapheneOS

So I tested with GOS and normal android.
When mic global toggle is turned off on normal adroid it does not let you dial at all unless you turn it on.
On GOS the global switch seems pointless since you are able to dial through it and voice is also captured.

I thougt that when something is turned off it should be turned off (even it is a system part), like wtf?

There is also statement of it:
https://discuss.grapheneos.org/d/12562-microphone-turn-off

You can simply avoid granting Microphone access to apps. There's also a global Microphone toggle which you can disable to disallow access even for apps or OS components with microphone access. It works the same way for the Camera permission and toggle. There's also an access history and indicators when they're being used.

But it seems like this is not working at all.
I mean when I turn off switch there should not be anything able to access it, use it or voice go through.

Even tho permisions in permision manager are turned off for default dial app the dial and call still goes through.
When on top of that the global switch is turned off it still goes through. Why this global switch not cut off also a system apps and services from accessing the mic?

Also I tested with camera:
if you have permission denied on camera app to use camera then the app will tell you that it is required -> ok
if you have allowed those permision and toggled off mic and camera -> it will ask you to unblock -> OK
but when you start recording you are then prompted to unblock camera and then mic, but if you keep that prompt up in first case it will keep recording but it is basicly blackscreen of nothing and in second case it will start and record video but without sound.
Also one thing if you permited cammera to function without sound (aka recording will happend but without sound) and you want to make it back, you have to clear the cache of an app to be abl to reset it. The simple toggle off will not work for mic.

Also yea that fact that there is no permision history about those accesses during calls is also weird even tho it is on OS level.

If this is AOSP issue then why on other system this is working as expected?
I mean it is a simple logic no? If switch is turned off the access should be turnedd off no, no ability to do calls nor receiving them?

Emmy

Curious You're right, the explanation/statement in the other microphone thread seems on first looks to be somewhat contradictory to what was stated in this thread by @GrapheneOS earlier, however as phone calls don't seem to count as "microphone use", maybe it's not.

For me I don't get why it's sometimes accepted blocked and sometimes overridden by the OS carrier call function.

Curious

Emmy I know right?
Like ok if this is from upstream and it is a bug or feature: that you cannot block mic access on default level due to making calls always go through, then ok I would take that but I am not sure if this was acknowleged or no like that. Also this and the other thread are not the only one that poiting to this issue.

Like for me it is a simple concept when something is turned off/blocked it should be turned off/blocked.
If it is happening randomly or not at all, that shows some issue in the expected behaviour.
Like I understand what @GrapheneOS stated above that the call and mic usage is not going through the dialer app but rather through the "call modem element" if I can call it like that, thus the permisions of android itself are not affecting it, so that means dialer app has no access to mic but the hw module that is performing the call still has so that is the reason why call goes through with mic eneabled but why on diff OS this is blocked by that switch?

Like idk if I turn something off in BIOS well it is not there at all, not drivers can interact with it, no OS can iteract with it nor user etc.
Like I know this is not a same in this case but I am just trying to show what the normal user expectation is, because sometimes (idk how this can happend but it happend some people) that when you had a phone in pocket etc. the dial went through without user knowleage and the other side could hear what you were talking about or just noise.

« Previous Page Next Page »