No, there is a button to make the Echo stop listening.
If you want to prove me wrong, it should be incredibly easy to press the button and record the Echos network activity. If you’re right you’d still see network traffic. But nobody has been able to show this so far. I wonder why?
Yeah I read the other comments after making mine. However everyone keeps calling it a “physical” button, and I don’t think that’s accurate. It won’t be a physical switch that opens a circuit, it will be a button that operates a transistor that opens the circuit.
Still, I see no good reason to trust the device - especially in a medical setting.
This is disingenuous at best and incorrect at worst. The mute button on the Echo is just that, a button; it is not a switch. It is software-controlled and pushing it just sends a signal to the microcontroller to take some action. For instance, one action is to turn on the red indicator light; that’s definitely not physically connected to the mute button.
Maybe another response of pushing the button is to disable the transistor used for the microphone, but it’s more likely that it just sets a software flag for the algorithm to stop its processing of the microphone input signal. Regardless of which method it uses, the microcontroller could undoubtedly just decide to revert that and listen in, either disabling or not disabling the red light at the same time.
But I personally don’t think it listens in when muted. I don’t think it spies on us to target ads based on what we say around it. I’m not worried that the mic mute function doesn’t work as intended.
But I fully understand that it is fully capable of it, technically speaking.
I don’t know the internal workings of the echo, I was responding to a comment that said it “operates a transistor”. Which is way different than it being an input to a microcontroller.
If the button is just connected to a transistor, it’s not software controllable, since transistors are electronical devices that don’t interpret any software. A microcontroller does execute software. There’s a big difference.
Transistors are simple electronical devices. They don’t run software. You can control their inputs with another device (such a microcontroller) that does run software. You can also control their inputs with a button. You can’t control their output with software.
I don’t know how an Amazon echo is wired up, but if you just have a button connected to the gate of the transistor, it works basically the same as a mechanical switch.
Transistors have no registers. They have no arithmetic logical units. They have nothing. They are so simple they can be made up of less than 100 atoms. Transistors have to be connected electrically to other device. Any reverse engineer can trace what it is connected to and it’s behaviour cannot be programmed. If you know that it’s a transistor and you know the inputs, you can know the output. The same cannot be said for a device which runs software, you’d have to additionally know what that software does, which is incredibly more complicated.
Software is ran by microcontrollers. Transistors can be connected to microcontrollers. But they can also be connected to buttons. If there is no microcontroller, there is no software.
Which you could easily see by looking at the amount of traffic sent after unmuting, unless you believe that Amazon secretly found an infinite compression algorithm they use only in muted Echo devices.
Tbf to foobar, that should still give a falsifiable and testable data-difference if you are willing to alter your behaviour around experimentation for an extended period of time
Though, there are always more ways to hide traffic
Again: Which you could easily see by looking at the amount of traffic sent after unmuting, unless you believe that Amazon secretly found an infinite compression algorithm they use only in muted Echo devices.
You understand that sending more information means more traffic? Unless - as I stated - they found a perfect compression algorithm, you’d be able to tell.
I’m a little confused as to why you are being so condescending. Every time you say “this is so simple if you do X”. And then I say “what about Y?” And then you’re like “that’s obvious too, just do Z” and kind of insulting me, even though you did not account for it in your prior comment. And it becomes less trivial with each additional test.
Your first method involves simply checking if there is any traffic after muting. Your revised method involves additionally checking if there is any traffic for some period of time after muting (how long?). And now your third method involves doing the first two things as well as gathering data on the average amount of traffic in your requests generally and deciding whether subsequent traffic during requests after muting for an unspecified amount of time is significantly large enough to conclude it is sending information acquired during muting.
But if they send it a little bit at a time, or they just leak a small portion of it occasionally in some requests, I think it would be very challenging to conclude definitively one way or the other.
I’m actually aware that there is no infinite compression algorithm, so you don’t need to keep saying that. And to be honest it just makes you look like you are lacking imagination because it’s not the only way to make detection difficult as illustrated by my responses.
I’m a little confused as to why you are being so condescending. Every time you say “this is so simple if you do X”. And then I say “what about Y?” And then you’re like “that’s obvious too, just do Z” and kind of insulting me, even though you did not account for it in your prior comment. And it becomes less trivial with each additional test.
I’m writing the way I do because you’re bringing up points that are incredibly easy to disprove as if they’re some kind of gotcha. “They might store the data” seems like a good point until you remember that even that stored data has to be transmitted at some point. How would you have me reply to these non-arguments?
Your first method involves simply checking if there is any traffic after muting.
Because it’s sufficient to prove that the device doesn’t just not respond. That was the initial point I was replying to. Why do I have to find any possible counter-arguments when they weren’t brought up?
Your revised method involves additionally checking if there is any traffic for some period of time after muting (how long?).
Yes, because it’s sufficient to disprove the additional point you brought up. Just do it until the heat death of the universe if you want to be sure. You’re the one theorizing they might store the data locally. Create a full hypothesis, and I can tell you how to disprove it.
And now your third method involves doing the first two things as well as gathering data on the average amount of traffic in your requests generally and deciding whether subsequent traffic during requests after muting for an unspecified amount of time is significantly large enough to conclude it is sending information acquired during muting.
You make it sound like “gathering data on the average amount of traffic in your requests generally” is complicated, and like you don’t already have the data from the previous two points.
But if they send it a little bit at a time, or they just leak a small portion of it occasionally in some requests, I think it would be very challenging to conclude definitively one way or the other.
And you could still see this through statistical analysis.
I’m actually aware that there is no infinite compression algorithm, so you don’t need to keep saying that. And to be honest it just makes you look like you are lacking imagination because it’s not the only way to make detection difficult as illustrated by my responses.
It’s the only way your points make full sense. It’s a simple truth of the universe that transmitting more information requires transmitting more information. The only way to get around this is the aforementioned infinite compression algorithm. Any other method is detectable through statistical means.
It was never supposed to be a “gotcha”, it’s just the obvious question that arises based on what you said. I didn’t think my ideas were clever. Your thesis when you started this thread was that there was an easy way to be sure that the mute is real, and you gave it. You sound like a person who simply can’t stand to just say “oh right, I misspoke” or even just “ah yes, I oversimplified”, so you act like obviously everything I bring up was implied all along, with a touch of rudeness as punishment. Even though, again, your point about there needing to be a zero-compression algorithm made it seem like there was nothing else left to account for, even though there was.
I would not be surprised at all if there is a way to detect with high confidence whether the mute does what it should, and for all I know that has been done. I was really just wanting to hear what I was missing by bringing up the obvious questions that a non-security expert like me would wonder. It seemed like it couldn’t be as straightforward as you said, and through your responses in fact it isn’t. You really have to ask yourself what you were even trying to accomplish with posting on this topic at all based on your reaction to those very simple, non-threatening questions.
It was never supposed to be a “gotcha”, it’s just the obvious question that arises based on what you said.
And I gave the obvious answers to those obvious questions.
I didn’t think my ideas were clever. Your thesis when you started this thread was that there was an easy way to be sure that the mute is real, and you gave it.
Sorry, but that’s a mis-representation. Somebody said “Also muting it probably doesn’t stop it listening, it just stops its response.”, and I replied to that with a simple way to show it’s not the case. I didn’t bring in a thesis, I brought up a counter-argument.
You sound like a person who simply can’t stand to just say “oh right, I misspoke” or even just “ah yes, I oversimplified”, so you act like obviously everything I bring up was implied all along, with a touch of rudeness as punishment.
You’re free to show me where I went wrong, but I don’t see it. Somebody said “what if A?”, and I responded “it can’t be A due to X”. Then you came in “what if B?”, I said “it can’t be B due to Y”. Then you came in again and I responded again. Where did I supposedly oversimplify or mis-speak? People kept bringing up hypotheses, and I kept bringing up counter-arguments.
Even though, again, your point about there needing to be a zero-compression algorithm made it seem like there was nothing else left to account for, even though there was.
Yes, if someone makes a different argument, previous counter-arguments won’t fit. Seems pretty obvious?
I would not be surprised at all if there is a way to detect with high confidence whether the mute does what it should, and for all I know that has been done. I was really just wanting to hear what I was missing by bringing up the obvious questions that a non-security expert like me would wonder.
And I gave you answers for your “obvious questions”. It would help a lot if you formulate your questions as questions. You formulated them as arguments, to which I replied with counter-arguments.
It seemed like it couldn’t be as straightforward as you said, and through your responses in fact it isn’t. You really have to ask yourself what you were even trying to accomplish with posting on this topic at all based on your reaction to those very simple, non-threatening questions.
The answers to the questions you brought up are as straightforward as I said. The answer to other questions isn’t as straightforward, because I didn’t answer those questions.
When there isn’t any stored data to be sent, they could easily send fake/random data in requests though. So then it’s not detectable if data is stored and sent or not. How would you make up for that?
That’s actually a good point! Random data is unlikely since it would be noticable due to differences in size of the compressed traffic (random data doesn’t compress), but fake data would not be distinguishable from just looking at traffic.
Luckily there are still things you can do, like analyzing the firmware itself (especially when you can inject your MitM proxy cert). It has been done before, and it’s reasonable to assume such a technique would have been found by security researchers by now.
I’m not sure that’s the case. We have one at work and if it thinks you’re calling out to it repeatedly it will say out loud that its mic is off and that you have to enable it.
It might just be the part that listens for “Alexa” but that audio buffer is available to the device and it can do things with it.
Because - as I’ve explained in the comment you replied to - it’s pretty easy to check it for yourself. Unless you believe that an Echo has a secondary cellular connection that’s only used while muted, any traffic must go over your configured connection.
Just look at the amount of transferred data while it’s muted. If there is data (beyond extremely low background traffic) I’m wrong. If there is no data, you’re wrong.
This is not some hypothetical metaphysical principle we’re talking about, it’s a product that you can analyse yourself. Put up or shut up.
No, there is a button to make the Echo stop listening.
If you want to prove me wrong, it should be incredibly easy to press the button and record the Echos network activity. If you’re right you’d still see network traffic. But nobody has been able to show this so far. I wonder why?
Yeah I read the other comments after making mine. However everyone keeps calling it a “physical” button, and I don’t think that’s accurate. It won’t be a physical switch that opens a circuit, it will be a button that operates a transistor that opens the circuit.
Still, I see no good reason to trust the device - especially in a medical setting.
There’s not much difference between a direct switch and a transistor, both will cut the signal and neither is over rideable by software
This is disingenuous at best and incorrect at worst. The mute button on the Echo is just that, a button; it is not a switch. It is software-controlled and pushing it just sends a signal to the microcontroller to take some action. For instance, one action is to turn on the red indicator light; that’s definitely not physically connected to the mute button.
Maybe another response of pushing the button is to disable the transistor used for the microphone, but it’s more likely that it just sets a software flag for the algorithm to stop its processing of the microphone input signal. Regardless of which method it uses, the microcontroller could undoubtedly just decide to revert that and listen in, either disabling or not disabling the red light at the same time.
But I personally don’t think it listens in when muted. I don’t think it spies on us to target ads based on what we say around it. I’m not worried that the mic mute function doesn’t work as intended.
But I fully understand that it is fully capable of it, technically speaking.
I don’t know the internal workings of the echo, I was responding to a comment that said it “operates a transistor”. Which is way different than it being an input to a microcontroller.
If the button is just connected to a transistor, it’s not software controllable, since transistors are electronical devices that don’t interpret any software. A microcontroller does execute software. There’s a big difference.
A transistor is controlled by software so yes, it’s absolutely over rideable.
Transistors are simple electronical devices. They don’t run software. You can control their inputs with another device (such a microcontroller) that does run software. You can also control their inputs with a button. You can’t control their output with software.
I don’t know how an Amazon echo is wired up, but if you just have a button connected to the gate of the transistor, it works basically the same as a mechanical switch.
No, as I just said in the comment you replied to, it’s backwards. Software controls transistors.
The important difference is that a mechanical switch cannot be maliciously switched on by software. It has to be done physically and intentionally.
There is absolutely no requirement that a transistor be controlled by software. They can be controlled by physical switches.
Transistors have no registers. They have no arithmetic logical units. They have nothing. They are so simple they can be made up of less than 100 atoms. Transistors have to be connected electrically to other device. Any reverse engineer can trace what it is connected to and it’s behaviour cannot be programmed. If you know that it’s a transistor and you know the inputs, you can know the output. The same cannot be said for a device which runs software, you’d have to additionally know what that software does, which is incredibly more complicated.
Software is ran by microcontrollers. Transistors can be connected to microcontrollers. But they can also be connected to buttons. If there is no microcontroller, there is no software.
I don’t understand what any of that has to do with this conversation.
Well, you claim that transistors can be controlled by software, and I claim that it is no more capable to run software than a mechanical switch.
If the Echo stored the audio and then sent it sometime after you unmute, it would still pass your test.
Which you could easily see by looking at the amount of traffic sent after unmuting, unless you believe that Amazon secretly found an infinite compression algorithm they use only in muted Echo devices.
Unless some or all of it was sent along during the next time you actually do a voice command.
Tbf to foobar, that should still give a falsifiable and testable data-difference if you are willing to alter your behaviour around experimentation for an extended period of time
Though, there are always more ways to hide traffic
Again: Which you could easily see by looking at the amount of traffic sent after unmuting, unless you believe that Amazon secretly found an infinite compression algorithm they use only in muted Echo devices.
You understand that sending more information means more traffic? Unless - as I stated - they found a perfect compression algorithm, you’d be able to tell.
I’m a little confused as to why you are being so condescending. Every time you say “this is so simple if you do X”. And then I say “what about Y?” And then you’re like “that’s obvious too, just do Z” and kind of insulting me, even though you did not account for it in your prior comment. And it becomes less trivial with each additional test.
Your first method involves simply checking if there is any traffic after muting. Your revised method involves additionally checking if there is any traffic for some period of time after muting (how long?). And now your third method involves doing the first two things as well as gathering data on the average amount of traffic in your requests generally and deciding whether subsequent traffic during requests after muting for an unspecified amount of time is significantly large enough to conclude it is sending information acquired during muting.
But if they send it a little bit at a time, or they just leak a small portion of it occasionally in some requests, I think it would be very challenging to conclude definitively one way or the other.
I’m actually aware that there is no infinite compression algorithm, so you don’t need to keep saying that. And to be honest it just makes you look like you are lacking imagination because it’s not the only way to make detection difficult as illustrated by my responses.
I’m writing the way I do because you’re bringing up points that are incredibly easy to disprove as if they’re some kind of gotcha. “They might store the data” seems like a good point until you remember that even that stored data has to be transmitted at some point. How would you have me reply to these non-arguments?
Because it’s sufficient to prove that the device doesn’t just not respond. That was the initial point I was replying to. Why do I have to find any possible counter-arguments when they weren’t brought up?
Yes, because it’s sufficient to disprove the additional point you brought up. Just do it until the heat death of the universe if you want to be sure. You’re the one theorizing they might store the data locally. Create a full hypothesis, and I can tell you how to disprove it.
You make it sound like “gathering data on the average amount of traffic in your requests generally” is complicated, and like you don’t already have the data from the previous two points.
And you could still see this through statistical analysis.
It’s the only way your points make full sense. It’s a simple truth of the universe that transmitting more information requires transmitting more information. The only way to get around this is the aforementioned infinite compression algorithm. Any other method is detectable through statistical means.
It was never supposed to be a “gotcha”, it’s just the obvious question that arises based on what you said. I didn’t think my ideas were clever. Your thesis when you started this thread was that there was an easy way to be sure that the mute is real, and you gave it. You sound like a person who simply can’t stand to just say “oh right, I misspoke” or even just “ah yes, I oversimplified”, so you act like obviously everything I bring up was implied all along, with a touch of rudeness as punishment. Even though, again, your point about there needing to be a zero-compression algorithm made it seem like there was nothing else left to account for, even though there was.
I would not be surprised at all if there is a way to detect with high confidence whether the mute does what it should, and for all I know that has been done. I was really just wanting to hear what I was missing by bringing up the obvious questions that a non-security expert like me would wonder. It seemed like it couldn’t be as straightforward as you said, and through your responses in fact it isn’t. You really have to ask yourself what you were even trying to accomplish with posting on this topic at all based on your reaction to those very simple, non-threatening questions.
And I gave the obvious answers to those obvious questions.
Sorry, but that’s a mis-representation. Somebody said “Also muting it probably doesn’t stop it listening, it just stops its response.”, and I replied to that with a simple way to show it’s not the case. I didn’t bring in a thesis, I brought up a counter-argument.
You’re free to show me where I went wrong, but I don’t see it. Somebody said “what if A?”, and I responded “it can’t be A due to X”. Then you came in “what if B?”, I said “it can’t be B due to Y”. Then you came in again and I responded again. Where did I supposedly oversimplify or mis-speak? People kept bringing up hypotheses, and I kept bringing up counter-arguments.
Yes, if someone makes a different argument, previous counter-arguments won’t fit. Seems pretty obvious?
And I gave you answers for your “obvious questions”. It would help a lot if you formulate your questions as questions. You formulated them as arguments, to which I replied with counter-arguments.
The answers to the questions you brought up are as straightforward as I said. The answer to other questions isn’t as straightforward, because I didn’t answer those questions.
When there isn’t any stored data to be sent, they could easily send fake/random data in requests though. So then it’s not detectable if data is stored and sent or not. How would you make up for that?
That’s actually a good point! Random data is unlikely since it would be noticable due to differences in size of the compressed traffic (random data doesn’t compress), but fake data would not be distinguishable from just looking at traffic.
Luckily there are still things you can do, like analyzing the firmware itself (especially when you can inject your MitM proxy cert). It has been done before, and it’s reasonable to assume such a technique would have been found by security researchers by now.
I’m not sure that’s the case. We have one at work and if it thinks you’re calling out to it repeatedly it will say out loud that its mic is off and that you have to enable it.
It might just be the part that listens for “Alexa” but that audio buffer is available to the device and it can do things with it.
This is the funniest thing I’ve read today (though I’m not sure if it is a joke).
I just tried it with mine, it doesn’t react in any way.
Aww, you actually believe that!
Shouldn’t take you more than 5 minutes to prove me wrong. Please do!
It shouldn’t take me more than 5 minutes? Why’s that?
Because - as I’ve explained in the comment you replied to - it’s pretty easy to check it for yourself. Unless you believe that an Echo has a secondary cellular connection that’s only used while muted, any traffic must go over your configured connection.
Just look at the amount of transferred data while it’s muted. If there is data (beyond extremely low background traffic) I’m wrong. If there is no data, you’re wrong.
This is not some hypothetical metaphysical principle we’re talking about, it’s a product that you can analyse yourself. Put up or shut up.
And I can do that all in 5 minutes without owning one?
Easily. The device doesn’t care who owns it, you can use one owned by another person.
I don’t know anyone who owns one either.
But go ahead, do your experiment and report back. Should only take you 5 minutes to prove your claim.
Why should I do it, when plenty of people have already done so, and reported the results I talked about?