Alerting Users that Applications are Using Cameras, Microphones, Etc.

Interesting research: “What You See is What They Get: Protecting users from unwanted use of microphones, cameras, and other sensors,” by Jon Howell and Stuart Schechter.

Abstract: Sensors such as cameras and microphones collect privacy-sensitive data streams without the user’s explicit action. Conventional sensor access policies either hassle users to grant applications access to sensors or grant with no approval at all. Once access is granted, an application may collect sensor data even after the application’s interface suggests that the sensor is no longer being accessed.

We introduce the sensor-access widget, a graphical user interface element that resides within an application’s display. The widget provides an animated representation of the personal data being collected by its corresponding sensor, calling attention to the application’s attempt to collect the data. The widget indicates whether the sensor data is currently allowed to flow to the application. The widget also acts as a control point through which the user can configure the sensor and grant or deny the application access. By building perpetual disclosure of sensor data collection into the platform, sensor-access widgets enable new access-control policies that relax the tension between the user’s privacy needs and applications’ ease of access.

Apple seems to be taking some steps in this direction with the location sensor disclosure in iPhone 4.0 OS.

Posted on May 24, 2010 at 7:32 AM37 Comments


Clive Robinson May 24, 2010 7:51 AM


Two quotes from above,

1, “We introduce the sensor-access widget,”

2, “Conventional sensor access policies either hassle users to grant applications access to sensors or grant with no approval at all.”

What makes them think that anybody in 2 who would just take privileges (because they can) is going to bother registering with their widget (1).

It needs some fairly fundamental plumbing to stop this sort of abuse and it’s the sort of thing MS should do but we know the chance of them doing that is somewhere between zero and 1/infinity.

halcy May 24, 2010 7:58 AM

I think early webcams in notebooks had it right.

Activity LED hardwired to the webcams killswitch. Best way to make sure things work as intended.

Jeremy Impson May 24, 2010 8:33 AM

Physical controls / indicators (shutters or hard-wired indications like LEDs) really are the best for this type of situation, and have been overlooked in the era of soft control of everything. I also happen to like physical switches for my WiFi antenna and internal speakers.

But, did you know that many automobile engine temperature gauges don’t actually show the temperature? They’re actually three-position indicators: too cold, just right, and too hot. Cheaper than a continuous gauge, and effective at indicating the important states the driver needs to know about. Point is, even if we see an increased demand for physical controls / indicators, we can’t assume they’re exactly what we think they are.

I’ve had one laptop with a WiFi switch that seemed to actually interrupt RF signals. When switched off, the software reported “no networks in range”. I’ve had another where the software knew the position of the switch, which always made me wonder if the switch physically controlled anything, or was just lit a pin that the software checked, meaning if it wanted to (or was coerced to), the software could ignore the switch position. (It was a work laptop, so I never took it apart to try to find out.)

Tim May 24, 2010 9:09 AM

This is only really a problem for microphones. Every webcam I’ve seen has a hardware light to indicate when it is active. It would be nice if laptop microphones did this too though.

BF Skinner May 24, 2010 9:40 AM

Based on the law enforcement communities demonstrated ability to take cell phones off hook and use them as remote mic’s – it’s probably prudent to consider all mics live at all times (former PM Brown, current VP Biden, deceased Presidents Reagan and Nixon; and Sarah, what were you pop thinking?)

Pete May 24, 2010 10:18 AM

I cut a 5x10mm piece of transparent tape, folded one of the ends over for a handle, and placed it over my laptop camera. IF it gets enabled and I don’t see the LED, the viewer just gets a blurred image. When I need the camera for something, I just move the tape off the lens until I’m finished.
Total cost: $0 (you can get tape at the library).

SteveL May 24, 2010 10:22 AM

I think it works for basic environment sensors, but location is a tricky one: even without GPS you are publishing lots of your location data to the web: IPAddr, maybe wifi information. Then there’s implicit information: if you are using an online application to get a map, the web site doesn’t need to know that at 11:42 I was at the top of ninetree-hill, all it needs to know is that at 11:42 my device downloaded the map for nine-tree-hill, and at 11:43 grabbed the map for freemantle square, therefore in one minute I traversed a road. It’s implicit in the data you ask for.

