Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
* [Galene] End-to-end encryption, revisited (SFrame, client-side only)
       [not found] <0eae8676-9575-4930-b0ee-d364251cf1d0@mochela.it>
@ 2026-10-11 13:31 ` Z0T
  0 siblings, 0 replies; only message in thread
From: Z0T @ 2026-10-11 13:31 UTC (permalink / raw)
  To: galene

Hello Juliusz


I run Galène 1.2.1 for a small, volunteer-run mail and messaging service 
(mochela.it, three nodes in three EU countries, everything free software 
and deployed with Ansible). Thank you for Galène.

I'm writing about end-to-end encryption. I read your message of 1 
October 2021 in the thread "End-to-end encryption [was: User 
management]", where you listed three obstacles: no standard frame 
format, Galène needing to read packets for keyframe detection and 
simulcast, and VP8 simulcast being impossible with encrypted payloads. 
You concluded it would need a couple of years. Five years later, some of 
this has moved:

- SFrame is now RFC 9605 (2024), so the frame format no longer has to be 
invented;
- current Chrome, Firefox and Safari all support encoded transforms in 
some form (createEncodedStreams or RTCRtpScriptTransform);
- VP9 and AV1 simulcast/SVC do not require rewriting the payload.

What I have in mind is an opt-in, client-side-only feature that leaves 
the server untouched:

1. a per-group setting, or simply a key present in the URL fragment 
(never sent to the server), enables encryption in the browser;
2. frames are encrypted with SFrame (AES-256-GCM), keys derived from a 
shared group secret with HKDF; no new dependencies, only WebCrypto;
3. encrypted groups are restricted to VP9 or AV1, with whatever minimal 
unencrypted prefix Galène still needs for keyframe detection, documented 
explicitly;
4. the UI states clearly what this does and does not protect.


Before writing any code I would like to ask:

- Do you think the time is now right for this, or are there obstacles 
I'm missing?
- Would you accept such a contribution upstream (MIT, small, loaded 
lazily so it costs nothing to groups that don't use it), or would you 
prefer it to live as a separate client?
- Which unencrypted bytes, if any, does the current server actually need 
from VP9 and AV1 frames?

I'm happy to do the work and the cross-browser testing, and to start 
with a design note on the list.

PS. To do this I proposed I'll use AI contribute.

Tell me you decision

Tkanks.

Best regards,


Alberto
mochela.it




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-10-11 13:31 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <0eae8676-9575-4930-b0ee-d364251cf1d0@mochela.it>
2026-10-11 13:31 ` [Galene] End-to-end encryption, revisited (SFrame, client-side only) Z0T

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox