From a security perspective, they should be equivalent (nothing that can talk to a network sees the microphone data, just a 1-bit wakeup signal). Modulo side channels, of course.

For Bluetooth and WiFi there are basically three modes: Active and connecting (indicated by blue icon in control center), Active bit not connecting (indicated by white icon) and disabled (indicated by gray icon and disabled state in settings).

My gaming laptop appears to (and is supposed to) completely disable the webcam when switched, so if the microphone was on the same circuit (as someone else here said theirs does) then that would fix the privacy question.

@beyondmachines1

For Google Home, there are many that use local keyword detection and local voice recognition with Home Assistant. From what I saw, it works wonders (if you get the right hardware).

But for Android? The best I found is an app that requires a persistent notification for the hot word to work. AFAIK Google crippled Android so they are the only ones that can build an app with efficient hot word detection "for security reasons". And no custom ROMs seem to have fixed that or developed alternatives ( including @GrapheneOS ... YET ).

It's actually triple stage (DSP hotword + CPU hotword + serverside hotword). Each of the models is larger and more accurate due to RAM requirements.

Programming the DSP with hotword program is a privileged operation though, only built-in apps can do it (among other things, due to the fact that the DSP doesn't have much of its own memory protection).

You are welcome!

If I understand correctly how this works: There is a small always-on low-power core that is recording everything to a small buffer and doing a small amount of signal processing to see if there's a reasonable chance that you've said the activation phrase. When it detects this trigger, it wakes up the main core, which grabs the buffer and does some more complex signal processing to see if you really (or, at least, with much higher probability) said the activation phrase. If so, it's then forwarded to the thing that processes the command.

If the code on the main core doesn't have microphone access, the core is still woken up, but then the process that tries to check if you really said the activation phrase fails because it can't access the microphone.

There's probably an interesting side channel where a malicious version could (assuming the low-power core doesn't hardcode 'Okay Google') rapidly program different activation phrases to get a reasonably high probability of whether specific things are said.