Signal Drops Phone Numbers, Apple Opens the Mic, Android Gets Rooted
Three stories from this week's tech feeds, picked because they all touch the same thing: what your device knows about you, who it listens to, and who it trusts. With what each one actually changes.
Three Trust Stories, One Underlying Question 🔍
We read the tech feeds anyway — the board on this page pulls from Hacker News, Lobsters, Reddit and others. Most weeks the front pages are unrelated noise. This week three stories landed that are really the same story, and it happens to be the one we spend our days on: what your device knows, who it listens to, and who it trusts.
These are other people's reporting — links go to the source. What follows each link is our read on what it changes for anyone running a VPN client, a private agent, or a voice companion.
1️⃣ Signal is dropping the phone number as your identity
Registration without a phone number will use zero-knowledge proofs · community.signalusers.org · 250 points on Hacker News
Signal has long been in an awkward position: an app built to protect your messages, that required a phone number — the single most linkable identifier most people own — to sign up. The plan is to use zero-knowledge proofs so you can register without handing one over.
What it changes: it separates proving you are a legitimate new user from telling us who you are. Anti-abuse has always been the honest argument for phone numbers — they cost money and they are hard to farm at scale. A zero-knowledge scheme keeps the abuse resistance and drops the identifier.
That distinction is worth internalising, because it generalises. Every app that ties your data to an account is making the same trade. When we wrote about where AI companion conversations actually go, the crux was that a companion which restores your history on any phone can do so precisely because that history sits on a server, tied to an account. Account-binding is the feature and the exposure at once. What Signal is demonstrating is that the two can be pulled further apart than most products bother to try.
2️⃣ Apple is opening the door to always-listening apps
Watch what you say · this.weekinsecurity.com · 82 points on Lobsters
A critical read on Apple shipping capabilities that let apps listen continuously rather than only while you hold a button.
What it changes: the security question stops being "did I grant microphone access" and becomes "what is that grant worth now". A permission that used to mean this app can hear me during a call can come to mean this app can hear me during dinner. The checkbox looks identical; what sits behind it does not.
This is close to home. AniSoul and RealSoul ask for microphone access so you can talk to a companion instead of typing. Our position on that has not changed, and this story is a decent moment to restate it:
- Approve microphone access from the system prompt only, and only when you understand what triggered it.
- You can decline and still use them — typing works identically.
- What the microphone hears stays on the device. Speech recognition uses Apple's on-device recogniser and the language model runs on the device too, so what you say is never sent to us or to anyone else. The details are in the docs. (Updated 8 October 2026: an earlier version of this post said conversations were processed by services, which is no longer how the apps work.)
An always-listening capability does not become safe because the app asking is friendly. The right habit is the same whoever is asking: grant narrowly, and know what the grant covers.
3️⃣ An unprivileged Android app can root major phones
OEMpocalypse · calif.io · 51 points on Hacker News
A chain that lets an ordinary app — no special privileges required — obtain root on devices from several major manufacturers.
What it changes: this is the one with the least comforting takeaway. Android's security model assumes apps are confined by the sandbox and that privilege escalation requires either your consent or a physical unlock. A vulnerability class that skips both means the app you installed for one purpose can, in principle, reach everything else on the handset.
For anything that holds credentials this matters more than usual. A VPN client stores subscription URLs and endpoint credentials. This is why AI Booster's docs tell you to treat a settings export like a password — an export can contain WARP device keys and the addresses of services you use, and "it is only on my phone" is a weaker guarantee than it sounds on a week like this one.
Two practical responses: take OEM security updates when they arrive (this class of bug is patched by the manufacturer, not by the apps), and keep your exports off public threads regardless of how healthy your device looks.
🧵 The thread connecting them
Read together, these three describe the same boundary from three sides:
| Story | The boundary |
|---|---|
| Signal | What your account has to know about you |
| Apple | What a granted permission actually covers |
| Android root | Whether the sandbox holds at all |
None of them is a reason for alarm on its own. Together they are a reminder that "it runs on my device" is not one guarantee but several independent ones, each of which can be true or false separately. That is the same point we keep arriving at from different directions — self-hosted does not mean local is the server-side version of exactly this.
The useful habit is not paranoia. It is asking, of any product including ours, which specific part is local and which part is not — and expecting a straight answer.
Links above go to the original reporting; the commentary is ours. Scores were current when this was written and move constantly.