Full security and code-health audit of the whole codebase

[DevEmperor]

This is a marker, not a plan. Nothing has been audited yet; this issue exists so the pass gets made deliberately rather than never, and so its scope is agreed first.

What we want to do

A full read of the codebase with two questions in mind at once: is anything here a security or privacy risk, and is anything here fragile, dead, or built in a way that will hurt later. One pass, both lenses, because the same code review answers both.

A keyboard is an unusually sensitive thing to install. It sees every password field, every message, every card number typed anywhere on the phone, and this one additionally holds API keys, records audio, and talks to providers over the network. The promises in the README and the privacy policy are only worth what the code actually does, and nobody has ever read the whole thing with an adversary in mind.

Scope

Everything: app/, lib/dictate-core/, the FlorisBoard modules we inherited and have been editing, wear/, and cloud/ (the Cloudflare Worker, including its D1 schema and the wallet flow).

What to look for

Security and privacy

• credentials — how API keys and passwords are stored, logged, backed up, restored and shown; what a rooted device or an adb backup gets
• the sensitive-field gates — password fields, incognito, isSensitiveDictationField() — and every path that reads text or audio around them
• what leaves the device, when, and to whom: every network call, every URL built from user text, every prompt that carries a transcript
• logging: anything that could put user text, audio paths or keys into logcat or a crash report
• Android surface: exported components, intent handling, the share-sheet entry points, SAF grants we hold and never release, file permissions on what we write
• the panels that hold user content — clipboard, history, stickers, GIFs — and what deleting something actually deletes
• dependencies with known CVEs, and the ones we vendored (sherpa-onnx, Silero, the dictionaries)

Stability and code health

• crash and ANR paths: work on the main thread, unbounded collections, coroutines and receivers that outlive their scope, anything that can throw inside the IME lifecycle
• the places where we already know a rebuild happens under pressure — text insertion, the window/height chain, the suggestion pipeline
• dead code, settings that no longer do anything, and duplicated logic that has drifted between two copies

How it should end

A written report first, then issues — no fixes inside the audit pass. A finding that gets quietly fixed while reading is a finding nobody can review. Each real finding becomes its own issue with a severity and a concrete failure scenario; the report lists what was checked and found clean as well, because that half is what makes the next audit cheaper.

Anything genuinely exploitable does not go into a public issue — it gets fixed first and described afterwards.

[DevEmperor]

Audit #383 — security and code health, full codebase

Read on 2026-09-21 against main @ 1c36bddd. One pass, both lenses, as the issue asks.

Nothing genuinely exploitable by a remote attacker was found. No finding below needs to be
fixed before it can be described in public. The two that come closest — the platform backup and
the file:// handling in the exported activities — are local-access or self-inflicted, and both
are stated here in full.

What was covered

Area	Depth
app/ (566 files, 132k lines)	manifest + every exported component read in full; the dictate, clipboard, history, sticker, GIF, a11y, recognition and backup paths read line by line; the rest swept by pattern
lib/dictate-core/ (28 files)	provider client, TLS, proxy, realtime, HTTP diagnostics read in full
lib/{android,color,compose,kotlin,snygg}/	swept by pattern; ZipUtils read in full
wear/ (13 files)	protocol + key handling read
cloud/ (37 TS files, 12.8k lines)	auth, wallet, guard, throttle, meter, redeem, delete, rtdn, chat, transcriptions and the admin dashboard read in full
git history	last 400 commits scanned for key-shaped strings — clean
dependencies	version catalog reviewed; all current, no analytics/crash SDK anywhere

---

Findings

S1 — The platform backup carries every credential off the device

Severity: high (privacy / promise mismatch). Definite.

app/src/main/res/xml/backup_rules.xml includes domain="root" path="jetpref_datastore", and
AppPrefs.kt:287 stores the whole provider keyring (dictate__provider_accounts) there as plain
JSON. So Google's cloud backup and the device-to-device transfer carry, in the clear:

