Niche-Knack · Security review · Version 1.11.95

Lamplighter: what it protects, and what it cannot promise

Lamplighter encrypts saved private content in a protected Android installation or a saved browser app. Locking it closes access to the reader and can leave a playable game on screen. This helps protect your content, but it cannot make the app undetectable or guarantee your safety.

Encrypted means the saved information is scrambled and cannot be read normally without the right access. To let you read a passage or message, the unlocked app has to turn it back into readable text. Locking closes that access. This is protection for stored content; it is not a promise that every trace disappears from the phone or its memory. A game appearance and a locked reader are different: the icon can still look like a game after you unlock. The icon alone does not prove your content is locked.

What is protected

Your saved library and personal work

In the protected installation, Bibles, commentaries, studies, Journal entries and saved private conversations are kept in encrypted storage. Stored content identifiers do not use Bible titles or verse references. Locking closes private views and stops further private reads.

A game when the reader is locked

Sudoku, Solitaire and Chess can be played while the reader is locked. Your chosen unlock method opens the reader. A game appearance reduces casual visibility; the phone can still retain records that identify Lamplighter.

Private messages and sharing

Supported private messages and resource transfers are encrypted between the participating apps, including through the tested Bluetooth and LoRa relay route. People confirm the connection, and the recipient accepts a resource offer. Public chat is public. Nearby devices can still notice radio activity, its timing and its size.

Protected updates and saved installers

The protected Android update replaces the reader while keeping the existing encrypted library, avoiding a second bundled library. Installers kept inside the app are encrypted until an approved installation or onward transfer needs them. Android still asks permission to install.

Exports and backups

You can choose an encrypted or readable export. An encrypted study, Bible or commentary file can be opened by its creating installation or with its matching decryption QR code. A full backup has its own password. Anyone with the file and its QR code, or the backup and its password, can open that copy. Keep them separate.

What we checked for this release

The radio test used the earlier versions named in the detailed evidence. Automated browser tests are not physical iPhone tests. This release review covers Android and the browser app; older desktop downloads and app-store approvals have their own status.

Three phone checks are still outstanding

The owner waived these checks before publication and chose to test them afterward. They are not counted as passed:

“Implemented but not yet verified on a device” means the code exists and may have passed automated checks, but the named real-phone task has not passed. “Not implemented” means the app does not provide it. “Platform limitation” means the phone or browser requires a different approach. None of these labels means a test passed.

Important limits, and why they matter

A normal download is not a hidden installation

The ordinary Android download and publicly hosted browser resources can contain readable Bibles. Setting up protected storage does not encrypt a copy left in Downloads. The protection described here applies to content inside the protected installation.

A locked app is not an invisible app

The app’s program files, installed-app list, browser history, notifications, icons and old screenshots may reveal it. Private stored record names are concealed; that does not remove every religious reference from the software or the phone’s records. Android Chrome has shown a Bible preview in Recents after the browser reader closed. Explicitly lock and wait for the game before leaving; even then, encryption cannot erase previews or copies already retained elsewhere.

Different connections have different requirements

Bitchat Bluetooth messaging can work with a game appearance while the reader is unlocked and on screen. A locked, game-only screen closes private reader access. Church study connections and internet updates require Show app, which restores Lamplighter’s name and icon; the protected library remains encrypted in storage. The app cannot stop Android or other apps from using the network.

The rest of the phone is outside this protection

Lamplighter cannot secure a compromised phone or prevent all operating-system traffic. Public setup and radio discovery happen before private connection approval. Accessibility services or debugging tools with sufficient permission may read what you type; our Android test tooling could read password-field content. Screenshot blocking does not remove that access.

Shared copies and deleted files have limits

A recipient can keep an exported copy. Android removes an imported source only after checking the protected copy, and only when the file provider permits removal. A browser cannot delete the source you selected. Deleting a file does not guarantee that every recoverable copy is gone.

Backups need care

Browser storage can be cleared or removed to free space, so keep encrypted backups. Restoring creates a new messaging identity: verify contacts again; old group conversations remain readable archives. Full backups do not include the opening keys for separately exported files. Those files need their matching QR codes if the original installation is lost. Choose a long, unique password when someone copying your storage is a concern; short PINs and board sequences offer less resistance to guessing.

Installing on an iPhone without the website

The browser app provides an iPhone option without relying on an App Store listing. The local installation flow is designed to receive the app from a nearby Android phone without visiting the public website or preparing certificates online.

