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
parent 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