• every provider API key
• the Dictate Cloud wallet token and recovery code (ProviderAccount.walletId /
  walletRecoveryCode)
• dictate__proxy_username / dictate__proxy_password (AppPrefs.kt:354,358)
• gif__klipy_api_key

The app already decided this is not acceptable in the other backup: BackupRedaction.kt exists
precisely to strip these, and BackupScreen.kt:460 switches to the redacted variant the moment the
destination is "share". The platform backup does the opposite with no such reasoning and no UI.

PRIVACY_POLICY.md §2.4 says the keys are "stored locally on your device" and §6 says they
"remain on your device until you delete them in the App or uninstall it". With allowBackup="true"
that is not true.

Failure scenario: minSdk is 26. On Android 8–11, adb backup -f out.ab net.devemperor.dictate
from a PC with USB debugging on pulls the jetpref file with every key in it — no root, no exploit.
On Android 12+ the same data goes to Google Drive (E2E-encrypted with the screen lock, so not
readable by Google, but off-device) and is restored onto whatever phone the user sets up next.

Fix: exclude jetpref_datastore from the backup and restore settings through the app's own
backup file instead, or keep it and say so plainly in the privacy policy. Not both as they are.

S2 — dataExtractionRules points at a file in the wrong format

Severity: high if it lands the wrong way. Needs one measurement.

AndroidManifest.xml sets both attributes to the same file:

android:dataExtractionRules="@xml/backup_rules"
android:fullBackupContent="@xml/backup_rules"

backup_rules.xml has a <full-backup-content> root. That is the correct root for
fullBackupContent and the wrong root for dataExtractionRules, which requires
<data-extraction-rules>. On Android 12+ only dataExtractionRules is read.

The two possible outcomes are opposites and I will not guess between them: either the parse fails
and the app is backed up not at all, or it fails and the framework falls back to backing up
everything — which would mean the transcript history (filesDir/dictate_history), the retained
audio, the clipboard database and the keys all leave the device, none of which the include-list
intends.

Fix: write a separate data_extraction_rules.xml with the right root and the same intent
(<cloud-backup> + <device-transfer>), then measure once with bmgr backupnow on an Android 12+
device and look at what actually goes.

S3 — The "never in a password field" promise only holds for the keyboard

Severity: high (privacy / promise mismatch). Definite.

DictateController.kt:3436:

private fun isSensitiveDictationField(context: Context): Boolean {
    if (outputTarget != OutputTarget.IME) return false      // ← everything else is "not sensitive"
    ...state.isIncognitoMode || state.keyVariation == KeyVariation.PASSWORD
}

OutputTarget has three values (DictateController.kt:257). Two of them return false
unconditionally:

• OVERLAY — the floating button, which writes into any app through the accessibility service
• RECOGNITION_SERVICE — RecognitionActivity, DictateRecognitionService and the voice IME,
  i.e. the mic button of every other keyboard on the phone

So a dictation into a password field reached through the floating button or through another
keyboard's mic key is written to the history verbatim, and with audio retention on its recording
is kept too.

The code comment says the floating button has "no reliable field-sensitivity signal". That is not
correct: AccessibilityNodeInfo.isPassword() exists and is exactly this signal.
grep -rn "isPassword" app/src/main/.../dictate/overlay/ returns nothing — it is simply unused.

PRIVACY_POLICY.md §7 states: "Password fields and incognito mode are excluded from the dictation
history entirely." Today that sentence is only true of the keyboard.

Fix: read isPassword on the focused node for the OVERLAY path; decide deliberately what the
recognition paths should do (the caller's EditorInfo is not available there, so the honest answer
may be "never log a recognition-service dictation"); then either the policy matches the code or the
policy gets narrowed.

S4 — A PIN field is not a password field anywhere in the keyboard

Severity: medium. Definite.

EditorInstance.kt:188:

InputAttributes.Type.NUMBER -> {
    activeState.keyVariation = KeyVariation.NORMAL     // ← even for numberPassword
    KeyboardMode.NUMERIC
}