The iPhone user must check the complete certificate fingerprint shown by Android, manually trust that certificate in Settings, and confirm the matching connection codes. The app and library then travel over the encrypted connection. This trust affects the device, so remove the temporary certificate trust and Wi-Fi proxy setup afterward. These manual steps are required because Safari does not automatically trust a nearby phone’s certificate.

The complete first save and backup migration on a physical iPhone have not passed for this release. They are follow-up tests, not completed checks. An earlier physical installation succeeded after a retry; that does not prove the revised first-save flow.

An iPhone/browser installation cannot pass Lamplighter onward. Android is the supported sender. A locally installed iPhone copy is upgraded by installing a fresh verified copy and moving data with an encrypted backup; keep the old copy until the replacement is checked.

How far the offline messaging tests go

The physical check used an Android phone, a Linux browser relay and two nearby H1 radios. Private messages and receipts passed in both directions. A carried message survived restarts and a measured 30-minute locked wait, then arrived once. A small 426-byte resource resumed correctly. This does not prove long-distance range, weeks of carriage, additional radio hops, large-resource performance, or compatibility with every Bitchat or LoRa client. Group messages cannot yet be carried and forwarded later; carried-resource delivery still needs physical testing.

Encryption and a game appearance can reduce exposure. They cannot guarantee safety, anonymity or freedom from discovery. This report is an internal engineering review, not an independent security certification.

Detailed findings, test results and download checksums

Niche-Knack · Engineering review

Lamplighter security review 1.11.95

Prepared October 28, 2026 at 14:34 UTC
Source af4ed650f323

Lamplighter 1.11.95 provides encrypted saved content, locking behind games, and encrypted private sharing in the reviewed Android and browser paths. Encryption does not make the app invisible or guarantee safety. The owner waived three real-phone checks—offline iPhone first save, iPhone backup migration and Android selected exports—so those remain unverified. See the results below for what was actually tested.

This review covers protected Android installations and saved browser apps, their private content, hiding, sharing, updates and exports. It distinguishes automated tests from real-phone tests. Older desktop downloads and native app-store releases are outside this Android/browser release review.

What is protected

Protected content at rest

Protected Android content uses authenticated encrypted storage and a separate secret naming key. Saved PWA content uses authenticated encryption with separately derived content/address keys and a master key wrapped by Argon2id-derived protection. Opaque storage addresses do not contain Bible titles or verse references.

When the reader is locked

Locking revokes access, clears private views and app-owned mutable buffers, invalidates private reads and plaintext work, and stops private connections. Already accepted encrypted saves and narrowly authorized ciphertext delivery may finish. Slow file-provider cleanup runs outside the UI path after revocation. Content must be decrypted while the authorized reader uses it; forensic erasure of immutable strings, OS memory, or screenshots is not promised.

Files and decryption QR codes

A new encrypted study, version, or commentary export has a fresh per-file key and authenticated frames. The creating installation keeps the key inside protected storage. Another installation needs the matching file-bound decryption QR. Supported backups exclude origin export keys. Explicit unencrypted JSON exports remain readable outside the app.

Complete PWA backups and local upgrades

Password-encrypted backups include saved resources, studies, notes, attachments, preferences, contacts, and conversation history. Restore keeps the new app’s verified program files and unlock. It creates a new messaging identity, requires contact verification again, and preserves old groups as read-only archives without copying live group/courier/session authority.

Small installers and protected updates

Prepared or received installers retained inside the app are encrypted as whole blobs. The protected Android update carries the signed reader without another bundled library; the existing encrypted library remains in place. Decryption is limited to authorized installation or onward-transfer operations; OS installation still requires confirmation. Public ordinary APK/PWA files remain public.

Private peer traffic

Verified private message and supported resource bodies remain end-to-end encrypted through Bluetooth and the LoRa gateway. Peers confirm identities, and a resource recipient explicitly accepts an offer. Routing identifiers, radio discovery, packet size and timing are metadata; public chat is public.

Offline iPhone setup

A nearby Android sender creates a short-lived local certificate with fresh nonexportable hardware keys, without internet certificate preparation. The iPhone user checks exactly one certificate and its complete fingerprint, explicitly trusts it, and both devices confirm matching transfer codes. Actual app/library transfer uses HTTPS. Remove the temporary trust and Wi-Fi proxy setup afterward.

Audit findings and fixes

S01–S03 · Fresh consent and session ownership