I’m very dubious these days about the speaker/wifi buttons on laptops -these are soft buttons not hard ones, same for the wifi light, so something could be online without me noticing.

Peter A. May 24, 2010 10:31 AM

In the old times when the machines (be it PCs or X terminals or RISC workstations) had no built in microphones, only MIC jacks at the back, and audio subsystem security was even lower than today, I routinely had the MIC jack unplugged (if I ever used it at all) and only used to plug it in when I needed to speak to the thing (which was very rare).

Henning Makholm May 24, 2010 10:51 AM

I don’t think hardware activity LEDs solve the problem (though of course a software widget is even less of a solution). If the attacker does not capture continuous video, but just a still image now and then, the activity LED will not be on constantly. Just sometimes a short blip somewhere in the user’s peripheral vision that is not there anymore even if he notices it.

Microphones might be a different matter.

W May 24, 2010 11:05 AM

I don’t think hardware activity LEDs solve the problem
Just make it blink for 10 seconds after a picture has been taken. I’m pretty sure I’d notice that.

vwm May 24, 2010 11:21 AM

@W: The average user reaction will be “oh, my webcam is having it’s funny 10 seconds again.”

@SteveL: I do not have to be at nine-tree-hill to look at the map of it.

Kevin May 24, 2010 11:27 AM

Android has a fairly good implementation of application permissions at install time. Would be nice if Android added run-time disclosure as well, but @ install is a good start.

If an app needs to make calls to access specific sensors, these must be specified at build time, and all sensors requested displayed to the user when the application is installed.

An application cannot make an ad-hoc request for a sensor — if it wasn’t built with “Position” or “Camera” access, then it will be killed by the Android OS if it suddenly tries to access these sensors at run time.

Dom De Vitto May 24, 2010 12:24 PM

Those of you with beards, and me – though I didn’t have a childhood – will remember the US CERT announcement regarding attacks against Sun workstations, and specifically regarding espionage taken from recording from office microphones – sometimes from unattended machines.

That’s when Sun then started putting a little red on/off on switch it’s microphones….

The more things change…..

bob (the original bob) May 24, 2010 1:58 PM

There should be a non-overrideable physical off switch (such as the kind which so offended ‘Mycroft Holmes’ in “Moon is a Harsh Mistress”) on all “external input” devices on a computer (ie, camera, microphone, wireless network). Currently I keep a post-it note on my camera.

SteveL May 24, 2010 3:19 PM

@vwm “I do not have to be at nine-tree-hill to look at the map of it.”
True, but if the streetview scene downloads come from a navigation applet and the events occur at a rate comparable with someone walking or cycling, whoever runs the datacentre can make a good guess as whether or not you are moving on foot or car.

NobodySpecial May 24, 2010 4:47 PM

@Dom De Vitto
Especially since all the profs got the newest Sparcstations and all stuck the little cute microphone to the monitor.

Then a simple ‘xon’ to record anything they said

Henning Makholm May 24, 2010 5:35 PM

@W: “Just make it blink for 10 seconds after a picture has been taken. I’m pretty sure I’d notice that.”

Do you propose to add dedicated analog circuitry to make that blinking happen? Ten out of ten engineers would make it a software/firmware controlled feature (which means it’s hackable), unless presented with extremely stringent requirements insisting on an independent blink circuit. Perhaps one out of ten engineers would let a programmable device controller blink the LED even in the face of requirements to the contrary, because making an independent blink timer is just bothersome and expensive. How are you going to check that your device was not designed by that one out of ten?

And no matter how it’s implemented, in which possible way would it be superior to a purely mechanical, easily-flippable, foolproof hinged lens cap?

Clive Robinson May 24, 2010 6:20 PM

@ Dom De Vitto,

“All those with beards, and me”

You don’t say what sort of beards and most importantly “they must have a bit of badger” in them…