InputAttributes.kt:41 maps TYPE_NUMBER_VARIATION_PASSWORD to Variation.PASSWORD correctly, and
then EditorInstance throws the answer away for the whole NUMBER class. Consequence:
state.keyVariation is NORMAL in a PIN field, so isSensitiveDictationField returns false and a
dictation into a banking PIN or a card CVV is logged to the history.

The composing region is off for NUMERIC, so word learning is not affected, and the key preview is
separately suppressed for numeric layouts (TextKeyboardLayout.kt:303, !numeric) — those two are
fine. It is only the sensitivity gate that is wrong.

Fix: set KeyVariation.PASSWORD for TYPE_NUMBER_VARIATION_PASSWORD before choosing the
keyboard mode.

S5 — The key preview shows the character in a text password field

Severity: medium. Code path is clear; wants one look on the device.

TextKeyboardLayout.kt:696:

if (prefs.keyboard.popupEnabled.get() && popupUiController.isSuitableForPopups(key)) {
    popupUiController.show(key)
}

isSuitableForBasicPopup (TextKeyboardLayout.kt:300) excludes numeric and phone layouts and key
codes ≤ SPACE. It does not look at keyVariation. PopupUiController.show() has no such check
either. popupEnabled defaults to true.

The codebase's own rule elsewhere is the opposite: glide typing is disabled in password fields in
two places (TextKeyboardLayout.kt:128 and :476), snippet expansion is
(KeyboardManager.kt:714), auto-capitalisation is (:1074), the maths strip is
(NlpManager.kt:616). The magnified preview is the one that isn't — and it is the one that is
visible from across a table.

Note TextKey.kt:106 builds a PASSWORD-specific extended popup set, so password fields were
thought about for popup content but never for whether a preview should appear at all.

Fix: add evaluator.state.keyVariation != KeyVariation.PASSWORD to the show condition. Confirm
first with one screenshot in a password field that the bubble does appear.

S6 — "Trust user certificates" is global, not per endpoint

Severity: medium. Definite.

prefs.dictate.trustUserCertificates is read at 12 call sites and passed into every
ProviderConfig — OpenAI, Groq, Dictate Cloud, the watch, the file importer, the model picker
(DictateController.kt:1855,1872,2772,2784,3967,4019, PhoneTranscriber.kt:68,97,
ImportTranscriber.kt:330, TranscribeShareScreen.kt:731, ModelPickerDialog.kt:97,
DictateProvidersScreen.kt:1183).

