Technically, the scenario described could happen entirely offline: voice recognition, transcription, then match for autocomplete (not that I am claiming this is what happened).

Full-text voice recognition is CPU intensive though, so one can expect mobile that's doing that all the time to drain its battery pretty fast in a noisy environment which should be rather obvious.

> If speaking automatically triggers some request you'd see it immediately (and see the URL and payload)

That's one possible way to implement a feature like this. Ruling out this mechanism doesn't rule out any others.

> phones being able to be eavesdropped/wiretapped even when turned off.

Nobody is auditing the baseband firmware blobs, and with non-removable batteries phones are never really turned off. I would be surprised if the NSA doesn't have a backdoor in it. Pure conjecture, of course, but the alphabet soup boys have the motivation, the ability, and the history, of getting their backdoors put into tech.

The EG.25 (Pinephone modem) baseband (not the Linux firmware (and of course, not the application processor OS)) blob source was up on Github for a while. I read through part of it. I think they managed to get it taken down with a DMCA request and I haven't seen it since.

I really wish I had cloned it locally, I don't know why I didn't.

They could also queue the data then piggy back it on a “legit” network transaction and since it’s encrypted you’ll never be the wiser.

Many apps are "pinning" TLS certificates, so you can't see their traffic w/o changing a hard-coded public key in the app itself.

It is also possible that the device does not send the data instantly, but rather at a time intervall or bundled with other legit requests.

It could happen offline, it could also happen async.

I wouldnt send instantly