Private transfers and protected messaging use fresh peer approval, exact token/session binding and generation checks. Concealment stops private connections. Public discovery and OS traffic remain separate from private-content authorization.

S04 · Private views and late callbacks after hiding

Hiding clears private views and revokes retained APIs. Late export, camera, contact and study callbacks cannot reopen private UI. The final release also discards a notification callback when its reader document has already been erased.

S05–S09 / S12 / S20 · Original unlock and large iPhone library saves

Original-secret launch proof rejects the wrong password before library transfer. The new path verifies and encrypts each resource into staging records, then commits atomically, avoiding the former whole-library clone. The original interrupted 1.90 first save remains historical evidence; its process restart was observed but its cause was not proven. The revised full first save is still unverified on a physical iPhone; the owner waived that check for this release.

S10 · Updating without reinstalling readable bundled Bibles

The signed protected companion carries the reader without a second bundled library and retains the existing encrypted library. The ordinary public APK remains a separate, readable package. The actual website-update retention check is listed below.

S11 / S14 · Cleanup after Stop or hiding

Admitted operations keep an immutable owner/epoch. Late hotspot, enrollment, network and receipt callbacks cannot publish into a revoked operation. Keys and plaintext authority are revoked before slow file-provider cleanup runs outside the UI path.

S13 · Radio control-packet loss

Bounded paced handshake/control retries and explicit fresh user retry preserve mutual approval and replay protection. A separate two-H1 deliberate-loss test recovered after about seven and a half minutes. Range and multiweek carriage remain unverified.

S15 · Hosted PWA policy and artifact identity

The deployment helpers validate the exact packaged private assets, entry files and response policy. The final staged release is checked before promotion. The deliberate production execution hold and any manual recovery retain their actual CI outcomes.

S16 · Unauthenticated certificate bootstrap payloads

The local HTTP guide serves one DER certificate, not a combined configuration profile. The user must inspect exactly one certificate and compare all 32 fingerprint bytes in iPhone Settings. Wi-Fi proxy configuration is a separate manual step. Automatic trust and a signed combined profile are not part of this flow.

S17 / S18 · Local sender state, keys and lease expiry

Hiding clears retained library choices and invalidates callbacks. Startup cleans only the feature-owned key namespace and refuses new local identity use if cleanup fails. Listener lifetime cannot exceed the certificate’s remaining 15-minute lease; session expiry removes owned keys and listeners.

S19 · Meaningful source and ciphertext tests

Pinned test dependencies and authenticated structural envelope checks replaced a random-ciphertext substring false positive. Historical failed runs remain failed; source, target, staged, device and publication results are reported separately.

S21 · Local PWA program upgrades and complete migration

Local per-transfer origins still require a fresh verified installation. Complete encrypted backups now move saved resources, studies, notes, attachments, preferences, contacts and conversation history while retaining the new app and unlock. Live messaging authority and origin export keys are excluded; contacts must be verified again and old groups become read-only archives.

S22 · Backup restore must not clone a study writer

Restore assigns a fresh study-writer identity and resets its next-event sequence while preserving historical events, revisions and deletion history. It does not copy the source installation’s authority for creating new events.

S23 · Visible game taps before input initialization

A deterministic test proved that early taps could be dropped before the layout reply arrived. The game now receives only its validated public layout before insertion; passwords and chosen places remain outside the game. Existing source, epoch, face and pending-save checks remain. This fixes the reproduced defect without claiming it was the proven cause of CI5475’s earlier failure.

S24 · Selected file protection and stale document pickers

Each encrypted export has a new file key and authenticated final manifest; another installation needs the file-bound QR. Stale/canceled native pickers cannot reuse an earlier plaintext destination. Import verifies durable protected storage and an unchanged source before attempting provider deletion. Explicit plaintext export remains available.

S25 · Reader-owned data in protected updates

The update and Pass it on paths treated every bundled file except the catalog as library, which would have left new word data behind. 1.11.94 takes the library from the catalog itself: listed Bibles, commentaries and resources stay in the existing encrypted library, and every other reader file must arrive with the update and match the signed inventory.

S26 · Password visibility to privileged accessibility and test tools

Recorded limitation, not a claim of a completed fix: the prior A14 automation could inspect typed password-field values. The shipping UI uses password input controls and the protected native window blocks screenshots, but these are not a guarantee against privileged accessibility/debugging access or an untrusted keyboard. The test driver’s temporary UI-dump file is a separate test-tool artifact; root removed that file after reading and retains only redacted field summaries.

