Hacker News Reader

Comment by bussierem | Hacker News Reader

> How do you know? And, how do you know they will not do this silently in the future?

Because it's a literal hardware limitation. The device is built in a way that requires a wake word before any recording can possibly happen, thanks to it being built with 2 separate control boards. If they ended up maybe changing the wakeword to "the", then maybe they could "silently" listen to everything, but that would be caught pretty quick because the device would be "lit up" constantly (another _hardware_ thing), or someone would notice that it no longer responds to "Alexa" or "Google".

Seriously, a lot of people on HN need to do their damn homework about these devices before declaring them to be something they have been proven not to be. Packet sniffing and hardware inspection both instantly disprove all these conspiracy-theory nonsense claims that these devices are recording your every word.

View on HN

Those two separate control boards didn't stop my Amazon dot from acually recording ambient noise and uploading it to Amazon's systems. I know this because of the audio history they themselves provide! You can literally go back and play back all the audio recorded, and a great deal of it did not include questions. Further, there was also a report of being able to trigger audio recording without either activating the LED ring or using a wake word via a serial root console. While a third-party attacker is unlikely to use that method of access, nothing about the hardware actively prevents Amazon ftom triggering it that way. Likewise for Google.

And yes, I work on this stuff. Neither Google nor Amazon have the hardware limitations you suggest.

You are making an enormous amount of assumptions based on a semantic argument.

Echo devices only begin recording if they think they hear the wake word. Obviously this is less than straight-forward, hence the recordings that didn't follow the wake word (just examples of an Alexa device incorrectly thinking it heard it).

To suggest that a serial root console is a point of attack for an Echo device is bordering on insanity. You'd need a breakout board connected via the USB interface (not port, mind you) in order for this work-around to be effective. So yes, if a hacker had physical access to your device, time enough to solder on a breakout board, said third-party could record a variety of things.

But then, it's a whole hell of a lot easier to just install a mic in someones house and get the same effect, now wouldn't it?

> To suggest that a serial root console is a point of attack for an Echo device is bordering on insanity.

That was not what he said. He argues that Amazon/Google could remotely use a similar exploit (without direct access to the hardware) to start recording without lighting up the LED.

Nobody has EVER gotten root console access on an Echo device remotely, and the only successful "remote" exploit that didn't require soldering requires that the attacker and the victim are both on the same wifi network.

Please, feel free to explain how Amazon and Google could exploit that vulnerability (that has since been patched)? More importantly, I'd love to hear how they are going to pull this off and hide it, given network traffic will be a dead give away?

If what your suggesting is actually what he meant, that's even more absurd than attackers trying to do the same.

I'm quite confident Amazon has remote root on every Echo device. It's called a firmware update.

True enough. They could easily push a new update that would record every single thing you say, and despite not indicating anywhere on the device, it would take a matter of minutes before it was in the news because what they certainly can't do is hide network traffic.

Right, the bigger concern for me is targeted attacks. One user, especially a non-technical user, getting a "special" update pushed out.

As indicated in your previous comments, e.g. https://news.ycombinator.com/item?id=18616219 , you work for Amazon. It would be a better look if you disclosed this openly when commenting about Amazon.

It's easily located in my post history, however, I don't work with anything even remotely related to the Echo devices. My interest in this discussion is as a user, not as an employee.

It's an ethics issue. You have vested interest in Amazon's public perception as an employee. You can't try to divorce your comments from your relationship with Amazon and expect to still be taken seriously.

A simple disclosure would have lent your comments more credibility.

> Because it's a literal hardware limitation. The device is built in a way that requires a wake word before any recording can possibly happen [...]

Take note that Amazon Drop In [1] is a feature built around turning on the Echo mic remotely without a wake word. I don't think this feature could exist if there was a hardware limitation.

[1] https://www.amazon.com/gp/help/customer/display.html?nodeId=...

But doesn't the device light up when that happens?

I was just offering a counter to the hardware limitation claim. It's possible the device makes itself known during use, I haven't used this feature yet.

And it beeps, and the audio from the other end starts coming through the echo's speaker. There is just about no way to know someone dropped in on you.

But is this behaviour implemented in hardware or software?

This feature is configured via its software.

My understanding is that the light at the very least was hardware. Sound can be disabled.

Dropping in causes the Alexa to light up and play a tone, so not exactly stealthy.

These are software companies. These devices support OTA updates, including changing the activation word. It's trivial to change the activation word to empty or something innocuous. Ergo, there's no hardware limitation.

If your argument stems from "Google and Amazon would never do that," I do not trust any corporate entity to value my rights more than their ability to make a dollar.

How about the issue where Google’s devices were errantly recording everything due to a hardware issue - where the button override for the voice activation was stuck in the activated position.

People who think that there’s no way that Google and Amazon could be recording everything need to realize that this is also not true. Most of these “limitations” are software enforced, and that software is updated constantly.

