However there is nothing at all to indicate that the computer has its audio microphone in use.
Yes, typically, but sometimes not when used by parties who want to obscure their use of the camera [1].
[1] http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/18...
However in that case it was for a legitimate purpose.
I can't imagine an IRB-approved research study that requires a software solution (developed under an NDA) to a hardware problem that couldn't be solved with a one-inch square of black electrical tape.
For the price of a contracted software developer, you could simply buy a model of laptop (or smart phone), in which the bezel can be pried open without substantial damage, and behind the LED's transparent aperture (but obscuring the LED), you fix a tidbit of black tape or whichever opaque material you may prefer.
Or, better yet, for pretty much every situation that doesn't involve eye-movement tracking, simply install a hidden security camera at an opportunistic vantage point.
The issues for the IRB would only be the fact that the subjects are not consented to covert surveillance and whether the nature of the information collected presents a risk to the subject if accidentally disclosed.
It's not just that I am still bound by my NDA, but telling anyone what the application actually did, would result in bad things happening to completely innocent people.
However, it turns out that it is unlawful to do that in such countries as Japan.
Asking how to silence the iphone camera on stackoverflow resulted in 20,000 views of my post, several people saying you can't do that, and several people telling me it's against the law, that it would be a bad idea and so on.
Nevertheless, I have a completely legitimate reason to do so.
I expect Apple would reject it from the App Store. I may do it for Android, as well as for jailbroken iOS devices, but then sell it through the Cydia App Store.
It's just like Apple to be a corporate nanny.
I've done some Android Platform Development, but not yet any real Android App Development. I'll do that after I ship the iOS App I'm working on.
There's a lot of stuff that at one time would only work on jailbroken devices, only for Apple to "add support" for it as a result of some App becoming a huge hit at the Cydia App store.
At first one could not even take still photos programmatically, the user had to use Apple's own App for that. But Snapture - if I remember correctly - was able to do it on jailbroken devices, so Apple added the public API so that Snapture would be sold on the App Store, rather than through Cydia.
> Perhaps Apple added a silent mode so as to compete with
> Android.
It doesn't have to be Objective-C and Cocoa Touch. I'd be completely cool with C and system calls.
As others have mentioned, if you put your iphone in silent mode there is no click sound except in Japan. I'm not sure if a) phones sold in Japan have disabled this feature or b) the phone knows when it is located in Japan and then disables silent mode.
Well OK...
More or less like writing any kind of virus.
Apple likes to claim that OS X is more secure. In reality, most of those who write malware own Windows boxen.
Which is of course an utter joke.
But they forgot firmware is software too, and is hackable too. (Now that's a 'leaky abstraction' for ya).
http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/18...
Turns out security is hard. Even compared to just 5 years ago, I think a lot more engineers are realizing how hard security actually is.
Security is hard in software because from the undecidable halting problem it immediately follows that any non-trivial property of software (such as "does the micro firmware turn the LED on when the camera is on") can also not be decided.
There is no halting problem in hardware. But I hear they have very, very cheap switches nowadays that could easily control the power to the camera and a parallel LED.
I've seen advertisements for automated circuit design tools that will convert a C program into the schematic for a chip that does the same thing, only in hardware.
That leads me to believe that hardware must have the halting problem as well. However I only have a passing understanding of the halting problem. Can you enlighten me?
> immediately follows that any non-trivial property of software (such as "does the micro firmware turn the LED on when the camera is on") can also not be decided.
Any non-trivial property of arbitrary software, you mean.
It is entirely possible to prove that some software is or isn't "secure", for however you define secure. It's just not possible to do that for arbitrary software.
It is entirely possible to (for example) write your micro firmware with an integrated proof that non-trivial properties (like the LED/camera thing you mention) are satisfied.
Second:
> There is no halting problem in hardware.
Actually, there is, kind of. Have you heard of the arbitrator problem? Long story short, analog behavior may propagate arbitrarily far into any digital system. You can make it less common, but you cannot get rid of it. Also: any non-trivial property of arbitrary hardware is also isn't provable. (Otherwise you could solve the halting problem, again)