For those not sure what “a bit of badger” is I refer you to the photo top right of this page for an example 8) I’m just jealous because my beard only has “a bit of dazzle” not badger so I don’t get the gravitas I should 8(

Jim May 24, 2010 7:17 PM

The OLPC addressed these issues as a basic design constraint; indicator LEDs are hardwired into the microphone & camera circuits.

I don’t know, but I assume that they are fail-safe; i.e. if the LED fails, the associated device is disabled. If you don’t have fail-safe indicators, there’s little point in having them at all.

I don’t see how a piece of software, especially on a non-secure OS, can help at all besides producing a false sense of security in the users. To be honest, this is completely a hardware issue.

Clive Robinson May 24, 2010 11:19 PM

@ jim

“To be honest, this is completely a hardware issue.”

Oh if only it was just a hardware issue, in Fast Moving Consumer Electronics (FMCE) things are rarely simple as it is driven by other factors such as line costs and return rates.

For instance the LED is not just an extra component sticking out a hole in the case.

The LED needs to be mounted, restrained, oriented and connected to. All of which have way higher cost implications than the cost of the LED and changing the design of the tooling of the case.

Line costs dictate that the LED be part of the camera PCB, but due to size, sub manufacture / bought in cost this is not likley to happen.

This implies another case mounted sub assembly which has to be inserted and fixed (big line cost) in series with the camera which means increased unreliability (thus higher return costs / loss of brand value).

Then there is the orientation of the LED this can easily have significant “re-work costs” either on the final line or sub assembly line.

Then of course there are design issues LEDs drop voltage (think zener diode) and draw significat current. The acceptable current range may not be the same as the camera thus necessitating other components such as dropper resistors or constant current drivers. Even if the current is compatable the LED drops between 0.8 and 2.1 volts depending on it’s design and colour, thus it is to much to put in series for a battery of only a few volts. Either way it has a big impact on battery life/usage.

Then there are the mechanical design issues over and above modifing the design of the case tool to put that little hole in.

All LED’s have two or more connecting leads. In the case of surface mount devices the mechanics are controled in the case of leaded components unless pressed down to a PCB this opens up a whole can of worms involving forming tools and stand off devices during PCB assembly. Even when surface mount or mounted flush to the PCB the LED still requires a way to get the light out of the case and this will usually involve a “light pipe” which is a clear plastic moulding which has it’s own tooling and line costs.

Oh and users fingers… Any device mounted in the case that pokes out through a hole into “userland” has issues to do with users proding and poking at it. If not considered correctly a light pipe could easily move causing preasure on the PCB causing mechanical strain and early failure and thus effect return rate under warranty or bad product image issues that effect the brand value.

There is a lot more to it but FMCE design trade offs are non obvious to many insiders and not even perceived by those not involved with “design to manufacture”. And it’s these hidden trade offs that make the big difference to profitability.

AC2 May 25, 2010 12:03 AM

@Clive, last comment

You make it sound like its pretty much impossible even though as several posters have pointed out we ALREADY have several devices (esp cams) on the market with something like this….

And you have yourself pointed out in your first comment the app/ OS level implementation will be even more difficult to build and easier to bypass…


Yup, Toshiba laptop with physical switch for WiFi/ Bluetooth, most battery saving bit on the whole laptop


So lets not make the dashed thing blink just leave it on for 5 secs using a suitable capacitor every time accessed.

Clive Robinson May 25, 2010 3:45 AM

@ AC2,

“You make it sound like its pretty much impossible”

No it’s quite easily possible but is the market prepared to pay the price?

The problem with the way it currently is, is that it’s a race to the bottom as far as price is concerned in a very time critical market (product goes from top of the line to near bottom within three years). Thus “marketers” have to decide what features are going to give the best return on investment in the shortest period of time.

As has been seen with the banking colapse the safe route for a marketer is to push what everybody else pushes if it succeeds then they get the credit if it fails then it’s the market intelligence that was wrong (ie put yourself in a win-draw not win-lose position).

Also with the likes of laptops there is a lot of badge labeling for a number of reasons. This is not just on bought in parts but on whole systems.

Part of this is chip manufacture refrence designs partly to do with tooling up charges. The chip manufactura wants to push chips and the marketers want to sell finished items the faster a chip manufacturer can get the marketers design enginers on stream the more likley they are to sell product.

The downside of these refrence designs is that they tend to come in three hardware flavours high medium and low cost. However “software” can bridge the functional gap (or so the marketers believe).

Also the marketers design engineers do not have time to experiment or inovate so they likewise go for a win draw position, they ask for the highend refrence design then ask “what can we take out”. The result on their PCB aproximates the medium reference design with components left out in production…

The marketer however also wants “design re-use” so that one PCB goes in as many products as possible and they still expect CPU horse power and clever coding to give them profit for free.

If you look at motherboard designs from various manufactures you will see the same little layout blocks on various boards with the variation around the edges of the design blocks. This is “design reuse” in action.

To break this pattern a Marketer has to be convinced to move from the win-draw position to the win-lose position. And they only way they are going to do this is if you can convince them the market not only needs the trend but will pay premium for it…

It is why you see the likes of Apple and Sony “trend setting” they have room to manoeuvre in their premium pricing structure that other manufactures do not have.

It is the consequence of certain economic market models, and usually the first casualty of this “vanilla market” is innovation. Instead products differentiate themselves on “specmanship” bassed not on real bang for your buck but on decreased user performance due to the spec being met by CPU cycles.

As an example look at accelerometers in hand helds. Apple put them in “on risk” but software engineers thought “that’s neat” and built unthought of (at design time) apps. Now the market is playing catchup because the vanilla market wants the premium market “toy”.

If this security increase is seen to work for Apple or Sony then you will almost certainly see it in other market entrants otherwise probably not accept in niche premium products.

Thus not your impossible just my improbable.

Clive Robinson May 25, 2010 3:53 AM


In my above the penultimate paragraph should use “except” not “accept”.

Wanda Round May 25, 2010 6:43 AM

A site wherein someone uses “penultimate” expecting others to understand–I’m going to pinch myself in joy!

Now I’m waiting for a good “antepenultimate.”

Julius Strangepork May 25, 2010 6:47 AM

Do not forget that other 3rd party applications, plug-ins and extensions all may access you webcam. Users should always check their Flash settings and limit/deny access to the WebCam from Flash. Visit On the right side panel under support you will see your Flash setting panel, users then should open that link and adjust the settings including access to mics and cameras.

The tape over the web cam is right out of public NSA guides, this is less altering then removing it completely.

Also a note on LED is that if someone triggers a picture the flash of the LED may not be seen. It last less then a second so I think tape is the best solution will also controlling what software has access to it.

peri May 25, 2010 7:57 AM

@Wanda Round: “penultimate”

Sorry, I can’t give you that but I can give you this: He meant “based” instead of “bassed” in the preantepenultimate paragraph.

David Thornley May 25, 2010 11:49 AM

@Wanda: That’s what delighted me about Lemony Snickett’s “A Series of Unfortunate Events”, book 12, “The Penultimate Peril” when I realized there were 13 books in the series.

Stephen June 15, 2010 4:19 PM


Because the webcam and mic are built into the laptop…as well as the GPS, the Wifi, the bluetooth, the accelerometer and all the other sensors that can leak information.

Accelerometer? Well, yes, aircraft use accelerometers in their inertial navigation systems, so it is conceivable that an application could trace your path based on data from the accelerometer.

Kate June 17, 2010 5:48 PM

Mini post-its to the rescue. I cover my webcam with one. But the mic is still an issue. If only there was a giant power button or cable that read “unplug me”

Daniel June 21, 2010 3:09 AM

@vwm : You don’t have to be somewhere to get a map of it, but if the map request comes from a mobile device and the location request is not an address but a GPS coordinates, and all previous and subsequent location requests are in the same zone and are GPS coordinates, you have a pretty good guess that the location is coming from a GPS chip in that location…

Nate Theis July 11, 2010 6:24 PM

The OLPC XO-1 and XO-1.5 have a very, very good method for implementing this: a LED in series with the power line to the mic and another one for the camera VIN. If the LED blows, the device doesn’t work, but it’s easy to replace. Also, OpenFirmware keeps the power on for ~3 sec after apps stop accessing it, and (unless you get a special “Developer Key”) is not software-writable. The LEDs are very very bright and are very obvious, being directly above each device.

James May 28, 2014 4:50 AM

Interesting discussion. IMHO the simplest robust solution is to PAINT any built in camera, GLUE any built in microphone – and then plug in external camera and mic when they’re actually wanted. Not connected is the best security.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.