Blanktick

Why: good AI against bad AI

Antivirus looks for bad files. Bad AI usually isn't one. An AI assistant that a web page can talk into running commands, a model server anyone on your network can use, an API key in a plain-text settings file: none of these is a file to scan. Blanktick looks at how the AI on a PC is set up and what it is doing, and lets your own AI agent help you close the gaps.

What it looks for	Rule
An AI assistant that can both read outside content and act on the computer (prompt-injection reach)	DSK-AI-006
AI model servers listening on the network	DSK-AI-001
Which tools an AI assistant is allowed to run (MCP servers)	DSK-AI-002
API keys stored in plain text in AI settings files	DSK-AI-003
AI tools that download and run code	DSK-AI-005
Windows Recall keeping a searchable record of the screen	DSK-AI-004
Live: an AI assistant starting a shell (cmd, PowerShell, mshta)	DYN-AI-001
Live: an AI agent acting right after reading outside content	DYN-AI-003

Your AI on your side. Blanktick.exe --mcp is a stdio MCP server with eight read-only tools (docs/mcp.md). Connect Claude or another agent and it can explain what is exposed and how to fix it. It cannot change anything: there are no fix tools by design, and a test enforces that. The agent explains; you act.

What it does not do: delete or quarantine anything, block every attack, or replace Windows Security. The live rules run while the app is open and flag by default; they stop a process only if you turn that on.

The rest of this README covers the other half (the whole-PC scan, the 75 Windows settings checks) and the design rule behind all of it: "not checked" is a result. When Blanktick can't look at something, it says so instead of showing a green tick.

---

A security checkup for your phone and your computer that runs entirely on the device it is checking.

The app has no INTERNET permission. Not "we choose not to send data" — the operating system will not let it open a socket, because it never asked for one. That is verifiable in ten seconds against any build:

$ aapt dump permissions app-debug.apk
package: com.blanktick.app.debug
uses-permission: name='android.permission.READ_MEDIA_IMAGES'
uses-permission: name='android.permission.READ_EXTERNAL_STORAGE' maxSdkVersion='32'
uses-permission: name='android.permission.PACKAGE_USAGE_STATS'

$ aapt dump permissions app-debug.apk | grep INTERNET
$

The build enforces it: assertNoNetworkPermissionDebug reads the merged manifest and fails if any network permission appears — including one injected by a transitive dependency, which is the realistic way it would happen.

On desktop, the same promise is weaker, and we say so

A desktop JVM has no permission model to opt out of. A process started by the user can open sockets and nothing inside that process can make that untrue. So the desktop build makes a narrower claim and enforces it differently:

$ gradlew :desktop:check
  Blanktick: no Blanktick class references a networking API.
  Blanktick: scanned 43 runtime jars, 0 contain networking code.
  Blanktick: dependency network surface unchanged (0 jars).

• assertNoNetworkBytecode scans the compiled classes of :core and :desktop for any reference to java.net.Socket, HttpURLConnection, SocketChannel and friends, and fails the build if one appears. Exactly one class is exempt, by exact name: NoNetwork, whose job is to break them.
• auditDependencyNetworkSurface pins every third-party jar on the runtime classpath — 42 of them — and flags those containing networking code. As measured on 2026-08-29, none of the 43 runtime jars (Compose Multiplatform, Skiko, coroutines, the Kotlin stdlib) contains a single reference to a networking API. The build fails if the set changes. An earlier version recorded only the jars that did contain networking code, which meant a new clean dependency passed silently. That was a false assurance and is fixed.
• NoNetwork additionally blocks java.net.Socket and http/https URLs at runtime. This is defence in depth, not the guarantee: java.nio.channels cannot be intercepted after startup and native code is out of reach. The About screen lists both gaps rather than implying total coverage.

The scanner is positive-controlled, because a broken scanner and a clean codebase produce identical output:

$ gradlew :desktop:assertNoNetworkBytecode -PblanktickNetworkGateSelfTest
> Task :desktop:assertNoNetworkBytecode FAILED
      com/blanktick/desktop/NoNetwork$BlockedSocketImpl.class -> java/net/Socket, java/net/InetAddress

If that passes, the gate is dead and its silence means nothing.

---

Status

Component	State
core/ — scoring engine, rules, filters, URL analysis, EXIF	Builds. 350 tests, 0 failures.
app/ — Android, Compose	Builds. 26.6 MB APK produced. 30 tests, 0 failures.
desktop/ — Compose Multiplatform	Builds and runs. Blanktick.exe produced. 77 tests, 0 failures.
Windows collector	Runs on real hardware. 70 of 92 checks answered on the dev machine, 0 not checkable, 22 that do not apply to it (re-measured 2026-11-03 on the packaged 0.1.3 build).
macOS collector	Written, never executed. No Mac available.
Linux collector	Written, exercised only under WSL. Not a real desktop session.
Intel bundle pipeline (Python → Kotlin ×2)	Working. Cross-language parity proven.
web/ — marketing site + live link checker	Working. 30/30 logic parity tests.
design/ — tokens, interactive prototype	Working.
ios/BlanktickCore/ — Swift mirror	Written, not compiled. No Swift toolchain on Windows.

This is the beginning of the README. Read the rest at the original. Read the full README ↗