Even root on our transcription host shouldn’t get your meeting archive — here’s the dual-wrap that makes that true
Indie Hackers has been the sharpest room I’ve posted this in, so I’m bringing the next boundary here.
Last thread pressure-tested the Honest Processing Window (fair). One thing I want to nail down as its own claim:
Root on the inference host ≠ “walk away with every past meeting.”
That only works if the architecture forces two different key holders for the same meeting:
Audio CEK (content encryption key)
Wrapped to the transcription host’s public key, delivered only inside the current Service Bus job (not persisted in our DB). During the Honest Processing Window the host decrypts in memory, runs ASR, then wipes.
So even a privileged operator who owns the box while a job is running can at best observe that job’s in-memory plaintext — not rewind history.
Transcript / sealed outputs
Wrapped to the user’s device RSA key. After the job, reading the archive requires the user’s vault private key — which we never hold.
Two wrap paths. Two holders. Not shared.
What we claim today:
At rest (Blob/DB): ciphertext only
Past meetings stay sealed even if someone roots a worker mid-job
We are not claiming TEE/attestation yet — a measured, attestation-gated key release would harden the live window; that’s a real upgrade path, not something we pretend to ship
What I’d love this room to whip:
Is dual-wrap the cleanest cut for “cloud ASR must hear audio once”?
Where does this still fail under malicious root / cloud-admin / poisoned image?
What should we spell more bluntly for buyers?
Whitepaper (algorithms + trust boundaries):
https://aegismeetings.com/whitepaper
If you want to keep the whipping in a higher-traffic launch thread, Product Hunt is live today — dump holes there too (UX, wording, threat model, all fair game):
https://www.producthunt.com/products/aegismeetings?launch=aegismeetings
I’ll hang out in both places.
The dual-wrap boundary is much clearer than a generic “encrypted” claim. The buyer-facing version I would make explicit is the residue around the live window: job payloads, retry queues, debug traces, metrics, support exports and derived metadata can quietly become a second archive even when Blob/DB are ciphertext only.
A compact table with each artifact, its key holder, retention period and deletion trigger would make the trust boundary auditable. Also worth stating whether a replayed job can ever obtain the audio CEK after the original window has ended. That is the kind of question a careful security reviewer will ask before they ask about algorithms.
You’re pointing at the right next layer. Dual-wrap answers who can open what; residue around the live window is where a careful reviewer looks for a quiet second archive.
On the hard question — can a replayed job obtain the audio CEK after the original window?
Not from our side. The CEK is delivered only in the current Service Bus job payload (wrapped to the transcription host), not persisted in the DB. After the job completes, we keep no lasting ability to decrypt that meeting’s audio again. A later run needs a new client-supplied wrap; we can’t resurrect the old one.
Where you’re also right: while a message is still in-flight — or briefly in DLQ before purge — that wrapped material still exists as queue residue. We sanitize keys out of telemetry, and we don’t treat metrics / metadata (paths, hashes, counts) as content. What’s missing for buyers is exactly what you asked for: a compact table of artifact → key holder → retention → deletion trigger. That’s on us to spell bluntly, not bury in algorithm prose.
If you want to keep whipping that residue list in public, PH is open too:
https://www.producthunt.com/products/aegismeetings?launch=aegismeetings