Privacy policy for Phone Checker
Checked against Phone Checker 1.0.0 on 10 September 2026. The data controller is Dimitrios T, Athens, Greece — hello@flosforge.eu.
Phone Checker makes no network requests of its own — there is no fetch, http or net call anywhere in the source. Everything it learns about your phone stays on your computer, in files you can read. There is no account, no server and no telemetry, and the app is not affiliated with Google, your phone’s manufacturer or any app store.
What Phone Checker collects about you
Nothing. There is no account, no telemetry, no analytics, no crash reporting and no identifier of any kind. The app has no server of its own to send anything to, and it does not phone home to check for updates — there is nothing to check for — you pull the source and rebuild when you decide to.
What it stores, and where
- One JSON file per phone, named after its serial
- Holding the baselines three checks learn on their first run, the last forty check runs with their full results, the last five hundred things the app did, and the undo list for every family of change. It lives in the app’s data folder on your computer.
- Save-state snapshots
- One JSON file each, holding a full picture of the phone including its complete settings tables, so any two can be compared later.
- A daily log of every adb command
- Every command the app sent, with its outcome and timing. The Console shows the same stream live.
- Theme and terminal history
- In the app’s own browser storage. Nothing else is kept there.
- These files are personal — read them before you share one
- By the app’s own standard every file above is personal data about you. They carry the phone’s serial, every package name on it, and in the snapshots the full settings tables. Exports and the full report go wherever you choose in a save dialog, and they carry the same content.
Everything it can connect to
The app makes no network requests of its own. Two things reach past your computer, and both are ones you cause deliberately.
- Your own phone, over the USB cable
- Through ADB, the debugging interface Google documents and that you switched on yourself. The phone shows your computer’s key fingerprint and asks whether to trust it before anything can be read. Nothing else is on the other end of that cable.
- The Search web buttons
- They hand an https:// address to your own browser and stop there. Whatever happens next is between your browser and your search engine, under their terms rather than the app’s — the app itself never opens a connection.
What never leaves your computer
- Nothing about your phone is transmitted anywhere: not the serial, not the package list, not a settings dump, not a check result.
- No telemetry, no crash reporting, no analytics, no update check and no account.
- The window that draws the interface has no network access at all — its content security policy is default-src 'self', node integration is off and context isolation is on, so the page can only call the fixed list of operations the bridge exposes.
- adb is not bundled and nothing is downloaded. The app uses the copy of the official platform-tools already on your PATH, and points you at Google’s download page if it finds none.
- The APK copy that Verify pulls in order to hash it is deleted in a finally block, whether or not the hash succeeded.
Safeguards
- Reads run at once, writes wait for you
- Every check, audit, comparison and export only reads. A command that changes the phone is named in full in a native dialog, with every affected item listed and Cancel as the default button, before it is sent.
- Risky changes are named as risky, separately
- A package the knowledge base marks keep-tier refuses the whole request. Caution-tier packages, settings with a trade-off and system packages get a second dialog giving the reason for each, offering cancel, skip the risky ones, or do them too.
- Changes are reversible, and recorded
- The previous state is saved before every change and the change is written to that phone’s history, so it can be undone from inside the app.
- A failed read is never a pass
- Every check notes the adb failure counter before it reads. If the counter moved, the result becomes unreadable rather than clear — a loose cable cannot turn into an all-clear, and the check’s baseline is left untouched.
- Unrecognised commands are treated as writes
- In the Terminal, a classifier runs on everything you type. Recognised reads run at once, destructive commands are confirmed twice, and a command it does not recognise is confirmed rather than assumed safe.
Your rights, and who to ask
Because the app holds nothing about you, there is nothing for the controller to access, correct or erase on your behalf: everything it knows is in files on your own computer, under your own control. Deleting the app’s data folder removes the per-phone JSON files, the snapshots and the command logs. Exports and reports you saved elsewhere are yours to delete; the app does not track where you put them. For anything else, write to hello@flosforge.eu. The site-wide privacy policy covers this website, your rights under the GDPR, and the supervisory authority you can complain to.
Changes
This statement is checked against each release. If a version changes what the app stores or what it can connect to, the version and date at the top change with it.