dkatsura

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?

Maker here. Quick challenge for the skeptics:

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?

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).

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).

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)

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.

https://truelock.pro