Privacy Kit

• Privacy Kit 2.0 — an assistant that can configure the app for you, an external automation surface, and device templates that finally work on every phone.
• Ask the app what's wrong A built-in assistant (Settings → Assistant) that reads your setup and changes it by calling the app's own tools — create a profile, apply a device template, run Setup Doctor, read hook logs, flip a Developer Setting, open the right screen. Bring your own API key.
• It is built to be narrow on purpose:
• It can only call the app's registered tools. No shell, no free-form writes. It cannot delete anything or weaken your protection without a confirmation card. A tool that would make you more identifiable stops and asks, because consent to that is not something to infer. It never sees your identifier values. Tool results are shaped into counts, rules, grades and setting names before they reach the model, so your real or spoofed IDs are never sent to your AI provider. Answers carry tap-through links to the profile or screen being discussed, and an answer given without running any check is labelled as such. Automate it from your computer (optional, off by default) A zero-dependency MCP server (tools/mcp/) lets an external agent read and change Privacy Kit's configuration over adb. Two separate opt-in switches plus a token, and the policy is enforced on the device, not by the client — so a client that ignores the rules still gets refused. Deletion and app launching are excluded by design.
• Device templates work on every phone now Applying "Nothing Phone" or "Samsung Galaxy" used to silently keep your real device on newer Android versions, because a catalog row's Android version can't always travel to your phone. Now the device identity is applied regardless and the fingerprint is rebuilt around your real release, so the two never contradict each other. A profile named after a phone now reports that phone.
• New: hide manufacturer-private sensors Your sensor list is readable by any app with no permission, and it names your manufacturer and your ROM. On one test device, 31 of 59 sensors reported strings like xiaomi.sensor.fod_detector and org.lineageos.sensor.udfps — while the profile claimed to be a Galaxy S23.
• The new per-app Hide manufacturer-private sensors toggle (Advanced) withholds device-private sensors whose vendor namespace doesn't match the device your profile claims to be, and aftermarket-ROM sensors always. Measured on that device: 59 sensors visible before, 30 after.
• It removes information and never substitutes it. Relabelling the roster to your claimed phone was built and rejected: a donor roster can only match standard sensor types, so the vendor-private half would keep its real strings and apps would see a list naming two different phone makers — which no real device produces, and which would identify Privacy Kit rather than hide it. Ordinary sensors keep their real vendor strings, and the toggle says so.
• Setup Doctor tells the truth about the native layer The native-module check used to report a clean pass while a profile claimed a chip the phone doesn't have. GPU strings, /proc/cpuinfo and CPU frequencies are passthrough by design at every module version, so it now fails with an explanation instead of implying those reads are covered.
• Fixes Profile creation and template application are transactional — a failed template no longer leaves a half-built profile behind. The automation token lives in its own store and is excluded from backups, so it can't travel in a restore. The three sensor modes now have an explicit precedence (Fake > Fuzz > Block); Block was silently winning over the other two when more than one was on. Device templates search the full catalog, so Google/Pixel templates resolve correctly.

Write a review