Launched this week
AegisMeetings
Meeting notes sealed — even if our DB is stolen
17 followers
Meeting notes sealed — even if our DB is stolen
17 followers
Built so even with a stolen DB + root everywhere, I still can’t decrypt finished meetings (audio, transcripts, summaries, vocab). Honest limit: one-job ASR RAM window—not E2EE. Founding limited · pay first, then vault. ≤30h transcription in 7 days → unconditional refund. Poke holes welcome. https://aegismeetings.com/
In the process where audio keys are re-wrapped using the 'transcription host public key' and transmitted to the transcription cluster, how does the system ensure forward secrecy and manage the key lifecycle for the transcription host’s asymmetric key pair? If the transcription host's private key were compromised in the future, could an attacker retroactively decrypt audio keys stored in intercepted historical Service Bus task messages?
@sy_hsu Great catch. Today the transcription host uses a long-lived key pair: audio CEKs are wrapped to that pubkey, sent only in the Service Bus job (not stored in our DB), unwrapped in RAM, then wiped after ASR.
So no true forward secrecy on that wrap path yet — if the host private key were stolen later and someone had old intercepted SB payloads + blob ciphertext, those jobs could be unwrapped. We mitigate by not persisting wraps, short-lived queue messages, and a locked-down host — but that’s operational, not FS.
Ephemeral / per-job wrapping (+ key rotation) is the roadmap. Happy to hear design critiques.
love that you're putting the refund policy and the honest "not E2EE" caveat right on the landing page instead of burying it. the transparency about the ASR RAM window basically invites scrutiny and that kind of openness is rare these days. poking the link now to see if the vault holds up.
@metehanzgg5 thanks — refund + the “not E2EE” bit are on the page on purpose.
seriously, go poke it. if you want to test end-to-end then hit refund after, that’s fine — then tell me straight if anything felt like we were bullshitting.
one catch: after a refund the system blocks buying again (keeps abuse down). if you tested, refunded, and actually want to keep using it, email service@aegismeetings.com and I’ll reopen purchase for you.
Tried it with a couple of calls and liked that the security limits are spelled out plainly instead of buried. The ASR decrypt window caveat is the kind of honesty I'd want before trusting anything with sensitive transcripts.
@nazmiyeemi0thh Appreciate that. We put the ASR decrypt window up front on purpose — no buried caveats. Glad a few calls felt okay.
What would make you trust it more next — tighter wording, or a clear “no cloud ASR” option?
the way you framed the actual e2ee boundary around the ASR decrypt window is refreshingly honest, most "secure meeting" tools just hand-wave that part and you called it out clean.
@zehra1029646 Thanks Zehra. That’s exactly what we were aiming for，a real implementation, not a marketing fog machine. No fake “E2EE everywhere,” no soft edges on the hard parts.
We name the weakness on purpose: ASR needs a short decrypt window in RAM. Then we document how we shrink it，job-scoped keys, no durable plaintext at rest, isolated transcription host, wipe after the job. Honesty first; controls second.
If anything is unclear, or you want to dig deeper，even sharp questions，I’m very happy to answer.
the honesty about the ASR decrypt window is refreshing. most E2EE products bury their limitations or hide them behind marketing, but you just put the actual tradeoff front and center. that kind of transparency builds more trust than the encryption itself.
@gnlsincarytnm Thanks — that means a lot. We debated soft-labeling it “E2EE with a caveat” and decided that just teaches people the wrong mental model. If ASR has to see audio once, say so up front; trust is cheaper to earn that way than to repair later.
If anything in the whitepaper still feels hand-wavy (especially the processing window), poke it. Prefer hard questions over compliments.