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.
Maker here. I’m especially interested in criticism of the threat model.
If you try it, I’d love feedback on:
which rule is actually useful in practice (time/geo/visual key)
what is confusing in setup
what would increase trust fastest (spec, vectors, reproducible builds)
dkatsura•1h ago
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).
dkatsura•5m ago
As promised, here’s a minimal sketch.
*Capsule format (high-level)*
* magic + version
* crypto suite id (AEAD)
* KDF id + parameters (for password path)
* salt / nonces
* policy section (time/geo/password/visual, AND/OR AST)
* ciphertext (payload blob)
* auth tag / integrity
*Threat model (compact)*
Protects against:
* someone who only gets the `.cfcaps` file (without required secrets/rules)
* accidental/premature access during sharing (time/place/team constraints)
Does not protect against:
* fully compromised endpoint/runtime (bypass checks / exfiltrate plaintext after legitimate open)
* malicious recipient taking photos/screenshots once content is opened
If people want, I can write a 1-page spec from this (policy AST fields + encoding).
dkatsura•2h ago
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.
https://truelock.pro
dkatsura•1h ago
If you try it, I’d love feedback on:
which rule is actually useful in practice (time/geo/visual key)
what is confusing in setup
what would increase trust fastest (spec, vectors, reproducible builds)
dkatsura•1h ago
dkatsura•5m ago
*Capsule format (high-level)*
* magic + version * crypto suite id (AEAD) * KDF id + parameters (for password path) * salt / nonces * policy section (time/geo/password/visual, AND/OR AST) * ciphertext (payload blob) * auth tag / integrity
*Threat model (compact)* Protects against:
* someone who only gets the `.cfcaps` file (without required secrets/rules) * accidental/premature access during sharing (time/place/team constraints)
Does not protect against:
* fully compromised endpoint/runtime (bypass checks / exfiltrate plaintext after legitimate open) * malicious recipient taking photos/screenshots once content is opened
If people want, I can write a 1-page spec from this (policy AST fields + encoding).