Every time I see the term "Zero knowledge encryption" something dies inside of me, as "Zero Knowledge" is not a property of ciphertexts but proofs. But this has seriously taken things up a notch: the server learns both plaintext audio and and transcripts. So that's literally "full knowledge" encryption.
Just drop encryption altogether, the server is trusted anyway. It adds absolutely no guarantees on anything than without the way encryption is currently performed.
You make a fair point about terminology. To be precise: our encryption is client-side AES-256-GCM encryption of the stored transcript meaning once transcription completes, the text is encrypted in your browser before being saved, and we can't read the stored transcript without your password. The audio is processed on our GPU during transcription and then deleted."Zero-knowledge" was used loosely a more accurate term would be "client-side encrypted storage". The server does see the audio during processing (that's how GPU transcription works), but the final stored transcript is encrypted with a key derived from your password that never leaves your browser. Update our terminology to be more precise and also the HN thread title. Thanks for the feedback and I hope something in you lives a little again.
> The server does see the audio during processing (that's how GPU transcription works), but the final stored transcript is encrypted with a key derived from your password that never leaves your browser.
You conveniently omit mentioning that the server also sees the transcript before returning it to the client side browser. Whether it is "immediately" erased, is something the client must trust the server to do. You might as well save yourself the roundtrip by encrypting server side, returning the key, then deleting it, same outcome.
Thanks for pushing us on this, you're right. We've updated all our terminology and documentation to be fully transparent:
- Security page now explicitly states the server sees audio + transcript during processing
- Privacy policy and terms updated with a bit clearer language about what's protected vs what's not
For users who need true end-to-end privacy where audio never touches shared servers, we're launching Private Cloud and Self-Hosted options: https://stt.ai/private-cloud/ Your feedback directly shaped these changes. Appreciate it.
Every time I see the term "Zero knowledge encryption" something dies inside of me, as "Zero Knowledge" is not a property of ciphertexts but proofs. But this has seriously taken things up a notch: the server learns both plaintext audio and and transcripts. So that's literally "full knowledge" encryption.
Just drop encryption altogether, the server is trusted anyway. It adds absolutely no guarantees on anything than without the way encryption is currently performed.
You make a fair point about terminology. To be precise: our encryption is client-side AES-256-GCM encryption of the stored transcript meaning once transcription completes, the text is encrypted in your browser before being saved, and we can't read the stored transcript without your password. The audio is processed on our GPU during transcription and then deleted."Zero-knowledge" was used loosely a more accurate term would be "client-side encrypted storage". The server does see the audio during processing (that's how GPU transcription works), but the final stored transcript is encrypted with a key derived from your password that never leaves your browser. Update our terminology to be more precise and also the HN thread title. Thanks for the feedback and I hope something in you lives a little again.
> The server does see the audio during processing (that's how GPU transcription works), but the final stored transcript is encrypted with a key derived from your password that never leaves your browser.
You conveniently omit mentioning that the server also sees the transcript before returning it to the client side browser. Whether it is "immediately" erased, is something the client must trust the server to do. You might as well save yourself the roundtrip by encrypting server side, returning the key, then deleting it, same outcome.
Thanks for pushing us on this, you're right. We've updated all our terminology and documentation to be fully transparent: - Security page now explicitly states the server sees audio + transcript during processing - Privacy policy and terms updated with a bit clearer language about what's protected vs what's not For users who need true end-to-end privacy where audio never touches shared servers, we're launching Private Cloud and Self-Hosted options: https://stt.ai/private-cloud/ Your feedback directly shaped these changes. Appreciate it.