This is the main problem that I see. Sure, I tested the packets, sniffed them, made sure it wasn't recording, etc, but then they push an update the next day. I don't think it's practical to monitor these devices all the time, and I haven't been asked to opt-in to an Echo update.

I also don't necessarily assume mal-intent on the part of the companies, but that doesn't mean there won't _ever_ be that intent. Trusting that all of these assumptions hold over time is hard.

> Trusting that all of these assumptions hold over time is hard.

This is the big point. You are not only trusting that the company as it is today is doing the right thing, but that the company will continue to do the right thing for so long as the device is in your house - and that they will do the right thing in perpetuity with your data (including if/when they sell the company down the road).

> This is the main problem that I see. Sure, I tested the packets, sniffed them, made sure it wasn't recording, etc, but then they push an update the next day. I don't think it's practical to monitor these devices all the time, and I haven't been asked to opt-in to an Echo update.

This is a problem with forced updates in general (I'm also thinking of Windows, Chrome, Chrome extensions, etc. here) that security experts seem completely blind to.

That said, note that even if the software didn't update, it doesn't mean it would have to send bad packets when you're actually observing. It could randomly start doing that once in a while after a few months.

"Malintent" can be a hard bar to clear, but it's clear beyond a shadow of a doubt that these companies view these devices as mechanisms to push forward their own interests and desires, in addition to my own. I won't even necessarily call that morally wrong, or at least, that line is very fuzzy. But it does mean that viewing them with a certain amount of suspicion is just rational, not crazytalk.

(It's true of cell phones too, of course, and I am engaged in constant activity to ensure the phone works for me, and not any of the many corporations that want to make it work for them. Turning off notifications, uninstalling certain apps after they've gone bad, ensuring permissions aren't too wide open, uninstalling default-installed apps and disabling others... it's a constant battle made worthwhile only by the fact that in the end, I really have mostly mastered my phone and it is working for me. I don't have one of these audio assistants because it is far less clear to me how to do that. Modulo being spied on by intelligence agencies, anyhow, although at this point I'm not sure how one could even escape that.)

Over a year ago Google removed the part of the hardware that caused that bug on the Home mini: https://www.theverge.com/circuitbreaker/2017/10/11/16462572/...

And so something like that can never happen again? Regressions are a very real thing, both in hardware and software.

I'm not sure how you would regress a button that physically doesn't exist anymore. Also, if you're that scared of future bugs that don't exist, then you should probably throw away your smart phone.

The entire top surface of the Google Home is a button (capacitive). Those kinds of sensors are just as susceptible to physical defects as mechanical buttons.

As a side note, whataboutism adds nothing of value to this discussion about the Google Home and Amazon Echo.

And the capacitive button doesn't trigger the listening hardware. Splitting hairs over the hardware specifications isn't proof that the bug is still a problem.

Also, talking about your contradictory behavior with your smartphone isn't whataboutism, unless you want to avoid addressing your hypocrisy, because smart phones are susceptible to the same blanket fears you have with homes/alexa. To critique only the latter, and not the former (which you use daily), is not fair.

> And the capacitive button doesn't trigger the listening hardware.

Per Google's own site: "Long press to trigger the Google Assistant."

I think the point is that bugs exist and will continue to exist: whether it's the same bug, a different one, mal-intent, negligence, or anything else. Sure, this one device won't solve every single problem out there, but should we not solve anything just because we can't solve everything?

Right, and my point is that bugs will exist for all devices, not just these. Applying the logic, "bugs could happen" to just these devices isn't rational because it applies to all all devices, especially smart phones. We shouldn't ditch devices because of future potential for bugs that don't exist yet.

"The device is built in a way that requires a wake word before any recording can possibly happen, thanks to it being built with 2 separate control boards."

This is a very technically naive interpretation of their hardware/software solution.

If the wake word were hard-coded into silicon then perhaps I would be charitable about your misunderstanding(s) - but of course it is not. The wake word is user-definable and can be changed to arbitrary sounds at any time.

Whatever hardware limitation(s) may exist are trivially worked around with software, which can be updated over the top of you at any time.

There's a widespread sentiment that current evidence of compliance to "doing right by users" should be viewed with circumspection. And it's fair to say Google's past behaviour raises doubts about the level of trust users should extend them.

What is a conspiracy theory about today's hardware, I have no trouble imagining is a planned or at least considered future iteration of their "service".

> Seriously, a lot of people on HN need to do their damn homework about these devices before declaring them to be something they have been proven not to be.

Based on what? Marketing copy? Eyeballing iFixit teardowns?

> but that would be caught pretty quick because the device would be "lit up" constantly (another _hardware_ thing)

Totally not buying it, unless you can show me the traces and discrete components that force power through the LED when signal from the microphone is allowed to reach the uC. If it's done in software, I'm not trusting it.

If you're making an argument of "trust the vendor because economics", you have to recognize how weak it is.

Do you (or anyone else with the same claim) have a citation for this?

I've spent some time reverse-engineering the echo microphone board, and while there is an interlock that prevents recording while the red mute button is lit (just the light under the button, not the ring), I didn't see anything that would prevent recording while the ring light was off.

> Because it's a literal hardware limitation.

Unless there is a separate out of band board with a relay I can hear or see (meaning, code alone can't enable something), then it really isn't a hardware limitation. The security controls and operations are in the code. The code can change or may already have silent monitoring capabilities. Nobody on HN could really answer whether or not this is the case. All we can do is speculate. If someone were required to put lawful monitoring code in place, they would not be allowed to discuss it here. The best anyone could do is decompile the code or get the source code for the firmware. Even then, there could be non-volital space that allows for updates.

Case in point, there have been malware packages that could enable your microphone and camera on the laptop without turning on the LED. This varied with camera model. Some power the LED when the camera has power. Microphones don't always activate an LED. There are a myriad of articles you can find providing examples of malware that can listen to cell phone microphones, laptop microphones without activating the LED.

> the device would be "lit up" constantly (another _hardware_ thing)

Unless the mic and lights are somehow wired together (they aren't), then this is really just more software which can be trivially updated away.

They are.

How so? Ultimately the mic is always on and listening for its keywords - if you look at the teardown of the Alexa on iFixIt, I don't even see any device other than the main CPU that would be capable of performing keyword recognition. Meaning the main CPU would have to be the thing then controlling the lights after the keywords are recognized...

The Google Home at least has a separate board with a microcontroller on it which could be used for keyword recognition, but I'm pretty sure they allow that to be updated for the sake of improving keyword recognition and there's no reason that an update couldn't disable the LEDs in the listen state as far as I can see.

Not a hardware guy, but couldn’t you tie the LEDs to whatever bus that connects the mic and the main CPU?

Yes, I don't mean to say it's impossible - just that you'd need an entirely isolated system to detect when data was flowing over that link which is physically connected in all cases and cannot be updated. I don't believe we see that in either the Alexa or Google Home, but I'd be happy to be mistaken if anyone's done a more in depth teardown of these systems.

And all of this is hinged on hoping you notice LEDs firing in the corner while you're having a conversation. Perhaps a more noticeable method should be used in cases like this. A forced "beep"/tone or something from an isolated circuit hardwired to the speakers.

As an alternate angle - Instead of trying to disable the light have it show the "I'm doing a software update" light pattern. I know I personally wouldn't give that a second glance

> If they ended up maybe changing the wakeword to "the", then maybe they could "silently" listen to everything, but that would be caught pretty quick because the device would be "lit up" constantly (another _hardware_ thing)

From pure technical perspective, can the device not be programmed to be waked by wakewaord “the” with the light off?

> "can the device not be programmed to be waked by wakewaord “the” with the light off?"

It absolutely can be.

I get that you believe this, and I even understand you repeating it to other people on the Internet. What I don't get is that your tone indicates that you are offended people don't believe what you believe... which also just happens to have been incorrect in the past and many others seem to think is provably possible in the future.

> Packet sniffing and hardware inspection both instantly disprove...

I'm under the impression that packet sniffing is useless with end-to-end encryption, but I could be wrong. I.e., you can tell that something is being sent, but you can't know what.

The theory is that we can still estimate how much data goes over the network. So if it were sending all audio to the cloud, we'd see.

It does however not exclude other information, like sending keyword flags, or storing audio fragments to send along with other messages later on.

Neither does it exclude the possibility of any "time-bomb"-type of features or future OTA updates altering the software's behavior.

If OP can show what they use to packet sniff those boxes, then life will be good and we can put the conspiracy theories to bed.

If they can't see all of the traffic, but just know where the traffic is going, then I don't think they did their homework.

You own the client. You can do anything to it. There is no way for encryption on the client to prevent you from inspecting the content.

Citation strongly needed.

I do understand that the wake word processing happens in a special kernel in a low power state, however....

The wake word is a trained kernel, it can be trained to listen for a huge set of things (as seen in the Pixel's passive song detection), so they would just train the kernel to detect a large targeted (marketing?) vocab.

about being "lit up" constantly? I'm not saying you are wrong, but I'd really like to see a citation that this is true. Is it true for both echo and home?

And while Packet Sniffing can disprove that it's listening and sending whole audio to the cloud, it can't disprove that it's listening for a huge set of "wake words" and toggling bits in other control messages to track users in more subtle ways.

> Because it's a literal hardware limitation.

Citation needed. Further, listening for a wake word and reacting to that is likely done completely in software: the fact it's even listening for a "wake word" means the hardware (microphone) is in fact always listening, it's just [presumably] not actually sending that audio to The Cloud (tm).

I don't own either of them but Siri and Google on my phone both require training when I first use them. Do these devices not? IF they do then isn't that proof they are re-programmable and could be programmed to respond to anything?

Good luck packet sniffing an encrypted text blob of your conversations the device is transcribing.

> Packet sniffing

The unauthorized recorded data can be sent encoded with/into the authorized data.

Reply on news.ycombinator.com