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 "remembers yesterday" precisely because yesterday is tied to an account somewhere. 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.
- Rendering is local; conversation is not. The character is drawn on your device, but what you say is processed by services. We say that in the docs rather than letting "runs on your device" imply something broader.
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.