The setting exists for one honest case: a self-hosted endpoint behind a private CA (#137). Turning
it on for that widens the MITM surface of every cloud provider at the same time.

Failure scenario: a user adds their company's internal CA to reach their own Whisper box, ticks
the switch, and from then on anything that can get a certificate out of that corporate CA — which is
usually the corporate MITM proxy — can read their OpenAI key and their dictations.

Fix: move the flag onto ProviderAccount so it applies to the endpoint it was turned on for.

S7 — A custom http:// endpoint sends the key and the audio in the clear, silently

Severity: medium. Definite.

android:usesCleartextTraffic="true" is app-wide, deliberately, so a LAN Ollama works (#136).
grep 'startsWith("http://")' across the whole app finds exactly one hit —
RealtimeClient.kt:143, which quietly rewrites it to ws://. There is no warning anywhere when
someone types an http:// base URL, and no restriction to private address ranges.

Failure scenario: a self-hosted endpoint is set up at home as http://192.168.1.50:8000. The
same URL is used on café Wi-Fi, where 192.168.1.50 is somebody else's laptop or a captive portal.
Authorization: Bearer <key> and a WAV of the user's voice go out unencrypted, with nothing on
screen saying so.

Fix: a warning line next to the base-URL field when the scheme is http, and consider refusing
http outright for hosts outside RFC1918/loopback.

S8 — The privacy policy never mentions the accessibility service

Severity: medium (policy gap, Play-policy risk). Definite.

grep -niE "accessib|floating button|overlay" PRIVACY_POLICY.md returns one unrelated hit.

The permission table in §5 lists RECORD_AUDIO, INTERNET, MODIFY_AUDIO_SETTINGS/BLUETOOTH,
VIBRATE, POST_NOTIFICATIONS. The manifest also declares FOREGROUND_SERVICE,
FOREGROUND_SERVICE_MICROPHONE, FOREGROUND_SERVICE_DATA_SYNC and com.android.vending.BILLING,
and — far more importantly — a BIND_ACCESSIBILITY_SERVICE service with
canRetrieveWindowContent="true", which is the single most invasive thing the app can be granted.

The in-app disclosure is good (accessibility_service_config.xml has a proper description that the
system shows verbatim). The policy simply doesn't cover it, and Play's accessibility policy expects
the disclosure in both places.

Fix: a section of its own: what the service can see, what it actually reads, that it is
optional, and that it never stores window content. The code backs all of that up (see C4).

S9 — The GIF safe-search setting does nothing

Severity: medium (content safety). Definite.

AppPrefs.kt:1150 declares gif.contentFilter with default GifContentFilter.HIGH.
GifContentFilter.kt:17 gives each level an apiValue for KLIPY's content_filter parameter.
KlipyGifProvider.kt:65-74 builds the request with page, per_page, customer_id and q — and
never content_filter. The preference is not read anywhere, and there is no UI for it either.

So GIF search runs at whatever KLIPY defaults to, in a keyboard, with no safe-search level set.

Fix: send it, and surface the control. Or delete the enum and the preference and make the
default explicit in the request. Either is fine; the current state is the one that isn't.

S10 — A failed preference load is logged and then ignored

Severity: medium (silent data loss). Definite.

FlorisApplication.kt:117:

val result = FlorisPreferenceStore.initAndroid(...)   // returns Result<Unit>
Log.i("PREFS", result.toString())                     // ← the only handling
DictateLegacyMigrator.migrateIfNeeded(...)            // ← these write
... nine more migrators ...
preferenceStoreLoaded.value = true                    // ← unconditionally

result.isFailure is never checked. If the datastore cannot be read — corrupt file, I/O error, disk
full — the app carries on with factory defaults, the migrators immediately write, and the
defaults are persisted over whatever was there.

Failure scenario: one bad read turns into permanent loss of every API key, every custom prompt
and every setting, with a single logcat line as the only evidence. The user's next report is "the
keyboard forgot everything", and nothing on the device can tell them why.

Fix: on failure, do not run the migrators and do not let anything write; surface it (a card in
settings, or a crash dialog) so the file can be recovered before it is overwritten.

S11 — Any app can crash the keyboard by sharing it a broken image

Severity: low-medium (DoS). Definite.

FlorisCopyToClipboardActivity is exported for ACTION_SEND + image/*. onCreate calls
handleIntent(intent) with no try/catch, which calls uriToBitmap, which calls
ImageDecoder.decodeBitmap — that throws IOException on anything it cannot decode, and
OutOfMemoryError on a large enough one. A file:// URI in ClipData.newUri additionally throws
FileUriExposedException.

Same process as the IME, so the keyboard goes down with it.

Note also that setPrimaryClip happens before the decode, so the clipboard is set even when the
activity then crashes.

Fix: wrap it, set the clip only after a successful decode, and refuse file:// URIs and URIs
whose authority is our own.

S12 — Exported activities open arbitrary URIs with the app's own identity

Severity: low (hardening). Definite; no working exfiltration path found.

TranscribeShareActivity is exported, and incomingUris() reads EXTRA_PICKED_URI before it
looks at the action — so an explicit intent from any app (which bypasses the intent filter entirely)
can hand it any Uri, including file:///data/data/net.devemperor.dictate/.... copySharedFile
then calls contentResolver.openInputStream(uri) as us.

StickerImportActivity has the same shape.

I could not build a working attack: the transcribe screen refuses a file with no audio track, and
the sticker writer only accepts four MIME types resolved from the URI (so a .jetpref or .db
resolves to null and is skipped). It is still the standard confused-deputy shape and costs three
lines to close.

Fix: reject file:// and reject content:// URIs whose authority is our own, in both.

S13 — Cloud: a wallet with no credit is never rate limited

Severity: medium (cost / availability). Definite.

cloud/src/wallet.ts, debit():

if (state.status === 'blocked') return { ok: false, reason: 'blocked', ... }   // before the window
const now = Date.now();
this.hits = this.hits.filter(t => now - t < 60_000);
if (this.hits.length >= rateLimitPerMinute) return rate_limited
...
if (state.secondsLeft < wantSeconds) return insufficient                       // before the push
this.hits.push(now);                                                           // only on success

Refused requests never enter the window, so they are never counted. A token with a zero balance — or
a wallet you have just blocked for abuse — can hit /v1/audio/transcriptions as fast as it
likes. Each attempt still costs an auth query, a full formData() read, budgetAllows, and a
logUsage write to D1.

Failure scenario: you block an abusive account in the dashboard; blocking is exactly the moment
their request rate stops being limited, and the D1 write volume from logRefusal is unbounded.

Fix: push the timestamp before the status and balance checks so a refusal fills its own window.

S14 — Cloud: the upload is read into memory before anything checks its size

Severity: medium (availability). Definite.

cloud/src/routes/transcriptions.ts:38: form = await request.formData() runs before
probeDuration, before the maxAudioSeconds check, before budgetAllows and before debit. The
comment budgets for 19 MB against 128 MB — but nothing enforces 19 MB.

base64() further measures at ~2 s CPU and a 26 MB string for a 19 MB file, so a 100 MB upload is
roughly 65 MB of string on top of the buffer plus the form's own copy.

Failure scenario: anyone holding a token (a €3 pack) posts 120 MB bodies in a loop. Each blows
the isolate's memory before any limit or billing applies, so the abuse is free, and on the dashboard
it is indistinguishable from a real outage.

Fix: check content-length first and refuse over a hard cap with 413.

S15 — Cloud: the recovery-code throttle can be made to fail open

Severity: low-medium (hardening). Definite; the secret still has 59 bits behind it.

GlobalGuard.attemptCode keeps codeAttempts as one Durable Object storage value: a map from
client IP to a list of timestamps, rewritten on every attempt. A Durable Object storage value is
capped at 128 KiB. At roughly 30 bytes per address that is ~4 400 distinct addresses inside the 60 s
window — reachable from an IPv6 range or a small botnet.

Once the put throws, guardCodeAttempts catches it and returns null, i.e. allows
(cloud/src/throttle.ts:76, deliberately fail-open). The per-address limit is then off for everyone
for as long as the flood continues. The keyless global failure counter lives under a different
storage key and would survive — but it is read inside attemptCode, which threw.

Not urgent: the code is 59 bits and noteCodeFailure still raises its alert. But the control that
is supposed to hold under exactly this condition is the one that gives way under it.

Fix: cap the number of tracked addresses (evict the oldest), and read the global failure counter
outside the try so it still applies when the per-address map fails.

S16 — ZipUtils trusts the declared entry size

Severity: low. Inherited from FlorisBoard.

ZipUtils.kt:165:

private fun ZipFile.copy(srcEntry: ZipEntry, dstFile: FsFile) {
    dstFile.outputStream().use { outStream ->
        if (srcEntry.size > 100000000) return     // ← the *declared* size
        this.getInputStream(srcEntry).use { it.copyTo(outStream) }

ZipEntry.size is whatever the archive's central directory claims, and it is -1 when unknown —
which passes the check. There is no cap on total extracted bytes and none on the entry count.

Zip Slip itself is handled correctly (canonical-path prefix check at :152), and models are
checksummed, so this only applies to a .flex extension the user imports themselves. The damage is
filling the device's storage.

Fix: count bytes as they stream and abort past a budget; cap the entry count.

S17 — Dead code and dead settings

Severity: low. Definite.

301 preferences are declared; 298 are live, which is a good number. The three that are not:

• gif.contentFilter — see S9, this one is a bug, not just dead
• emoji.preferredHairStyle (AppPrefs.kt:1073) — no UI, never read, FlorisBoard leftover
• dictate.livePromptActionMigrated (AppPrefs.kt:891) — orphaned; the live migrator uses
  livePromptActionRemoved instead (DictateLegacyMigrator.kt:293)

Five TODO() calls ship in the release APK and would throw NotImplementedError if reached:
KeyboardExtension.kt:55, LanguagePackExtension.kt:62 (TODO("LOL LMAO")),
LanguagePackManagerScreen.kt:92, UserDictionary.kt:259 and :528. I traced every caller —
none is reachable: ExtensionEditScreen.kt:161 only routes ThemeExtension into the editor and
wraps it in runCatching, and reset() has no callers at all. Dead, not dangerous, but they are
five landmines with the pins already pulled for whoever extends that code next.

Also: 59 raw Log.* calls run unconditionally in release builds (the flog* family is correctly
gated on BuildConfig.DEBUG). All of the ones I read log lengths and metadata rather than content,
which is the right discipline — but it is discipline rather than a guarantee, and
Devtools.generateLogcatDump() hands the whole lot to the user's clipboard/GitHub with no
redaction pass.

S18 — runBlocking on the input path

Severity: low-medium (ANR risk). Architectural, inherited.

54 runBlocking call sites in main sources, concentrated exactly where they hurt:
AbstractEditorInstance.kt (9), InputEventDispatcher.kt (6), NlpManager.kt (4),
EditorInstance.kt (4). NlpManager.assembleCandidates() wraps the whole candidate assembly —
including getSuggestionProvider(subtype), which can be a first-use dictionary load — in a
runBlocking reached from the UI thread.

This is FlorisBoard's architecture and not something to rip out in this pass. Worth recording as the
standing explanation for the jank family already met in #334 and in typing-jank-a11y-node-fetch,
and worth a rule: no new runBlocking on the input path.

---

What was checked and found clean

This half is what makes the next audit cheap.

C1 — No telemetry of any kind. The version catalog has no Firebase, no Crashlytics, no Sentry,
no analytics SDK. Every HTTPS host referenced in app/ and lib/ is a provider the user chose, our
own API, GitHub or a docs link. There is no host that exists to hear from the app.

C2 — HttpCallDiagnostics is exemplary. It logs address families rather than addresses, and
never a URL, header, body, credential, transcript or byte of audio — and says so at the top of the
file. This is the model the rest of the logging should be held to.

C3 — Model downloads are properly verified. All 56 LocalModelFile entries carry both a byte
size and a SHA-256, over HTTPS from our own release, staged into .tmp-<id> and verified before the
atomic move (LocalModelManager.kt:112-134). A tampered model cannot be installed.

C4 — The accessibility service is disciplined about what it records. Every log line carries
lengths, class names and flags, never text (DictateAccessibilityService.kt:560, :845). It
deliberately does not subscribe to typeWindowContentChanged. Nothing it reads is persisted.

C5 — The user-facing backup gets credentials right. BackupRedaction strips the keyring's
secrets and drops the proxy pair, the KLIPY key and the legacy flat keys — before anything touches
disk, by wrapping JetPref's writer rather than rewriting the file afterwards. Choosing "share"
switches the default to redacted (BackupScreen.kt:460); a warning card appears only when
credentials really are in the archive. This is the standard S1 should be held to.

C6 — DictateWearService cannot be reached by other apps. I disassembled
play-services-wearable-19.0.0: com.google.android.gms.wearable.zzaf calls
Binder.getCallingUid() and UidVerifier.isGooglePlayServicesUid() and refuses anything else
("Caller is not GooglePlayServices; caller UID:"). All seven actions arrive through onBind, so the
exported service with no permission is safe as declared.

C7 — Android hygiene is right throughout. Every PendingIntent is FLAG_IMMUTABLE; every
dynamic receiver uses RECEIVER_NOT_EXPORTED where the broadcast is not a protected system one;
there is no WebView, no MODE_WORLD_*, no GlobalScope, no custom HostnameVerifier, no
trust-all X509TrustManager. The FileProvider exposes <cache-path> entries only. Release builds
are minified and shrunk; signing comes from an untracked keystore.properties.

C8 — No secrets in the repo or in recent history. keystore.properties, local.properties,
private/ and cloud/wrangler.jsonc are all untracked and ignored (the last is a symlink into
private/). A key-pattern scan across the last 400 commits found nothing.

C9 — Clipboard deletion takes the media with it. deleteWithMedia (row first, file second) and
the pinned-item handling in clearHistory are correct — #316 closed this properly.

C10 — History deletion is complete. deleteById, clearAll and prune each delete the row
and the retained audio, and prune enforces count, age and byte budgets with pinned entries
exempt. The history DB and its audio directory are outside the backup include-list (subject to S2).

C11 — Cloud: the money path is sound. Debit happens before the upstream call and is refunded
on failure; the server chooses the model and the output length and discards whatever the client
sends for either; the daily budget is booked in a single Durable Object and settled against measured
neurons rather than an estimate; purchase_token is the primary key, so double redemption is
structurally impossible; purchases are verified with Google directly rather than believed.

C12 — Cloud: the admin dashboard is properly gated and properly escaped. Cloudflare Access JWTs
are verified against the JWKS with alg pinned to RS256, plus issuer, audience and expiry; it fails
closed when unconfigured. Every user-influenced field on the page goes through esc() — I checked
the device label, the wallet note, the audit note and the model cell specifically. The model name is
written server-side from limits, never from the request, so there is no stored-XSS path from a
paying customer.

C13 — Cloud: token and code handling is right. 32 random bytes from crypto.getRandomValues for
the token, ~59 bits for the recovery code, both stored as SHA-256 only. Both code-bearing endpoints
are throttled per address and globally on failures. Deletion removes tokens, usage rows and alerts
and empties the wallet row, keeping only what §147 AO requires — and erases the Durable Object last,
deliberately.

C14 — Cloud: nothing content-bearing is stored. meter.ts writes numbers only — wallet id,
timestamp, kind, duration, tokens, cost, status, latency. No audio, no text, no prompts. Durable
Objects are pinned to the EU jurisdiction with a noisy fallback if that ever stops working.

---

Open measurements

Three things I would not assert without a device:

1. S2 — what Android 12+ actually does with a <full-backup-content> root in
   dataExtractionRules: back up nothing, or back up everything. One bmgr backupnow settles it.
2. S5 — whether the key-preview bubble is visibly shown in a text password field. One screenshot.
3. S1 — whether adb backup on an Android 8–11 device really yields the jetpref file. Optional;
   the include-list already proves the intent.

Suggested issues

Separate issues, in the order I would do them:

#	Finding	Why first
1	S1 + S2 (backup)	one change, and it is the only finding where data leaves the device
2	S3 + S4 (sensitivity gate)	the privacy policy currently says something the code does not do
3	S10 (preference load failure)	silent, permanent data loss from a single bad read
4	S13 + S14 (cloud limits)	cheap, and both bite exactly when you need them
5	S9 (GIF filter)	a safety setting that does nothing, in a keyboard
6	S6 + S7 (TLS and cleartext)	both are "the user cannot see what they agreed to"
7	S8 (policy: accessibility)	Play-policy exposure as well as a gap
8	S5, S11, S12, S15, S16	hardening; each is small
9	S17, S18	code health; S18 is a rule, not a change