Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Z0T <zot@mochela.it>
To: galene@lists.galene.org
Subject: [Galene] End-to-end encryption, revisited (SFrame, client-side only)
Date: Sun, 11 Oct 2026 13:31:00 +0000	[thread overview]
Message-ID: <681d4233-ab7f-4f23-a85b-a852823978d2@mochela.it> (raw)
In-Reply-To: <0eae8676-9575-4930-b0ee-d364251cf1d0@mochela.it>

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




           reply	other threads:[~2026-10-11 13:31 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <0eae8676-9575-4930-b0ee-d364251cf1d0@mochela.it>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=681d4233-ab7f-4f23-a85b-a852823978d2@mochela.it \
    --to=zot@mochela.it \
    --cc=galene@lists.galene.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox