Hacker News Reader

Comment by drusepth | Hacker News Reader

This seems equivalent to security theater in response to misplaced fear and mistrust over cameras in general. I understand why they felt pressured to make this change (and the "good" PR it results in), but I can't help but shake the fact that, well, it doesn't actually do anything.

Bad actors will just disable the light in a myriad of ways. People will still mistrust cameras because the light can be disabled. Drawing over the light with permanent marker (or doing something temporary like putting tape over it) doesn't even create a small barrier of entry for people secretly recording. If they want to secretly record, it's not significantly harder now than it was yesterday.

The only thing this is supposed to accomplish is appeasing people that don't understand technology yet make a ruckus over Google disrespecting privacy. Now Google can say "no look, we do!" and those people will complain about something else.

View on HN

The LED needs to be connected to the power lead on the camera. Then it cannot be hacked via the software.

Also, microphones and cameras need physical switches to enable them, not software switches. Preferably with an LED indicator too.

This is what I did with the electric fuel pump on my car. A dash light connected to the power lead, and a physical switch. There's also a low oil pressure switch that'll interrupt the power to the fuel pump.

This is not practical, if I use it as a baby cam I want the light to be off.

We have been using it to watch our non-verbal young autistic son in bed. I know a tiny light in a pitch black room keeps him awake for many hours of the night and he doesn’t do being awake quietly so it also keeps us awake. We also can’t just remove the camera, it’s not like he is able to tell us that he has wet his bed. Having been given zero days notice of this change means I’m going to have to take time off work today to go home to find an effective way to put some tape over the light.

I have been holding back on deciding which home automation ecosystem I want to buy into. I was leaning towards Google and Nest was our first step into that direction. However I’m now increasingly of the opinion that I should just continue to build it out with devices where I have control over the firmware.

1. Pretty much every audio baby monitor in existence has an LED on it, those cause no problems.

2. Duct tape/sharpie

(1) Not a blinking one, though. That's a little more annoying.

(2) there's a nice product called LightDims that are removable. Little stickers that are about 95% opaque.

> (2) there's a nice product called LightDims that are removable. Little stickers that are about 95% opaque.

You can also use colored electrical tape as it is opaque (buy quality tape like the 3M brand). I've found that the best colors to use are white or yellow. Other colors work too but let less light through like red, magenta, and blue. Though those darker colors are beneficial for very bright LEDs.

I taped over all the annoying LED's on my router, switch, and low power server which live in my bedroom on my desk. It went from discotheque to barely noticeable.

It is practical.

The light could be designed to not be disruptive even to a baby, or you could build a physical switch into the device to turn the light off.

It just shouldn't be remotely configurable because that undermines some of the purpose of the indicator.

If it’s connected to a physical switch you could still turn it off.

I wouldn't trust it as a baby cam - the Nest or anything that relies on wifi. If you do, probably a good idea to add a cheap audio monitor as well.

Why not? I've been using one for two years now. It works fine, and allows me to 'roam' a bit farther than a simple RF transmitter.

I tried a Nest but went back to an IP camera because the Nest can't be monitored off a local feed — it has to go to the cloud first. Most of the time when I'm looking at the baby monitor I'm at home. Requiring me to send it to the cloud before seeing it on my local device is bad for two reasons:

1: If the internet goes out, I can't even monitor locally. With IP cameras, it doesn't matter if the internet goes out.

2: Since the camera is always transmitting to the cloud, I don't want to use a very high-resolution option, which would eat up too much upstream bandwidth. What I really want is to have moderate-quality footage going to the cloud and high-def footage whenever I go to check it in real time. With an IP camera, it's only transmitting when I'm actually connected to the feed.

Vastly more ways for it to fail without being immediately obvious to the user.

One solution is to apply some sharpie or electrical tape to the light.

Same - hugely frustrating.

A low-power red LED shouldn't be keeping anyone awake.

You dont get to pick what keeps infants and toddlers awake, my dude.

I don't believe that most children would be bothered by a single, dim red LED. If your child is, it's easy to cover it a bit of electrical tape. So arguing against a feature with clear and significant security value because you don't want to risk the possibility of having to fiddle with tape is silly, my dude.

This is how iSight is designed, no?

No. Everything I've seen indicates it's much improved over the pre-2008 iSight[1], but still not hard-wired to the power rails.

[1] On those early models it was relatively trivial to upload malicious firmware which was widely reported and verified.

> No. Everything I've seen indicates it's much improved over the pre-2008 iSight, but still not hard-wired to the power rails.

Everything I’ve seen is the exact opposite. Care to share a source confirming your belief?

Other than physical access to the camera (at which point they will more likely just install their own cameras), how precisely could attackers disable the light in any plausible ways? I’ll offer one for free:

1) “Forcing Google to do so through a government court order that leads to a firmware update to that specific camera”

What other methods besides “issue Google-signed firmware to the device” are you implying exist (“a myriad of ways”), that are obvious enough to be taken for granted without further explanation?

I can’t see them, and so unfortunately I must request that explanation.

> how precisely could attackers disable the light in any plausible ways?

The light is software controlled, as this very change clearly demonstrates. The fact Google can turn and off the light at a whim suggests an attacker could. Your defense of this being possible is based on a vague theory of infallible security.

You even seem to use a fictional quote to that end:

> What other methods besides “issue Google-signed firmware to the device” are you implying exist

Who are you quoting? What are you quoting? And where can I read up on google's infallible firmware signing strategy that you're implying has the ability to block exploits and bugs?

Despite claims to the contrary you're less "requesting an explanation" and more making several unsupported security claims, then asking people to refute your claims as if they were factual in nature.

If this device was as secure as you imply that would be quite unique for smart home devices in general, and software in general for that matter.

Nest historically used firmware updates to do this stuff, I see no explanation why Google would vary that practice for something they’re doing to gain trust. They could be so absurdly stupid that they software control that lamp off from their servers as a permanent solution, but I think they have more wits about them than that. As you point out, it’s a terrible idea; and it’d wreck them in the press if that was their final answer.

Please reread Someone1234’s comment.

In my words: Nest devices had security issues in the past [1]. It’s very likely that they still have issues today (like most software). Once a hacker gains enough control of the device she can turn off the led because it’s software controlled[2].

[1] https://gizmodo.com/this-nest-security-flaw-is-remarkably-du...

[2] https://www.grahamcluley.com/webcam-spying-without-turning-l...

That is not an answer to the question you were asked.

"And where can I read up on google's infallible firmware signing strategy that you're implying has the ability to block exploits and bugs?"

I have no clue where on the scale of "state action" -> "bribed/coerced insider" -> "disgruntled ex google employee" -> "Elbonian strip kiddie" you need to be to "control that lamp", but I'm 100% certain that the reality is that the capability to revert this new lamp behaviour is not exclusively in the hands of authorised Google employees...

It's exactly the same as the current encryption bullshit. If there's a backdoor for law enforcement, there's a backdoor. If there's a remote way for Google to update the Nest software - there's an exploitable remote way to update the software.

>If there's a remote way for Google to update the Nest software - there's an exploitable remote way to update the software.

This is (quite obviously?) wrong. One doesn't imply the other at all in any way shape or form. If this were true, there wouldn't be a single device on the planet, including phones, servers, etc. with remote update functionality that would be secure, ever.

Also

>If there's a backdoor for law enforcement, there's a backdoor.

duh? But I think what you are trying to imply is that "there is a backdoor that criminals could use" - which is also wrong. As long as the implementation is correct and the key isn't leaked, this is completely secure. Of course it'd be insane to have one key being able to unlock essentially all communication within a huge system, because chances are it might be leaked eventually, but that has absolutely zero impact on the fundamental possibility of making this system secure.

> If this were true, there wouldn't be a single device on the planet, including phones, servers, etc. with remote update functionality that would be secure, ever.

You're so, so close to waking up from the matrix. Very excited to have you join us in the real world soon! Follow the white rabbit.

If it's on a network and connected to the internet, it can be hacked.

Perhaps malicious code will be produced which will only take single frame shots, never staying on cycle long enough to trigger the light.

Or it will go unnoticed because it flashes on and off so quickly.

I will concede that it’s technically plausible to chain an RCE persistent attack to it somehow, and hopefully that pays out a significant bounty!

When I think of bad guys with cameras, I think of Airbnb scams and the like hiding cameras in a home/office/etc. When they have physical access to the camera, there's a million ways to disable the light ranging from nail polish to opening it up and rewiring it.

I wasn't even considering remote attackers, but I'd imagine it's not a large step from [compromising a remote camera such that you can remotely record] to [compromising a remote camera such that you can control other software features while remotely recording].

I admit this update does make it a bit more difficult (for now?) for remote hackers to secretly record people; I'd be interested to see how prevalent that is compared to people actually just recording people with their own cameras.

Putting tape over it.

Remotely?

You could mount a tape dispenser on a robot platform, but it’s not really “plausible”.

There are real positive effects from this change, though -- in particular, it does prevent a remote attacker from viewing the camera undetected.

This was already solved, however. If one was worried about this, one could have set the option to leave the light on when recording.

The most likely threat model for someone being able to access your camera feed is that they compromise your Nest/Google account. In which case they just turn the light right back off.

Better to just put a shutter on the camera.

Oh wait, that breaks Google's business model of spying on people, plus it does nothing to the microphones on this thing.

(Yes, a shutter that blocks microphones can be designed, but it's a hard problem.)

Exactly. As long as the LED is disable-able via software it's placebo.

Reply on news.ycombinator.com