[alias_neo]

I don't think they contradict each other. The way I read it is, the former, have hardware disconnects controlled by some software/firmware, such as a relay/MOSFET or something of that kind; an electronic switch.

The latter I read as being hardware _only_; "only" being the key addition to this sentence. I would expect this implementation to be something like a reed switch to magnetically disconnect the lines _physically_ rather than electronically.

[ken]

Isn't the whole point of software to control hardware, at some level? How is hardware-controlled-by-software different from plain old software-controlled? If a switch can be closed by software, I'm having trouble putting my finger on exactly what security benefit that might offer.

[derefr]

> How is hardware-controlled-by-software different from plain old software-controlled?

Perhaps it’s that the hardware interlock on the microphone can be enabled by software, but can only be disabled by a physical action (i.e. opening the lid.)

[jaywalk]

The security benefit here is that software has no access to this hardware switch.

[hamiltonkibbe]

I don't think the distinction is a FET vs a reed switch -- the means of blocking electrons, rather, it's in what decides whether that switch is open or closed. I would consider a circuit like this driving the FET/relay/etc. to be a "hardware disconnect" (using HDL to describe the circuit, not suggesting it should be programmable logic):

  module mic_enable (lid_closed, lots, of, signals, mic_enable);
    input lid_closed, lots, of, signals;
    output mic_enable;
    assign mic_enable = !lid_closed & lots & of & other & signals;
  endmodule

[simias]

I think that there are two aspects to this problem of hardware disconnects: can we really sure that the disconnect actually cuts the microphone and then can we be sure that this disconnect is driven reliably to cut the mic when we want it to be cut.

Having a separate FET/reed switch is about the former: having a discrete component makes it easier to audit and make sure that the microphone is indeed cut off. Technically messing with the audio codec config or pin muxing is probably equally as efficient when it comes to muting the audio input, but that's a lot more difficult to audit.

But then all all that is pointless if the code driving the switch is broken or has a backdoor. Given that most people won't disassemble their phone or laptop to put a probe on the FET/reed/whatever driving signal I feel like this is just a marketing smoke screen.

If I have to trust Apple's firmware to drive the "hardware" switch reliably, why not make things simple and trust Apple's OS to mute the audio codec reliably?

[hamiltonkibbe]

I think the whole point is that there is no code (firmware or otherwise) driving the switch. I guess it depends on your threat model, but if you don't trust apple's hardware or firmware to disconnect the microphone, you can't trust their hardware not to have another microphone somewhere else that isn't advertised and is on all the time.

I'd take the term "hardware disconnect" in this sense to mean that there exists no program that you can run on any of the processors, or no bitstream you could load into any FPGA on the device that would be able to enable the microphone when it shouldn't be enabled, eliminating the threat of malicious code enabling the microphone