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.
And yes, I work on this stuff. Neither Google nor Amazon have the hardware limitations you suggest.
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?
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.
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.
A simple disclosure would have lent your comments more credibility.
Take note that Amazon Drop In  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.
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.
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.
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.
(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.)
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.
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).
As a side note, whataboutism adds nothing of value to this discussion about the Google Home and Amazon Echo.
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.
Per Google's own site: "Long press to trigger the Google Assistant."
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.
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".
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.
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.
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.
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.
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.
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.
From pure technical perspective, can the device not be programmed to be waked by wakewaord “the” with the light off?
It absolutely can be.
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.
It does however not exclude other information, like sending keyword flags, or storing audio fragments to send along with other messages later on.
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.
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.
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).
The unauthorized recorded data can be sent encoded with/into the authorized data.