Indie builder working on TrueLock: offline-first encrypted capsules (.cfcaps) where ciphertext + unlock policy travel together. Rules: time/geo/password/visual keys with AND/OR. Android + Windows. Honest threat model: app-layer enforcement (not DRM / not tamper-proof). Here to learn from feedback and improve the docs + UX.
Maker here. If you think this is security theater, please don’t be polite — pick one and attack it:
1. “policy travels with ciphertext” — why is that a bad idea vs external workflow?
2. geo/time gating — useless gimmick or actually valuable friction?
3. visual key — dumb novelty or practical multi-party secret?
I’m genuinely trying to find the sharpest criticism, not compliments.
Maker here — adding a concrete detail to make critique easier.
Capsule = one file: header (version, KDF/AEAD ids) + encrypted payload chunks + policy tree (AND/OR over time/geo/password/visual). Password path uses Argon2id; payload encryption is AEAD (AES-GCM or ChaCha20-Poly1305).
If you were reviewing this: what would you want first — (a) public capsule format spec, (b) test vectors for decrypt/verify, or (c) a short threat-model page with explicit non-goals?
Assume the capsule file leaks (someone forwards/copies it). In your view, does embedding the access policy (time/geo/password/visual key) into the same artifact as the ciphertext add any value, or is it pure security theater?
If you think it’s theater, what’s the smallest, most realistic bypass you’d try first — and what constraint would you add to make this primitive actually useful?
Design question: for Windows geo I chose a phone relay (QR challenge/proof) instead of trusting desktop location APIs. Is that the right tradeoff in your view, or would you prefer a different approach?
If useful, I can post a minimal capsule format sketch (header + policy fields)
and a compact threat-model table (what it protects vs. what it does not).
I built TrueLock to share content that opens only under rules, without cloud dependency or a central service.
A capsule is one .cfcaps file containing encrypted payload + an embedded unlock policy.
The recipient gets one file, and the app checks rules locally before open.
Current rules:
time window
geo radius
password
visual key (up to 5 images)
AND/OR logic across rules
Windows geo can be confirmed via a phone relay (QR challenge/proof flow).
Capsules can contain text and attachments (including media).
Current clients: Android + Windows.
Crypto in current build: AEAD (AES-GCM / ChaCha20-Poly1305) + Argon2id for passwords.
Format: cross-platform capsule container.
Threat-model boundary:
This is application-layer enforcement. A fully compromised endpoint/runtime can bypass local checks or exfiltrate plaintext after legitimate open. The goal is programmable disclosure in normal environments (reduce premature/accidental access).
I’d value technical feedback on:
threat-model clarity
most compelling real use case
which trust artifact is most useful next (format spec, vectors, reproducible builds, etc.)
Quick test: set a time window (e.g., unlock in 2 minutes), share the .cfcaps, try open before/after.