[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