[HN Gopher] Amazon Echo Flex: Microphone mute button appears to ...
___________________________________________________________________
Amazon Echo Flex: Microphone mute button appears to be real and
functional
Author : parsecs
Score : 422 points
Date : 2021-01-12 04:26 UTC (18 hours ago)
(HTM) web link (electronupdate.blogspot.com)
(TXT) w3m dump (electronupdate.blogspot.com)
| jojobas wrote:
| The implication is that the microphone emits completely no signal
| without power and doesn't have any capacitor to last even a few
| seconds.
|
| Surely the most valuable data is just after the mute is turned
| on?
| mlyle wrote:
| There's no massive electrolytic capacitor that would be needed
| to power it for a few seconds.
|
| It's gonna be pretty damn fast. Standard ceramic decoupling
| cap-- very likely 0.1uF-- right next to it. 1/2 C V^2 at 3.3V
| is 0.5 microjoules. If the entire energy in the capacitor can
| go to effectively power the microphone (it can't), and the
| typical power consumption of a MEMS microphone is about 1
| milliwatt, it might keep working for about 500 microseconds.
| jeffrallen wrote:
| The fact that the mike defaults to on after power on is
| completely understandable from a user interface perspective, but
| from a security perspective it makes the mute switch useless.
| Why? Because any attacker that has penetrated far enough to be
| able to control the SOC in order to snoop can also trigger a SOC
| reset in order to make sure that the mike is enabled before they
| start snooping.
|
| A physical switch would have been a better choice, if it was
| actually for security instead of security theatre.
| rahimiali wrote:
| The R line for the flip flops goes to the SoC, but we don't
| know if it's tied to SoC's reset line or if it's a GPIO on the
| SoC. In the former case, you'd have to reset the SoC to turn on
| the mic. In the latter, you can just turn on the mic without
| reset. In either case, the LED always shows the true state of
| the mic.
| dvfjsdhgfv wrote:
| > The fact that the mike defaults to on after power on is
| completely understandable from a user interface perspective
|
| A compromise would be to play a message after turning the
| device on, requiring user to take action and unmute it or leave
| muted. This shouldn't be a problem in most scenarios as Echo is
| meant to be powered once and run for a long time, so it would
| be just a minor inconvenience.
| lemonspat wrote:
| > would be to play a message after turning the device on
|
| It does this already
| kylegordon wrote:
| I'm curious as to what the state would be after a firmware
| upgrade?
| jstanley wrote:
| At least it sounds like the red light would go out in this
| case, so you'd have some indication that something is up.
| cyphar wrote:
| That assumes you check whether the mute light is active on a
| fairly regular basis. If you just turn it off and don't check
| on it, the light is pretty much useless as an indicator.
| lemonspat wrote:
| The boot up sequence does an audible musical tone and says
| "Hello", so an attacker is not silently going to reboot it
| and listen in
| kevin_thibedeau wrote:
| The parallel flops are probably hardening against bit flips from
| ESD events. There aren't any other active protection devices and
| phantom flips probably showed up at some point during testing of
| earlier prototypes.
| spicybright wrote:
| I'm honestly surprised they went that far, and happy they did.
| faeyanpiraat wrote:
| I think accidental unmuting due to random events would
| translate into "theyare listening to me" in their average
| customer's mind, and would be a pr disaster. Compare the cost
| of that to an extra component, and the surprise goes away.
| sokoloff wrote:
| There's no "extra component" in the physical design. Both
| flip-flops are in the single 74x74 package and if you're
| only using one, you have to drive the other to a known
| state anyway, so why not use them both anyway?
| faeyanpiraat wrote:
| Even better
| [deleted]
| colejohnson66 wrote:
| Maybe because they had a second flip-flop and CMOS is sensitive
| to floating inputs? So they just decided to use both in
| parallel? Just a guess.
| sdfaeagaca342 wrote:
| I'm also worried about echo devices scanning my home network
| maigret wrote:
| Then don't buy one.
| PeterStuer wrote:
| With Alexa and it's ilk being integrated in ever more home
| electronic devices, not buying one is becoming increasingly
| impossible.
| mvanbaak wrote:
| Put them on their own network, make sure that network is
| not routed/connected with the internet.
|
| Or, if possible, dont connect to a network at all.
| PeterStuer wrote:
| There is ISP provided 'free roaming' wireless internet
| access nearly everywhere here. Very hard to block devices
| that really want and have deals with ISP's from accessing
| the internet even if your own network is secured.
| nisa wrote:
| sed -i 's/impossible/inconvenient/g'
|
| The power of convenience is probably also the reason to
| place a megacorp microphone in your home in the first
| place.
| PeterStuer wrote:
| Finding out whether an 'assistant' is present is not
| always straightforward form the product information
| before you buy.
| bonoboTP wrote:
| Red light used to indicate recording, traditionally.
|
| I'd expect the light to be green when I'm safe from spying.
| sokoloff wrote:
| On conference room phones (polycom spiders and similar), red
| usually indicates muted.
|
| From an end user mental model perspective, I think Echos are
| closer to that than to recording studio equipment. "Normally,
| to use this device, I speak to it and it warns me when that
| function is disabled."
| jannes wrote:
| Agreed. The red LED seems to be a conscious choice to indicate
| something that you need to get rid of (like those notification
| badges on iOS app icons or the unread indicator on Facebook).
|
| This is especially jarring as the rest of Alexa LEDs are all
| blue.
| [deleted]
| CamperBob2 wrote:
| Not sure why this was voted down, as that's the way I'd expect
| it to work as well.
|
| The red light should flash or pulsate when recording, in fact.
| Otherwise, people without good color vision might miss the cue.
| magicalhippo wrote:
| While a multi-color LED would be preferable, if only a single
| LED could be spared then it's better that it's on to indicate
| mic is off.
|
| Otherwise the LED could fail and you wouldn't be able to tell
| if the mic was on.
|
| As is, you assume the mic is on if the LED fails, which is
| preferable from a privacy point of view.
| [deleted]
| jodrellblank wrote:
| The parent comment is a "hurr de hurr it should be green when
| I'm PROTECTED from SPYING" comment. From the point of view of
| a normal person who bought it _for_ the Alexa functions, is
| GREEN for "stop" and RED for "go" honestly the way round
| you'd expect it to work?
| plumeria wrote:
| My 2015 Macbook turns on a green LED when the camera is
| recording.
| meehatpa wrote:
| All cameras should also have this.
| bayindirh wrote:
| IIRC Apple hardwires camera LED to enable pin for some time
| now. You can't even disable the LED even if you tamper with the
| camera firmware.
|
| Old Logitech Pro 9000 is the exact opposite. You can control
| the LED independently of the camera state.
| ncmncm wrote:
| We have been over this before: if you want to take
| surreptitious images on Apple, you operate the camera at a
| low enough duty cycle that it doesn't look like it's on.
|
| It could have been wired to indicate recording for a minimum
| of a second after each image capture. But it wasn't.
| shaicoleman wrote:
| Same with the Logitech Brio. You can turn off the LED while
| recording.
| WClayFerguson wrote:
| It's likely there are microphones in Echo that even an
| electronics expert can't "recognize" as a microphone. Any object
| that is flimsy and can 'vibrate' due to sound, can have it's
| position used to alter an electrical signal, and anything
| monitoring that signal can convert the signal easily back into
| sound. Even a non-data carrying wire with current can do this.
| parsecs wrote:
| I don't know about that. Yeah, ceramic capacitors in particular
| exhibit strong piezoelectric effects, but you'd need some sort
| of silicon to amplify the signal. I think electronic _experts_
| should be able to discover any sketchiness like that through
| thorough inspection and reverse engineering.
| WClayFerguson wrote:
| I'm a mechanical engineer myself. I've built microphones
| before in a college laboratory where all we used (proved) was
| "any object that vibrates from sound, which can be used to
| alter an electrical current, can be turned back into sound"
|
| Even the most basic form of digital audio stored as PCM
| (redbook, etc) is actually nothing but a file where every
| data-point in the file is an integer representing the
| 'magnitude' of a disturbance during that short
| milli/microsecond of time. Any vibrating 'disturbance' is the
| very definition of "sound" itself too.
| parsecs wrote:
| I'd consider myself an electrical engineer. How do you
| suppose you would transform and capture those vibrations to
| electrical signals with enough fidelity? I'm aware of
| techniques like perhaps laser diode self mixing. How will
| you do it in a way that cannot be detected even by
| _experts?_
|
| What I'm getting at is: how do you capture those signals
| without the use of obvious silicon devices (so no MEMS or
| opamps or whatever)? I'd imagine you have to hide it in
| software somehow. Then how do you acquire that signal? A
| simple analog input pin to the ADC of a cheap
| microcontroller is not good enough.
| WClayFerguson wrote:
| Right, the fidelity is not that good, when just sampling
| arbitrary vibrating objects. For example a simple
| accelerometer attached to the center of a lamp shade
| might create an intelligible signal, but one attached to
| a heavy table might not. Remember, AI can build speech
| from a very noisy signal, however.
|
| To pick up a better signal you need either a large flat
| or concave object (like even a computer case), or else
| something small and flimsy. You may know that even
| shining a laser pointer at the window of a building can
| pick up sound from a mile away simply by using a
| telescope to capture video of it and then let video
| processing detect the miniscule jostle in position due to
| the vibrating window. That trick has been used for
| decades, and works well.
|
| But yes _recording_ stuff secretly from an electrical
| device means you need either computer microcode or
| software secretly onboard that is recording signal
| variations that emerge from these physical vibrations,
| but there is almost no way, even after full disassembly,
| that even an electronics expert can necessarily detect
| this setup.
| chaboud wrote:
| Disclosure: I'm an Amazon Devices PE, but not on Alexa devices.
|
| Jeff (and others) have spoken publicly about this in the past,
| and this teardown is correct. The hardware is designed such that,
| if the privacy LED is on, the microphone is unpowered. In order
| to compromise that, one would need to physically alter/damage the
| hardware.
| Daho0n wrote:
| AFAIK a reboot would trigger a reset from mic off to mic on. If
| true that is a very poor choice for a privacy switch.
| dvdkhlng wrote:
| Also a minor hardware re-design may change mic switch
| behaviour in the future without that change being noticeable
| to the buyer. You'd really need regular tear-downs of a
| sufficient sample-size of devices to make sure that you can
| actually trust newly bought devices with sufficiently high
| confidence.
| mhaymo wrote:
| It depends how paranoid you are. If you believe your audio
| is so valuable that Amazon would create a separate hardware
| model for you and those like you, and would succeed in
| keeping that a secret, then yeah you still shouldn't buy an
| Echo. You will also not want any other always-on devices
| with microphones and network connections, like a phone or
| laptop. 99.9% people are not in this category.
| cool_dude85 wrote:
| I think you may not be worried about targeted attack here
| necessarily.
|
| Suppose for example that Amazon wants to know how many
| people talk about some topic or brand, and wants to sell
| that information, but they think that the mute switch
| will get in the way of collecting the data.
|
| All it would take is a relatively small sample - maybe
| 1/1000 Alexas randomly built in such a way that the mic
| can't be muted - and they would be able to sell these
| aggregated statistics with reasonable confidence
| intervals.
|
| Not that I think this is happening, but it is a possible
| reason I might not trust a single teardown, and it
| doesn't require worrying about a targeted attack against
| me personally.
| michaelt wrote:
| Presumably the threat isn't a targeted attack by Amazon,
| but rather that the the hardware mute will get 'value
| engineered' away in the future to save money.
| Johnny555 wrote:
| My Echo Studio preserves the mute state on reboot (I just
| tried it -- I usually keep it muted since I mostly just use
| it as a smart speaker for Spotify). So I don't know if that
| makes it more safe or less safe if the mute state can be set
| either way by the software
| appleflaxen wrote:
| Your statement really isn't any different than saying "Amazon
| says the mute button is real".
|
| Which we already knew.
|
| The problem is that many people don't trust the good faith of
| the company you work for, and by extension they won't trust you
| either.
| some_random wrote:
| You very clearly are not the target audience for this device.
| Jon_Lowtek wrote:
| Many people trust this "word of mouth" way of telling
| stories, but for those who know rhetorics this pattern should
| raise a warning. _(it is not my intention to accuse, just
| doing some rhetoric deconstruction)_ The "so the teardown is
| correct" part is backwards. Calling the billionaire ceo by
| his first name tries to create an aura of personal knowledge.
| At the core it is an _argumentum ab auctoritate_. Honestly
| this is worse than "amazon said so" because it is veiled.
| 1f60c wrote:
| If you don't trust the mute button, don't buy an Echo.
| tobr wrote:
| Which "Jeff" are you referring to here, and if it's Bezos, why
| are you using his first name as if we all hang out with him on
| a regular basis?
| jeffrallen wrote:
| THERE CAN BE ONLY ONE. (Too bad it's not me.)
| blackoil wrote:
| Maybe in company he is referred on first name basis. In my
| company we always refer CEO by first name, even when we had
| never met him personally.
| mabbo wrote:
| Strangely enough, it is totally normal at Amazon to simply
| call Jeff Bezos "Jeff".
|
| He even has the jeff@ email address.
| sneak wrote:
| > _The SOC (system on chip) controller seems to be connected to
| the flip flop resets, which makes sense as the product powers
| on with the microphone enabled as default...._
|
| To compromise it, one just needs control of the SOC (which
| Amazon has) to turn the light off and the mics back on.
| dom96 wrote:
| What's the PE in "Amazon Devices PE" stand for?
| chaboud wrote:
| Sorry for the jump straight to the abbreviation. "PE" stands
| for "Principal Engineer".
|
| Amazon's Software Engineer level progression is:
|
| SDE1->SDE2->SDE3->PE->SPE (Senior Principal, Director
| Level)->DE (Distinguished Engineer, VP Level).
| unwind wrote:
| My random guess would be "product engineer [1].
|
| [1] https://en.wikipedia.org/wiki/Product_engineering
| e9 wrote:
| Why not physical debounce switch? I get it is more expensive
| but no one would question it twice.
| gary_0 wrote:
| There'd be no point: a suspicious end user would still need
| to test/dismantle the doodad connected to the power lines to
| see that it behaves as expected and doesn't contain anything
| nefarious. So might as well use a relatively standard
| electronics design.
| texasbigdata wrote:
| What's wrong with their solution / implemention? Why do they
| have to defend against a tear down?
| aeternum wrote:
| The design allows the SOC to unmute via software. This is a
| significant security vulnerability.
|
| Yes the light will turn off, but who constantly monitors
| the lights on their devices?
| _flux wrote:
| So I guess this calls for a led monitor project!
| systemvoltage wrote:
| In order to use a physical debounce switch, there are several
| steep challenges. You can imagine OP presenting to an
| audience of 14 people at Amazon Devices group with a slide
| titled "New BOM proposal" entailing 6 million devices x
| [$0.0273 (switch price at 100k qty) + $0.05 assembly cost] +
| $50k engineering NRE (650 engineering hours) + $35k tooling
| NRE + $22k FCC re-cert + 7k ESD cert + another $100k in
| various certifications from continental EU, JP, Australia, UK
| and Brazil. At the end, OP has to say "We love our customers,
| don't we?" followed by an awkward silence. RIP OP.
| CommieDetector wrote:
| Don't scare the "Full Stack Developer" children with the
| reality of hardware manufacturing.
| stdbrouw wrote:
| You'd make this change alongside others that would require
| recertification and retooling anyway, and presumably a lot
| of those engineers have a full-time contract so that's not
| an additional cost. Overall assembly cost may be higher or
| lower depending on those other changes. It really is just
| that $0.0273 for the switch, which compared to the very
| steep marketing and branding challenge of convincing
| privacy-minded folks that Amazon isn't evil, is nothing.
|
| I love how people on HN can rationalize every imaginable
| bad thing, and figure out reasons why the good thing is
| really, truly impossible. Qwerty is superior to any
| alternative, healthcare in the US is completely rational,
| we can't build cheap tunnels but at least we build the best
| tunnels, English spelling is a feature not a bug, as are
| Imperial units by the way, and college education is
| optimally priced.
| some_random wrote:
| >It really is just that $0.0273 for the switch, which
| compared to the very steep marketing and branding
| challenge of convincing privacy-minded folks that Amazon
| isn't evil, is nothing.
|
| Looking at this thread, there is no amount of money nor
| action they could take that would convince people here to
| buy an echo, so honestly why bother?
| [deleted]
| sokoloff wrote:
| I agree with you on excluding certification costs if
| you're going to respin the device anyway, but part,
| assembly, and NRE labor are real costs of this change.
| dvfjsdhgfv wrote:
| Which should remind companies releasing similar products
| in the future that it's cheaper to design them with
| built-in privacy features rather than patch them as an
| afterthought.
| Kalium wrote:
| You're absolutely right.
|
| That said, I think companies also have to consider the
| saleability of privacy features. How many Echos would
| you, personally, buy if they had a mechanical switch? How
| many people do you think would make the same decision?
| How does this stack up against the change in failure
| rates from a physical switch?
|
| Again, you're completely correct. It's cheaper to design
| in privacy features up front. I can see some wrinkles
| that make the question more subtle, though.
| ovi256 wrote:
| Engineers, with contracts or not, have about 2200-2500
| hours to spend per year. Those hours can presumably be
| allocated to this task (that doesn't add any new
| capability) or to a task that adds capabilities (which
| will bring in new revenue).
| bald42 wrote:
| 2200-2500h? Where did you pull that number from? That's
| like 6 days per week with no vacation.
| stdbrouw wrote:
| Clearly it does add a new capability: it gives people an
| additional assurance that the mic is muted in a tamper-
| proof way whenever the switch is toggled, which is
| something that according to the article many are
| currently wary of.
| panta wrote:
| It's $0.11 per device. If the change was merged with
| another batch of changes, it would be just the $0.07 for
| switch + assembly.
| mhh__ wrote:
| Isn't that all back of the sofa change for Amazon, though?
| Less than a cent per device is still a fraction of what it
| costs overall.
|
| You could use this logic to shun literally any improvement
| to the device not done in software.
| Uhhrrr wrote:
| OP should also Insist On The Highest Standards and remind
| them that OP is Right, A Lot.
| systemvoltage wrote:
| Then OP sees newsflash on TechCrunch "Amazon Echo Flex v2
| is failing in low humidity conditions". Goddamn it,
| Andrew (at the reliability lab). OP goes home and opens a
| bottle of Amazon basics wine.
| buran77 wrote:
| This comment along with your previous one give the
| impression that in effect any solution that is favorable
| for the user is not only going to "cost too much to do
| just for the customers" but is also bound to be less
| reliable. It's how every privacy invasion or abuse of
| position of the past decade+ has been justified: "we made
| the product cheaper and better for you, any change will
| cost a lot and break it".
|
| Because yes, this can be used to justify close to
| anything that is in the interest of the company even if
| it's to the customer's disadvantage. Those features
| usually bring money to a company so removing them would
| be a loss. On top of that you can always attach that
| generic claim that any change will cause the system to
| implode and will also make your cat feral.
|
| Well, some of that may be true but it doesn't mean we
| should use it as a justification to keep doing things
| like that. Products can be built with the consumer's best
| interest in mind at little additional cost if any. The
| problem is the consumer's best interest usually brings in
| less money.
| dvfjsdhgfv wrote:
| Sometimes it gets absurd. You can hardly buy any modern
| laptop with a hardware camera switch. It's as if laptop
| manufacturers were completely blind what number of people
| uses a hardware solution in order to render their laptop
| cameras unusable when _they_ want it. The same group of
| people would love to be able to do the same with their
| built-in mics (not just in laptops, but also phones). We
| 're not talking about clueless folks but all kinds of
| people, including tech-aware ones like Zuckerberg.
| Nevertheless, mobile device manufacturers remain deaf and
| pretend the problem doesn't exist. And Librem is the
| exception that proves the rule.
| omnicognate wrote:
| Do you know if the same is true of the microphone button on the
| FireStick remote? Been debating with myself whether to remove
| the mic from it.
| bobuk wrote:
| But there's still a security flaw in this method. If somebody
| from Amazon will decide to record you, they just send a reboot
| command to Echo. After reboot mic's state will be changed back to
| normal I.e. powered.
| johnghanks wrote:
| Jesus - does everyone on this site live in a bunker using only
| candle light? Tip: you're insignificant and nobody at Amazon
| (or any company, for that matter) cares enough to spy on you.
| mlyle wrote:
| Yes, but at least this turns the light off and the light is
| stuck off (and can't be turned back on by software even if they
| decide to stop listening).
| aeternum wrote:
| Sure but it's still a bad design. If the device ever loses
| power, or restarts for any reason while the mute is engaged
| an informed user must accept a non-zero probability that
| their privacy was invaded.
|
| I have wireless headphones that work like this and it's a
| terrible design. If they go out of range temporarily, they
| unmute. It makes the 'hardware' mute functionality absolutely
| useless since it cannot be relied upon to stay muted.
| mlyle wrote:
| Short of a switch that is sticky when powered off, or a
| design that comes up muted... or excessive wizardry to
| persist state, this is non-negotiable, though.
| astura wrote:
| >switch that is sticky when powered off
|
| This is a long solved problem, a lever switch. Laptops
| (usually enterprise laptops) sometimes have them to turn
| on/off wireless communication.
|
| https://ux.stackexchange.com/questions/34956/who-needs-
| an-ex...
| ashtonkem wrote:
| Slider switch solves this problem. They're well known for
| maintaining their state between reboots.
| aeternum wrote:
| Physical switches for mute are underrated, think of all
| the conference call time that could be saved (and
| embarrassing moments avoided) if laptops had physical
| mute switches.
| harrisonjackson wrote:
| In that scenario, couldn't they just send an unmute command?
| 867-5309 wrote:
| in the same vein, what about the overlooked 1mm x 1mm chip that
| holds logic such as {{ if red_led==active then
| pushAudio('udp://amazon.com/jeffsBathroomSpeaker') }}
| dmix wrote:
| Considering the countless chips on most standard SoCs this is
| the correct answer. And presumably what the NSA does when
| they reroute your Dell or MacBook for an overnight session in
| a sealed off room at the post office.
|
| Doesn't even need to be at Amazon's factory in China of where
| ever. But that is largely feasible too.
|
| The difficulty is more about data exfiltration. Has to be
| appended to some real 'normal' request the next time a
| legitimate use of the mic is made, then piggybacks uploads on
| that connection.
|
| Recording all times when a voice is heard would also
| massively increase the payload sent to the server. If you
| were just passively network monitoring it could stick out.
| Which is not something nation states want.
|
| Forget these smart home mics, if I was a nation state I'd
| just stick with the mobile phones and laptops every person
| uses.
|
| People are already paranoid about their Alexas inherently
| (and far more likely to potentially care to look) making them
| a poor target for hacking. It's far more useful to turn the
| thing they carry around with them 24/7 into an active
| microphone with GPS, and plenty of more exfiltration
| possibilities with any mobile and desktop OS network traffic.
| mlyle wrote:
| Unless it has a microphone itself, that's difficult, because
| the actual microphone is depowered.
| skzv wrote:
| What does it mean for a microphone to be depowered? Doesn't
| the movement of the diaphragm induce a current, which is
| amplified- so it's the microphone amplifier that's
| depowered? Are we assured that the current produced by the
| diaphragm is too weak to reconstruct audio, even if it's
| very noisy?
| mlyle wrote:
| It's a MEMS microphone: silicon electromechanical device
| + amplifier in one package.
|
| First, this generally means that when depowered, the
| output signal line is connected to ground by the ESD
| protection path.
|
| Second, the actual mechanism which picks up the audio is
| generally variably capacitive-- a few picofarads-- in
| MEMS mics, and requires a pretty high bias (~15-200V)
| voltage to induce a usable signal for the in-package
| amplifier to be able to pick up the audio.
|
| To not only have the in-package amplifier turned off, but
| also no significant bias voltage across the microphone
| electrodes, and somehow pick this up on the other side of
| the trace would be somewhat miraculous.
| skzv wrote:
| Great, thanks for the detailed and informative
| explanation.
| knaik94 wrote:
| From using an echo at home, the unmuted state is only during
| the bootup process during which there's no processing or
| recording of audio going on anyway. If it shutdown muted mine
| starts up muted, even if the power cord is removed.
| beervirus wrote:
| > the unmuted state is only during the bootup process during
| which there's no processing or recording of audio going on
| anyway
|
| Is there any reason to believe that there's no processing or
| recording going on?
| mlyle wrote:
| Is this the Echo Flex? The pictured schematic appears to
| disallow software re-muting.
|
| Otherwise, all this hardware protection is moot (mute? ;),
| because you can listen for a few seconds, and then turn the
| mute light back on.
|
| Or you can even toggle them back and forth really quick, and
| turn the light half on and keep the microphone's power pin
| capacitor charged.
| Prcmaker wrote:
| Colour me impressed! I would have expected a digital pin be used
| to control the microphone in software, which I wouldn't have been
| nearly as satisfied to see. Really nicely presented breakdown
| too.
| mlyle wrote:
| > Colour me impressed! I would have expected a digital pin be
| used to control the microphone in software
|
| Yup, and even if the same pin drives both the LED and the
| microphone power switch, there's various attacks (e.g. high
| frequency PWM 75% duty cycle-- enough to light the LED to
| nearly full brightness, but also probably enough to keep the
| mic bypass capacitor nearly fully charged).
|
| Since the SOC can only turn off mute, and not turn it back on,
| any attempt to eavesdrop would leave evidence (a mute LED left
| off).
| cbradford wrote:
| Anyone that invited one of these spying devices into their home
| gets what they deserve.
| teruakohatu wrote:
| Tldr; it is real.
| markdown wrote:
| Thanks. Annoying that clickbait titles are allowed here.
| speedgoose wrote:
| The title gives all the information you need : https://en.wik
| ipedia.org/wiki/Betteridge%27s_law_of_headline...
|
| If it was not a real mute, it would not be a question in the
| title but a statement such as "Amazon Echo Flex Teardown: The
| Microphone Mute is Fake".
| tolbish wrote:
| > Like similar "laws" (e.g., Murphy's law), it is intended
| to be humorous rather than the literal truth.
| speedgoose wrote:
| For sure.
| jobigoud wrote:
| The title is not a yes/no question. You can't answer "is it
| real or fake?" by "no", the law doesn't apply and you have
| to take the bait to get the answer.
| speedgoose wrote:
| You got the point, if it was fake the title would very
| very likely be different.
| coldtea wrote:
| The writers don't write for our amusement here and according
| to our criteria on HN, they writes as it pleases them. They
| went to the length to do a useful breakdown of a circuit, and
| write about it.
|
| They don't owe us some nice title, or some convenient summary
| so we don't read their post...
| renewiltord wrote:
| Haha, _they_ don 't, but _we_ owe ourselves that so we
| should submit with that info.
| bigiain wrote:
| That's not what the site guidelines say...
|
| "Otherwise please use the original title, unless it is
| misleading or linkbait; don't editorialize."
|
| Use the original titles.
| samatman wrote:
| I would argue that the "Real or Fake?" part is
| clickbait-y, and the poster could have rewritten it to
| answer the question.
|
| This has come up before, and titles have been rewritten
| accordingly.
|
| Me? Title like that, I just skip to the comments, there's
| always someone at the top to sort me out.
| colejohnson66 wrote:
| The rule is there not to prevent clickbait, but to prevent
| editorializing the title when it's posted. The reason is
| editorializing inserts biases and possible wrongs
| (unintentionally).
|
| However, it is clickbait, by definition, but it's not
| _clickbait_. If it was, I'd expect: "You'll never guess what
| your Echo Flex does when you do this _one thing_!"
| colejohnson66 wrote:
| Nice to see electronupdate here. For those who don't know, he
| also has a YouTube channel[0] where he does teardowns of random
| ICs. It's quite interesting seeing the die shots. I'm assuming
| this post is a continuation of his "part 1" post/video from a
| week and a half ago[1] about the Echo Flex.
|
| His videos are definitely not scripted (and barely edited), which
| can be off putting to some (hearing "umm"s among other things),
| and he doesn't go into the detail that Ken Shirriff (@kens) does,
| but they're interesting nonetheless.
|
| [0]: https://youtube.com/c/electronupdate
|
| [1]: https://youtu.be/gYPLunFMIEI
| exmadscientist wrote:
| You'd think that he'd be better at interpreting IC markings by
| now, though....
|
| Part 1 is not "ICFJ", it's "CFJ". The line is the pin 1
| marking. This one is the harder of the two; however, if you've
| been doing this a while, you'd recognize this SOT23-5 as coming
| from TI, whose online marking code lookup returns
| "SN74LVC1G14DCK" in just a few seconds. (Incidentally, that
| means the actual marking is "CF" with a lot/date code marker of
| "J"; the random-looking lines above and below the text are also
| a lot or date mark.) No acid needed!
|
| Part 2 isn't marked "COOR", it's "C00" with lot/date code "R".
| That's decodeable by eye as a TI LVC2G00 dual NAND gate.
|
| The third part, the one marked "JW", is _probably_ an ON
| Semiconductor dual transistor, but those guys are always harder
| to track down. The fourth one, the SOT-323 (?) marked "39R"...
| that one will be hardest of all.
| moefh wrote:
| You seem to know what's going on, do you mind answering a
| question about the schematic?
|
| If the transistor is a PMOS like the author says, when the
| output of the NAND goes low wouldn't both the LED and the
| transistor turn on?
|
| The way the LED is drawn it should turn on when the NAND
| output is sinking current, right? Maybe the LED is drawn
| upside down? Or am I misreading/misunderstanding something
| really simple?
| osamagirl69 wrote:
| Very nice writeup, I love the combination of fun writing style
| and hand drawn schematics with things quickly escalating to
| decapping chips.
|
| Also nice to see that the led is a real one, even if the micro
| does have the ability to override the mute switch... I guess the
| 80's scifi movies with red glowing eyes to indicate the 'evil'
| subroutene was activated got it pretty close!
| mlyle wrote:
| Here, the red glowing eye turns off when the evil subroutine is
| activated.
| fctorial wrote:
| Now we just need another person educated enough to verify this
| blogpost.
| jwr wrote:
| That's an excellent teardown! Thanks!
|
| I think we should appreciate that while this isn't the best or
| most secure design (I'm not that happy with the host controlling
| the reset), it at least has an LED that shows the microphone
| status, which can't be controlled by software.
|
| I think this is the very bare minimum we should require from all
| our digital devices.
| [deleted]
| aufhebung wrote:
| Don't these mute buttons defeat the purpose of these devices in
| the first place?
|
| If I want to do what generally amounts to a google search it's
| generally easier to pull out my phone than walk over to the
| device, flip a switch, and speak.
| Krasnol wrote:
| There has been a related "talk" on rc3 on the topic, featuring
| scientists who analysed the traffic:
| https://media.ccc.de/v/rc3-466940-alexa_who_else_is_listenin...
| jessriedel wrote:
| Conclusion:
|
| > But, basically if one presses the switch it causes the flip-
| flops to change state and to then either add or remove power from
| the microphones.
|
| > The 'mute' button appears to be very real and functional. When
| the button glows 'red' the power is removed from the microphones.
| pansa2 wrote:
| I sometimes write articles describing investigations similar to
| this one. Do you think this article's structure is appropriate?
|
| Or would it be better to reduce the need for comments like this
| one by putting the conclusion much earlier in the piece? I
| understand not putting the conclusion in the title, but perhaps
| in the first paragraph, in the spirit of BLUF [0]?
|
| [0] https://en.wikipedia.org/wiki/BLUF_(communication)
| e12e wrote:
| > I understand not putting the conclusion in the title
|
| Why?
| richrichardsson wrote:
| I would hazard a guess that fewer people would read the
| article if the headline was, "Amazon Echo Flex: Microphone
| mute, real or fake? It's real."
| Birkalo wrote:
| I think that BLUF is definitely the better way of writing
| most informational pieces, particularly articles such as
| this.
|
| It's a similar concept to the 'Topic Sentence' which would be
| used to sum up the ideas of the following paragraph.
|
| The only reason I could see for actively choosing not to use
| BLUF - would be to force users to read more of your article
| for the sake of it, which seems (to me) like a 'cheap'
| tactic.
| pansa2 wrote:
| Do you think presenting the conclusion up-front could
| detract from the "story-telling" of the piece? By walking
| the reader through the investigation and its findings in
| chronological order, perhaps the article aims to make the
| reader feel like they are performing the investigation
| themselves?
| bo1024 wrote:
| Some readers could prefer the story-telling style, but
| others prioritize getting the information. To contrast, a
| novel wouldn't give away the ending on the first page,
| but a scholarly article absolutely has to give the take-
| away in the abstract.
|
| I personally think for informative reporting, it's
| maximally respectful of the reader's time and attention
| to give a quick summary up front. Then they can decide if
| they want to continue for the full details and story-
| telling experience. Many people won't, but those people
| would probably skip the story in the first place and
| click through to the comments for the punch line.
|
| Thanks for bringing up this discussion!
| analog31 wrote:
| I can't think of one right off the bat, but I've read
| some great novels where the author starts by telling you
| what's going to happen, but you still don't want to stop
| reading. In fact sometimes it makes you all the more
| interested in continuing with the story.
| tomxor wrote:
| Agreed. Although being upfront to some degree is useful
| there is a balance, some things are better revealed in
| context to fully appreciate. If the conclusion is less
| binary or singular something can be sacrificed without
| ruining everything, but in this case I can't see a way to
| not destroy the story telling... I'm pretty sure I
| preferred reading this without BLUF.
| floatingatoll wrote:
| The conclusion needs to be in the headline. If I'd seen this
| last night I would have emailed the HN mods using the footer
| Contact link to have the clickbait stripped out of it. I'm
| doing so now anyways.
| dang wrote:
| I'm not sure the original headline was that baity, since
| (1) the original title implies that the article will
| investigate the question, which is exactly what it does;
| and (2) if the conclusion had been that the button was
| fake, the title would certainly have said so.
|
| But point taken and I've changed it now. Thanks!
| alias_neo wrote:
| I have noted this with several high ranking posts on HN. I
| wonder whether it's a case of the author being unaware of
| BLUF, or simply that they want you to read their work before
| finding the conclusion?
| sokoloff wrote:
| I see it a lot at work and chalk it up to some people
| having learned/internalized a legalistic way of building up
| a pattern of facts and basing each on the previous. It's
| not so much that they want you to read 2 pages but that
| they want you to believe every newly introduced bit of the
| story.
| lovemenot wrote:
| Here in Japan too, bottom-up is the standard pattern.
|
| Japanese people can learn to use BLUF, but it's very much
| not the culturally expected approach.
| Fethbita wrote:
| As far as I can see from the blog, it's a technical blog. I
| would expect its regular users to read to the end and it kind
| of makes sense to put the conclusion at the bottom.
| jessriedel wrote:
| Technical users are exactly the ones who are looking to get
| information, not an entertaining story.
|
| There is a reason academia uses abstracts, and it's not
| because the attention spans of the readers are unusually
| short.
| SAI_Peregrinus wrote:
| This blog is all about decapping various ICs and providing
| die photos. The motivating question is mostly irrelevant, the
| intended audience is there to let someone else deal with
| boiling acid and still get cool pictures of chips to look at
| (and sometimes reverse-engineer). It's all about teardowns
| that don't give up whenever there's an IC package or epoxy
| blob.
| jcims wrote:
| We used to do that with all of our security assessment
| reports. It let people actually focus on the content vs.
| being distracted by waiting for the punchline at the end. To
| a person, our customers absolutely loved it.
| squaresmile wrote:
| I personally enjoy a good story. I think articles like this
| are about the story as much as if not more than their
| informational aspect. They are kind of like cool stories you
| tell your friends. You can see it the conversational
| sentences in this article.
|
| Especially if it's an article and not a video when I could
| easily skim to the end to read the conclusion if I don't want
| to read the story. I feel disrespectful towards the author if
| I want the conclusion up front.
| oops wrote:
| > The SOC (system on chip) controller seems to be connected to
| the flip flop resets, which makes sense as the product powers
| on with the microphone enabled as default....
|
| It sounds like you could press mute, walk away and it could
| reset unmuting itself in the process without you realizing. You
| would need to constantly monitor that LED for assurance it is
| still muted. It's not clear to me from the article how the SOC
| is connected to the flipflop reset. i.e. can the flipflop reset
| be initiated via software?
|
| A mechanical switch that can't so easily and unexpectedly lose
| its state would be preferable. There are probably good reasons
| they didn't do that (aesthetics, cost, reliability?)
| varispeed wrote:
| Can the device turn itself into automated update and then
| restart thus enabling adversary to listen to whatever is
| going on at someone's house?
| njdullea wrote:
| What did the OP do with acid to get an image of what was in the
| ICFJ chip?
| jaywalk wrote:
| https://en.wikipedia.org/wiki/Decapping
| HourglassFR wrote:
| Yes that is the technical conclusion. But maybe the most
| important thing is that we have to do an actual teardown of the
| product in order to have some confidence that Amazon is not lying
| on it's Echo capabilities.
|
| To be clear, I am not saying we should trust Amazon & Co, I'm
| saying that if that's the level of trust we have with home
| assistance devices, why even bother with the stuff ?
| rubyfan wrote:
| The stakes are so high for Amazon to tell the truth here. If
| they were lying then there would be outrage among users, media,
| competition, etc.
|
| I've dealt with many people from Amazon in my professional life
| and based on their handling of customer data I believe Amazon
| take seriously the trust customers place with them. Amazon
| believe the Alexa and Echo platform will grow their retail and
| service relationships with customers.
|
| I don't think they would throw that away to fool us all into
| believing a fake mute button - for what?
| anotherforsure wrote:
| "outrage among users, media, competition, etc."
|
| You really believe this? Still?
|
| Amazon is so big that the loss of outraged users is a
| rounding error to them. Ford used to let cars off the line
| missing bolts. They're still here because their pockets are
| deep enough to wait until people forget.
| everdrive wrote:
| I think both you, and the parent you're responding to are
| correct. Amazon is not evil, they're merely self-interested.
| This can lead them to do some evil things, but they are not a
| cartoon villain, twisting their mustache in shadows.
|
| On the other hand, it's important to verify claims, and
| Amazon should be very happy about this verification. It
| proves that their claim could be trusted. Some other
| conclusion could have just as easily been true.
| iratewizard wrote:
| Amazon is treated as if it were Google, despite not having
| quite the same track record. Amazon has walked a thin ethical
| line in terms of managing their labor force, but I haven't
| seen the same level of involvement in things like PRISM.
| darepublic wrote:
| I'm honestly not sure what the public response would be. I'm
| inclined to believe the revelation that the microphone is
| always on would not effect bottom line too much. Though maybe
| if a good meme campaign materialized people would join in on
| the public flagellation. But I bet more on people appetite
| for a public lynching than sacrificing their own convenience
| for long term considerations
| verbify wrote:
| Couldn't they have implemented mute in software? There would
| be little outrage if they had (users don't care about the
| difference) but spy agencies (e.g. NSO Group) would have a
| backdoor.
|
| The fact that they used a hardware switch means they did it
| the right way.
|
| By contrast my Logitech camera has a light to show when the
| camera is running - but the light can be disabled via their
| software which makes me uncomfortable with fully trusting the
| light.
| jsight wrote:
| They could have, but I believe in the past they have
| claimed it to be hardware.
| sib wrote:
| When we discussed this - at long length - during the
| original Echo development program, we consistently came to
| the conclusion that it should be hardware, not software, to
| maintain customer trust.
| mgdev wrote:
| I know you. :)
|
| #doppler4lyfe
| sib wrote:
| Took me a couple of minutes to figure out who you are :)
|
| Still proud of this product!
| sushisource wrote:
| My question for you is why not advertise this loudly? Or,
| maybe you did and no one cared? Because presumably it's a
| bit more costly per unit to do it this way, and very few
| people are ever going to understand and care.
|
| Not that I think you made the wrong choice, I think it's
| a good one, but I'm just curious how many consumers you
| thought would actually understand it, or how that
| information would be distributed
| sib wrote:
| It's a balancing act. We built it, to build trust. But
| talking about it too much would - we thought - highlight
| concerns and increase worries that we hoped (most) users
| wouldn't have.
|
| As an example, we were very clear and upfront in the
| original product detail page that users' voices went to
| the cloud, as we were not trying to hide that. Even so,
| some people tried to play a bit of "gotcha" and fear-
| mongering about the fact, as though we were not being
| transparent.
| pnathan wrote:
| Appreciate that, a lot.
|
| Particularly with software auto-updates, a software mute
| is simply untrustworthy.
| sib wrote:
| True. And in the early (internal) alpha days, false
| positives for wake word detection were quite high. So we
| felt the pain from eating our own dogwood; even though we
| spent huge amount of science / engineering resources on
| reducing those false positives, we knew it would never
| get to zero while maintaining acceptable true positive
| rates.
| criddell wrote:
| Are you still involved? If so, is there some way I can
| request a feature to turn off all of the "by the way" and
| other follow-ups? I find them incredibly annoying. I
| usually answer "no and don't ask again" but it doesn't
| seem to understand.
| sib wrote:
| I left some years ago. Yeah, not a huge fan of these "by
| the ways" but agree that having them would be less bad if
| there were a "don't ask again."
| Shared404 wrote:
| IMHO, This was the correct choice.
|
| No one I know would trust a software mute.
| sib wrote:
| Yeah... I thought it was pretty clear. While still hoping
| that we could build something (product & reputation) that
| users wouldn't want to turn off.
| DaniloDias wrote:
| Software based mute means a compromise of the kernel would
| destroy the control provided by a software mute.
| cmiles74 wrote:
| This is a good point, I had suspected that the mute
| function was, in fact, implemented in software.
|
| That they went ahead and implemented in hardware is
| encouraging. Someone over there took the feature seriously
| enough to take it this far. I am sure it added cost over a
| software-only solution.
| jgalt212 wrote:
| > I don't think they would throw that away to fool us all
| into believing a fake mute button - for what?
|
| True, but what is the incentive for Amazon to behave given
| their dominant market position? Customers might not have
| viable alternatives.
| KraftKacke wrote:
| To me it's unfathomable to have such a device around. I even
| feel uncomfortable with my neighbor having one (which I _hear
| him talking to).
|
| I assume it's like reading the side effects of medication and
| think they are other people's problems somehow. How do people
| trade core privacy for setting the alarm or getting the weather
| report by voice command. I don't respect them. Same with off
| the shelf IP cameras in one's bedroom. Hello?
|
| Air gapped speech recognition and FOSS, or this should never,
| ever become a thing.
| fortran77 wrote:
| I take security seriously. I have separate networks for my
| smart devices that have no access to my secure home network.
| I stay current on all risks, and I'm a regular attendee of
| security conferences.
|
| But I have Amazon smart speakers in every room (on their own
| network that can see the network my smart lights are on.)
| They're great. I don't worry about Amazon listening in.
| KraftKacke wrote:
| https://xkcd.com/1200/
| koolk3ychain wrote:
| I cannot agree more. In my home as long as I live I refuse to
| live with devices like this. And yes, I am _that guy_ who
| keeps laptops / phones in a Faraday box (a cool project I
| completed in quarantine) while not in use haha. My friends
| actually really like the novelty of putting their phone /
| devices into the box when they come over - even if they make
| fun of me for it.
| TheOperator wrote:
| For me what made me give in was realising how useful the
| features would be in regards to ADHD, allowing for a new
| input modality that just straight up reduces the friction it
| takes for me to set a reminder.
|
| It's routine that I will just leave an item and forget where
| it is several times a day that I take it almost for granted
| up until it causes me to be late going out the door. Now I
| can yell "Find my phone" (or wallet, keys, etc) and my phone
| is there. Yes I could go to my computer, go to the find my
| phone page, but there's just more friction and these issues
| happen to me all the time. The more things I link up to voice
| control, the more options I have in regards to accomplish a
| task, and sometimes voice is the most efficient means of
| going about it.
|
| I can get entertainment like a podcast or music without a
| single screen being involved, which given that I inherently
| have low impulse control, is a nice separation of things. Or
| I can again, find my stuff without looking at any screens.
| Voice input can act as a lesser evil to screens.
|
| Saying to just use FOSS and air gaps, because of how immature
| such solutions are, is effectively saying you shouldn't use
| these systems at all. The benefits of using the systems that
| exist today makes it so that the average person, like
| yourself, judge me less because I appear more punctual and
| less forgetful and more productive and better rested and so
| on. Being human, you are likely to disrespect me for being
| late and disorganized no matter what my excuse is, whereas
| you'll only disrespect me for using voice assistants if you
| know I'm using them, so it's a winning tradeoff. Just like
| how some will judge me for taking medication but only if they
| know I'm using it.
| randomsearch wrote:
| How is it different from having a mobile phone on the table?
| ballenf wrote:
| I think the issue is one of the consumer's intent: are you
| buying a phone with a bunch of extra capabilities or a
| microphone hooked to a data center around the world? And
| that explicit decision is what is jarring to people who
| value privacy.
|
| Of course they both _have_ microphones hooked to data
| centers, but the Alexas /Echos are almost worthless without
| the microphone enabled. Many people I know have turned off
| listening for trigger words on their phone.
|
| That being said, I have a HomePod that I have to manually
| press the touch button on top for it to listen. I use it
| for music, an occasional family conference call and
| occasional for generic assistant stuff like weather.
|
| I tried a Google Home but couldn't get it configured in
| that mode -- listen on physical touch only (that was 3-4
| years ago). And doubly couldn't get it setup without deep
| integration into a google account. The HomePod complains
| occasionally that it can't answer because it hasn't been
| personalized to an account, but is otherwise totally fine
| operating without access to my every inner thought
| (web/location history, etc.).
|
| I'm just as concerned about every modern car essentially
| being a microphone hooked to a datacenter on wheels. And
| new TVs. And a few refrigerators and kids toys. And light
| switches. At least phones (well iPhones -- haven't used the
| last few Android versions) are easy to setup without
| listening enabled. And on iPhones it's opt-in during the
| setup process (the Siri checkbox is default on, but you are
| prompted to decide with no other confusing decisions on the
| screen at the same time).
| tshaddox wrote:
| I'm not seeing the difference. If you already have the
| cell phone in your home, you might as well get the smart
| speaker if you want the convenience of voice controls for
| playing music, setting timers, etc.
| cmiles74 wrote:
| I don't think any consumer is buying a smart phone with
| the expectation (or intent) that it's recording them all
| the time, or sometimes, or at the behest of law
| enforcement, etc. They aren't really thinking about this
| when they buy a product like the Echo, either, I don't
| think. Also: a phone without a microphone will be of
| limited utility on calls. ;-)
|
| The only way to be sure these devices aren't listening to
| you is to not have one at all. Or, as the person in this
| article did, take it apart and de-cap the chips to make
| sure.
|
| In the case of smart phones, I think it's a mistake to
| assume that switching some of these functions off in the
| settings will actually have the desired effect:
| preventing the phone from recording audio without making
| the owner aware of this recording.
| shaklee3 wrote:
| > are you buying a phone with a bunch of extra
| capabilities or a microphone hooked to a data center
| around the world
|
| Yes.
| Talanes wrote:
| I get that you're trying to be clever and say that it is
| actually both, but the question was clearly phrased so
| that the second option was in exclusive opposition to the
| first.
| StavrosK wrote:
| > I have a HomePod that I have to manually press the
| touch button on top for it to listen
|
| What's the difference? You trust it not to listen without
| the button press, I trust it to not listen without the
| wake word. To think that the distinction is meaningful is
| wishful thinking.
| dunnevens wrote:
| It's kinda meaningful. Wake words can be sometimes
| triggered by accident. Or by things like that commercial
| from a few years ago. A physical button press avoids all
| that.
| thebean11 wrote:
| So the worry is that it will be triggered accidentally
| and hear something you didn't intend it to, then that
| tiny, rarely occurring piece of data will be used against
| you?
| ballenf wrote:
| I just see listening for a trigger word as surveillance.
| Your (and your guests) every word is analyzed and at
| least temporarily saved somewhere outside your control.
| StavrosK wrote:
| It's analyzed on the device, which is not outside your
| control. Besides, how do you know the same isn't true of
| the physical button?
| cmiles74 wrote:
| In my opinion, the difference is the amount of social
| pressure that is bearing down. Deciding to avoid products
| like the Echo and it's not a big deal. My mother-in-law
| will roll her eyes when I remind her we don't want for
| Christmas but it's not a big deal.
|
| I can't really get away without having a cell phone. The
| slope has been slippery on this one; when I purchased my
| first smart phone this wasn't a big concern (but maybe it
| should have been). It's been several years and it's a
| bigger sacrifice, in my opinion, to give up a smart phone.
| Even if I wanted to, my employer might buy one for me, for
| instance.
|
| I do think the expectation today is that everyone have a
| smart phone.
| breakfastduck wrote:
| If anything it's even worse with a mobile phone because
| that follows you after you've left the house.
| KraftKacke wrote:
| Yes, phones do have microphones too. The were a
| confidentiality risk even before becoming mobile. You also
| have piping running through your house, which could be
| tapped, you don't even need microphones, and the EM field
| emitted by your monitor can be read across the street. So
| why even care? Why should I encrypt anything, if I can't
| even prove not living in an all powerful simulation?
|
| Back on topic, it's not a phones intended purpose to snitch
| on you, they usually do not listen into the room, without
| extremely malicious manipulation, and more so you simply
| can not realistically avoid having a phone in your reach,
| today. If I were talking business I would probably leave
| the phone outside too, for that matter, and I don't trust
| cheap communication hardware, either.
|
| In real life drawing analogies by principle doesn't make
| for a good argument, most of the time, as life is
| adaptation and compromise, not a path through a logical
| circuit.
|
| Do you honestly not see an obvious difference between a
| phone and an Amazon wired device intended to record and
| remotely analyze what's happening in the room?
| xnyan wrote:
| >Do you honestly not see an obvious difference between a
| phone and an Amazon wired device intended to record and
| remotely analyze what's happening in the room?
|
| Do you honestly not see that there's no fundamental
| difference between the two? A CPU, ram, storage, wireless
| modems, microphones and a battery all running under
| software we don't control.
|
| As far as intent, it's not possible to be sure about
| intent, you have to judge based on the information we
| have which is the features and capabilities of the
| device.
| AnHonestComment wrote:
| The only obvious difference I see is my Amazon device has
| a hardware mute/can be unplugged and my phone doesn't
| have either option.
| creeble wrote:
| >Do you honestly not see an obvious difference between a
| phone and an Amazon wired device intended to record and
| remotely analyze what's happening in the room?
|
| I sure don't, from a security viewpoint. They are both
| cloud-connected microphones. Google is just as likely as
| Amazon to listen in surreptitiously. And my phone is
| 1000x more vulnerable to someone _other than_ Google
| listening in due to installable apps.
| epanchin wrote:
| Why would a google phone be any less likely to be
| listening than a google home?
| KraftKacke wrote:
| I addressed that point already in the post you're
| replying to.
| [deleted]
| Johnny555 wrote:
| You said _it 's not a phones intended purpose to snitch
| on you_, but it's also not an Amazon Echo's intended
| purpose to snitch on you, so I'm not sure what point
| you're making if you're going to assume that the device
| is used for its intended purpose.
| xg15 wrote:
| You're right, but how to do it otherwise? With the camera,
| there is at least the option of installing a mechanical shutter
| that can be easily seen (and understood) by users. With audio,
| I can't think of any similar solutions at the top of my head.
|
| Of course, technically, not even this hardwired circuit is
| complete proof that there is no trickery going on. If Amazon
| really wanted, they could simply hide a _second_ mic at some
| other place inside the device.
|
| I think the only solution that would really solve this was
| public auditing of the whole device.
| ehnto wrote:
| I think we are at a point with electronics and connectivity
| that trust is all consumers really have. Your average joe
| isn't going to think too hard about how they work, and they
| also lack the skills to assess it themselves.
|
| It's not a problem without prior art though, and other
| industries have had to find solutions such as certifications,
| regulatory bodies etc. Think of medicine, food, vehicle
| saftey standards and the like. I'm not an electrical engineer
| but I can trust my fridge to draw what it says it will,
| because I know it's been through the regulatory processes to
| get to market and be stickered with the 4 star energy rating.
|
| I think at this point we might need a privacy and ethics
| regulator for technology, with a certification program.
| SilasX wrote:
| This. It's why it's so important for laptops to permit a
| physical slider to block the integrated camera. It is a low-
| cost, low tech way to verify that the camera is not picking up
| usable images.
|
| The real problem is that we don't have something analogous for
| microphones. The best we could do is some kind of humming
| device that you could turn on near the sensor that would drown
| out any noises it might otherwise pick up (and also be
| unobtrusive).
| ansible wrote:
| > _It is a low-cost, low tech way to verify that the camera
| is not picking up usable images._
|
| It is definitely not _low cost_.
|
| In the hardware business, we count pennies. We count
| _fractions_ of pennies with the costs of various components.
|
| A shutter means at least one extra mechanical part, and a
| more complicated housing and increased assembly time at the
| factory.
|
| You might look at a piece of plastic and think it is only a
| few pennies of plastic. But by the time you get it integrated
| into the product, and shipped out to consumers, it can add up
| to a dollar of cost. That really eats into the profits of
| low-margin hardware.
|
| Only if enough consumers care about hardware shutters does it
| make business sense to include it. If most don't, and it is
| not a part of their buying decision making, then you're just
| throwing away money. Especially if it leads to increased
| post-sales tech support costs: ("My camera doesn't work! Is
| the shutter closed? Oh it is!").
|
| Note that this is not an argument _not_ to have hardware
| shutters. They are a good thing. But they come at a
| significant (to the final price) cost.
| Johnny555 wrote:
| Or you can spend a dollar on a stick-on sliding camera
| cover, which is what I use on my Macbook. Or spend a
| fraction of a penny and tear a corner off a sticky-note and
| past it over the camera.
| throwawayp123 wrote:
| Well, a physical open/close switch that's in line with the
| microphone lead would do the same thing. But, obviously that
| would be assuming privacy needs are incorporated into the
| design. I would imagine this could be added on some older
| laptop models with more physical space(I'm thinking of older
| thinkpads), but it would be a non-trivial process of opening
| a case, adding a cut-out for a switch, etc.
| SilasX wrote:
| To be analogous, it would have to actually interfere with
| the thing-being-sensed. The idea is that it should work
| despite you having no knowledge, and being completely
| untrusting, of what shenanigans they might have regarding
| how it's wired up.
| blackoil wrote:
| We have options of either to trust the company or some other
| auditor. We can try getting some laws made to ensure honesty,
| but I personally don't like that route this early in the
| technology.
|
| What we need a completely independent organisation like EFF to
| audit and certify basic guarantees around privacy/safety. The
| companies should also prefer this route as it would give take
| some heat off in EU/Congress without creating bureaucratic
| bottlenecks.
|
| One problem I see that such an organisation can act as front
| for the cartel to prevent entry of new startups/players.
| Daho0n wrote:
| That would make EFF a de facto certifier, taking on the role
| of state and make it a (bigger) target for big business.
| Really, we need laws (and a system that isn't broken. More
| like in Scandinavia, less like the Federal Communications
| Commission).
| mhb wrote:
| Isn't this Consumer Reports?
| jstanley wrote:
| > We can try getting some laws made to ensure honesty
|
| I'm pretty sure we already have laws to ensure honest
| advertising. The problem is that it's hard to tell the
| difference between malice and incompetence.
| BurningFrog wrote:
| > _But maybe the most important thing is that we have to do an
| actual teardown of the product in order to have some confidence
| that Amazon is not lying on it 's Echo capabilities._
|
| Isn't it also the most obvious thing?
|
| To be confident something is true, you need to confirm it. How
| else would the universe and human perception work?
| HourglassFR wrote:
| From a hackers perspective I guess it makes sense yes, and as
| we are on HN this is perhaps not surprising.
|
| Still, this is not how humans usually interact. I trust there
| is no poison in my food without analysing it, I trust people
| to no shot me as I walk in the street, I trust the shopkeeper
| to accept that I have paid if the card reader says so... As
| ethno points out [1], some social work is needed here for our
| collective trust no to be misguided. Crucially, if the social
| work to buy trust does no exist, it entirely falls on you.
|
| I consider myself that trusting the Echo (or other home
| assistance devices) is too much work for the meager benefit
| it provides.
|
| [1]: https://news.ycombinator.com/item?id=25747404
| cmiles74 wrote:
| I disagree with the idea that people, on average, take the
| word of business or corporate entities on faith. In the US
| we have organizations that vet drugs and medication (FDA)
| as well as to verify the safety of foods (USDA). I believe
| most US states license restaurants and have a process to
| ensure they aren't poisoning customers.
|
| In my opinion, it's only in the case of electronic and
| software products where we are supposed to take so much
| functioning of the device on faith. Perhaps this is a bad
| idea and we need an organization to vet these products as
| well.
| dbuder wrote:
| I'd want the source and the build chain for all the mcus on
| that board, you can turn many things into a microphone. I
| wouldn't put it past FAANG to get cute with it.
| torgian wrote:
| Interesting read. But if I owned one, I would destroy the trace
| going to the mic, specifically the one giving power, and install
| my own physical switch as a physical power switch.
| sircastor wrote:
| This is a really great breakdown of what's going on in device. I
| really appreciate the case removal to look at the inside of the
| chips, as well as the general explanation of the circuits
| involved.
| Geminidog wrote:
| Did you really have to acid etch a chip package to find this out?
| Can't you measure current/voltage across the microphone?
| monsieurbanana wrote:
| The reverse engineering work here showed that "LED is
| electrically tied to the signal which controls the microphone's
| power", which means there's no software way to turn the
| microphone on while keeping the LED red.
|
| Measuring the current of the microphone would only tell us that
| at a specific moment, the microphone is off and the LED is red.
| But that might be a software switch, in which case nothing
| would prevent Amazon to turn the microphone from time to time
| while keeping the LED red.
| tangoalpha wrote:
| An OTA firmware update can change this behavior overnight. Unless
| it's a physical bounce switch that actually disconnects power
| mechanically, you are still at the mercy of someone else.
| bayindirh wrote:
| As far as I understood from the schematic [0], the power line
| of the mic is directly connected to the LED.
|
| Looks like when you press the mute button, you both light the
| led up and pull-up the transistor gate (It looks like PNP so,
| it turns off when you apply power to the gate). This
| effectively cuts off power from the mic itself.
|
| So, the LED is not controlled by firmware but, by the behavior
| of the circuit.
|
| AFAIK, OTA updates cannot re-wire PCBs or do we have nanobots
| now?
|
| [0]:
| https://1.bp.blogspot.com/-vVhoXpEtTXo/X_0iLmz9gcI/AAAAAAAAB...
| bibabaloo wrote:
| Perhaps you could disable the button, but I don't think a
| firmware update can change the red LED on == microphone off
| behaviour. This is a good compromise IMO, as if the microphone
| off button stops working then you can deduce that the firmware
| may have been tampered with.
| detaro wrote:
| How does a firmware update change the hardware on the board?
| bigiain wrote:
| As I understand the teardown article, it is impossible for a
| firmware update or any malicious SOC code to enable the
| microphone without also turning the red led off.
|
| Not as good as a physical switch I guess, but better than some
| implementations of laptop webcam activity lights at least...
| ohazi wrote:
| > Unless it's a physical bounce switch that actually
| disconnects power mechanically
|
| That's literally what you're looking at.
|
| The schmitt-trigger and the DFFs debounce the switch in
| hardware, and then the FET that controls the power input to the
| microphone also controls the power input to the LED. What do
| you want, a relay?
|
| Firmware can only reset the DFFs (which does turn on the
| microphone), but it can't change the physically coupled LED /
| mic-power behavior.
| jwr wrote:
| Incorrect. The main conclusion of the article is that firmware
| can't affect the function of the switch.
| varispeed wrote:
| If the device reboots after remote update, wouldn't that
| enable the mic? I read that when you power on the device, mic
| is on by default. So that could be a way to turn on listening
| without consent.
| pengaru wrote:
| So the microphone signal line isn't broken by the mute, got it.
| mlyle wrote:
| No-- even better, the MEMS microphone is depowered.
| bigiain wrote:
| Not sure that really qualifies as "even better"...
|
| "Even better, there is no microphone", is about the only
| "even better" scenario than the signal lines being broken. A
| powered down active component is only "almost as good" at
| best.
| mlyle wrote:
| OK, so you'd rather have a big, high gain, low output
| impedance amplifier enabled and driven with the audio
| waveform but the signal line gated... than the device
| unpowered and the signal line connected to ground via the
| ESD protection path in the package. K.
|
| I'd have a decent chance at recovering the audio in the
| former case, but nil in the latter..
|
| For instance, if it's gated with a FET, and then hooked up
| to a SOC ADC pin that's multiplexed with other functions,
| one could use those other functions to provide biasing
| opening the FET.
|
| If it's gated with something better-- e.g. an actual
| relay-- the audio waveform may still be recoverable: it's
| very, very large in magnitude compared to how it is with
| the device unpowered, and will be consuming variable
| amounts of power with the audio waveform. You might be able
| to recover the signal by measuring power nets AC coupled
| with lots of gain.
| pengaru wrote:
| I wasn't aware the two were mutually exclusive. Why
| wouldn't you cut the power AND the signal?
|
| That MEMS microphone is producing analog output, is it
| not? I did a cursory search for the printed part numbers
| but came up empty handed.
| mlyle wrote:
| It looks like an analog part, yes, going to an ADC.
|
| Sure, cutting both would be even better.
|
| But-- as I posted earlier-- recovering a signal from a
| depowered MEMS device would be somewhat miraculous.
| https://news.ycombinator.com/item?id=25743822
| electro_blah wrote:
| That's great. now find the other hidden mic disguised as a
| different component.
| jstanley wrote:
| To wear a tinfoil hat for a moment:
|
| > The SOC (system on chip) controller seems to be connected to
| the flip flop resets
|
| > The 'mute' button appears to be very real and functional. When
| the button glows 'red' the power is removed from the microphones.
|
| Does the microphone take any time to boot up? How far could a
| malicious SoC get by toggling "reset" on and off very fast? If
| you toggle the microphone on and off at 96kHz with e.g. a 1% duty
| cycle, then you'd be able to sample the level from the microphone
| at 96kHz, and the LED would still be glowing at 99% of its usual
| current (which would be visually indistinguishable from 100%).
| This would allow the SoC to record audio at full quality, and
| still leave the LED glowing.
| danhor wrote:
| The reset stays. If the soc toggles the reset line, the
| microphone stays on and the led turns off, until the user
| presses the mute button
| _flux wrote:
| So I picked the very first mems microphone datasheet my ddg
| gave me: https://www.st.com/resource/en/datasheet/mp34dt06j.pdf
|
| ..and it says 10 ms max turn on time, so 100 Hz.
|
| Of course, a typical or minimum turn on time could be better,
| but I imagine it it were better, it would be advertised as
| well.
___________________________________________________________________
(page generated 2021-01-12 23:02 UTC)