Microphone availability while other app uses it

Question

1.00/5 (1 vote)

See more:

Hi,

I'm writing a VOIP app for phones and there is an important question about it's security: can other apps access microphone while I'm in a call? I mean if some background app can access it, then it can record the call and that is a security leak...

Thanks

Posted 13-Jan-16 1:34am

dtoth2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 13-Jan-16 10:39am

Of course. Think about it: how anything can muffle the sound which physically exists?
And if you have malware application recording your speech, it would record everything, no matter if one uses your program or not.
The question makes no sense.
—SA

dtoth2 13-Jan-16 11:00am

I think you misunderstood the question. I don't want to muffle sound, I just want to be sure that the OS won't let to any other app to use the mic at the same time while my app uses it for calls. Is this implemented in the os? Is there any API to find out how many apps want to use the mic at the same time, etc...? E.g. if you try to use win sound recorder while you are in call, it will record only silence :)

Sergey Alexandrovich Kryukov 13-Jan-16 11:05am

No, I understood it. I don't mean that you want to muffle sound, I mean that you cannot muffle it, no matter if you want it or not. I was just a hint. Think logically. If you use a sound recorder, it will always record sound if microphone is physically available. How else?
—SA

dtoth2 13-Jan-16 11:19am

So the OS will let a background process to record independently the voice despite the mic is used by another app? If I think logically, I would say that OS has to revoke permission from one of the apps which want to use mic at the same time. It would be the safe mechanism.

Sergey Alexandrovich Kryukov 13-Jan-16 11:38am

Sorry, I did not explain myself clearly. I'm not sure that a microphone can be enabled/disabled per application, never heard of that. If I was sure, I would post a formal answer. I'm talking about different thing.

I tried to bring to your attention a purely practical aspect, about safety. Why trying to take care of such things in your application? Imagine that you have some software which records (detects, transmits) some of the customer voice without explicit customer's consent. But this is nothing but malicious activity. Imagine that you even found a way to block such activity in your application. But what's the use? The malicious process will still spy on the customer when your application is not used. The problem is reduced to the problem of malicious applications in general.

—SA

dtoth2 13-Jan-16 11:58am

Thanks :) Yes, that is exactly what I want to solve. I'm working on a secure VOIP app, and I have to guarantee to the customer that nobody can listen to his call. So, there are 2 ways:
1. I trust the OS - it will not let other apps to spy on me (or at least they can't reach the mic while I use it) even if the phone is in developer mode. It is important, because if the user's phone is in dev mode and he deploys some malicious app than I don't have to think about this way of threat - the OS will protect me.
2. If the phone is in developer mode, and someone deploys a malicious app to it, and the OS will let other (background) apps to record the voice continuously, then I must develop my own protection in my app (e.g. put the call on hold while some other process is using the mic).

Sergey Alexandrovich Kryukov 13-Jan-16 14:59pm

All right, I hear you. Sure, you have your reasons, otherwise I would not continue this discussion after you first comment.

Perhaps the following consideration will be my last argument:

I still think you cannot really solve this problem on application level, and should not try. Here is why. First of all, your comments suggest that you do understand that two or more processes can freely record audio from the microphone; there is no limits here, except some limited system resource. This is really so. The point is: the process you want to protect your customer from would be malicious software. Now, even if you find a way to block some processes from recording the customer's voice, the malicious application will have no less possibilities to unblock it. I can understand your feeling, you want to claim "anything can be eavesdropped, but not my application". But it contradicts to the concept of "application". The applications should not fight against each other, contradict to each other, interfere in any way. Operating systems are always developed in this direction, to prevent it to one or another degree. Besides, the feature you want to implement may create an illusion of safety, which could be even worse.

—SA

Philippe Mori 13-Jan-16 22:32pm

And even, if it was possible...mone could always write a driver at a lower level completly bypassing your extra security. In practice, if someone really want to intercept the communication and he has smarter than you or even protection offered by the user, it might be able to do so. On the other hand, common people probably won't try anyway.

I don't know if it is possible to open microphone in exclusive mode. This would give basic protection. But one could probably write virtual drivers or in some case there might be more than one microphone... Or someone might still be able to intercept received audio and thus get half the communication anyway.

Like browser security or antivirus, one can almost always break system if he out a lot of effort in it.

And finally, you do not necessarily have control over data being intercept on the link between those two people.

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)