S27 · Sudoku shortcuts consumed password digits and editing keys

The document-level Sudoku keyboard handler consumed digits and editing/cursor keys while the game password input was focused; its notes shortcut also changed the board state. The handler now ignores editable controls. Real keyboard typing reproduced the original failure and passed after the fix, including unchanged game progress and a successful reader unlock. The root also observed the failing keyboard-event path on the A14. This explains that reproduced failure, not every earlier report of slow decryption.

What was verified

Current source checks and unchanged native code

Exact-source full software gate passed; native JVM checks bound by unchanged source

The exact 1.11.95 source passed 394 application units, 55 release-tool checks, 10 narration checks, 520 renderer/browser cases (10 existing skips), 71 PWA units, 255 PWA browser cases total across three engines, and 19 Rust tests in CI run 5481. Its native Android app source is byte-identical to the tree that passed 288 JVM tests in 53 suites. Those JVM results are reused with an explicit source binding, not described as a fresh hardware test.

Exact-source CI and packaged browser staging

Exact-source CI and all 255 packaged-browser staging cases passed

CI run 5481 passed the exact af4ed650 source gate and signed direct Android build. The retained 1.11.95 PWA archive passed all 255 staging cases total across Chromium, Firefox and WebKit. Production promotion then stopped only at the deliberate publication hold; that CI failure is preserved. The planned manual recovery uses these same archived bytes and records its public readback separately. Native iOS and Play publication remain separate from this direct Android/browser release.

Protected website update on the A14

Passed on the Samsung A14 running Android15 with the exact final signed companion

The A14 installed 1.11.95 through the actual signed website check, encrypted in-app download and Android Update confirmation. The installed APK exactly matches the published companion. All 22 existing bundled library entries (182,970,570 bytes), the Genesis1:1 pin and original configured password remained. All 55 added reader-owned JSON entries match the final build; the Interlinear view, a main-reader word-reference card and its Reading toggle worked. Real Android key events preserved password digits and backspace editing, then opened the reader. A locked library read was refused. The read-only controller ended locked and was removed; no files remained in the app’s external files folder. This fresh fixture contained no imported resources, contacts or studies, so their preservation is not claimed by this device check.

Sudoku password keyboard correction

Reproduced before the fix; focused software checks and actual A14 key-event unlock passed

Actual key events reproduced dropped digits on the unchanged 1.11.94 runtime. Sudoku now leaves input, textarea, select and editable-content keys alone. Six complete password setup, cue, typing/editing, unlock and relock checks passed across all three games and desktop/phone layouts. Two editable-control and normal-board-keyboard checks, 26 surrounding browser checks and 11 relevant unit tests passed. The exact CSP hash changed without adding permissions. The same fix bytes are in 1.11.95. This does not claim every earlier decryption delay had this cause; the final A14 also passed original-password entry and backspace editing using Android key events through the normal password field. Tapping each key on an on-screen keyboard layout was not independently qualified.

Physical mixed Bluetooth/LoRa and carried messages

Historical device checks passed; unchanged dedicated transport source bound to 1.11.95

The measured physical route used Android 1.11.90, PWA 1.11.91, Linux Chromium with experimental Web Bluetooth, and two nearby H1 radios. Private messages/receipts, an explicitly joined group message, a 30-minute locked courier carry surviving restarts, and a 426-byte encrypted resource transfer with resume and duplicate suppression passed. The 22 dedicated protocol/transport files remain byte-identical to that run. All 32 tracked files match the reviewed 1.11.93 binding; five supporting contact/storage/UI/lifecycle files changed since the physical run and have software checks, not a new complete physical radio run. The 1.11.95 source rebuilds the qualified 1.11.93 gateway ZIP byte for byte. These are not distance, large-resource, radio-repeater or multiweek tests.

Checks the owner waived for this release

These checks did not run before publication. They are not counted as passed.

What “incompletely qualified” means

“Implemented but not yet verified on a device” means the code exists and may have passed automated checks, but the named real-phone task has not passed. “Not implemented” means the app does not provide it. “Platform limitation” means the phone or browser requires a different approach. None of these labels means a test passed.

Limits that encryption does not remove

Release and download integrity

Security report generation precedes broad website/PWA promotion. The protected update may first be staged at an immutable artifact URL and an IP-scoped test endpoint for its real-phone canary. Final publication requires the exact signed artifacts, full website gate, preserved unrelated pages/services, and public byte/header readback.

Platform instructions