[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Michael Niedermayer]

On Sat, Apr 27, 2024 at 08:01:14PM +0200, Tomas Härdin wrote:
> lör 2024-04-27 klockan 12:53 +0200 skrev Michael Niedermayer:
> > On Thu, Apr 25, 2024 at 12:26:00PM +0200, Tomas Härdin wrote:
> > > tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer:
> > > > On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote:
> > > > > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer:
> > > > > 
> > > > > > * ffchat
> > > > > >     (expand into realtime chat / zoom) this would
> > > > > >     bring in more users and developers, and we basically have
> > > > > > almost
> > > > > >     all parts for it already but some people where against it
> > > > > 
> > > > > You mean inventing a new chat protocol? If so then please
> > > > > don't. We
> > > > 
> > > > If theres an existing protocol that serves the purpose then
> > > > theres no
> > > > need to invent a new one
> > > > 
> > > > I think at a minimum it should have "secure and private by
> > > > default
> > > > and always"
> > > > (there are many solutions already when one is willing to give up
> > > > security/privacy)
> > > 
> > > "Security" and "privacy" are relative terms.
> > 
> > yes, more security and privacy is better
> 
> Not always. More security is typically more work.

Yes, thats of course true
I meant it more in a sense of providing a sane level of security&privacy
and then always providing the maximum security&privacy as long as it did not
add "cost" to the user.
As well as maybe automating things where that can be done without it by itself
causing more issues than it fixes.


> For example TOFU
> (trust on first use) is easy but you should really compare
> fingerprints. The latter is more work however.

> 
> I've worked with helping people who have a need or even a legal
> obligation to secure their chats, such as journalists. This is non-
> trivial.

I did not know. So i first would like to thank you for doing that
sort of stuff. The world today is increasingly in need of this.


> Have you done the necessary research on this?

probably not. Because i did not had the need for truly secure communication.
also if i had the need it would then be a specific case while the goal here
is more to have something generically usefull. Like gpg is for email.



> 
> > > If you want end-to-end encryption in a federated system then
> > > XMPP+OMEMO
> > > is the way to go. Or Matrix I guess, but it isn't standardized last
> > > time I checked.
> > > 
> > > If you want metadata resistance then Briar is the way to go. It's a
> > > peer-to-peer store-and-forward network that tunnels all its
> > > internet
> > > traffic through Tor, and also supports synchronizing messages over
> > > WiFi
> > > Direct and Bluetooth.
> > > 
> > > There's also GNUnet and its associated protocols like psyc.
> > > 
> > > Short of using some complicated thing involving data diodes you're
> > > not
> > > likely to do better than what's already out there. And nothing
> > > beats
> > > not using computers at all.
> > 
> > sure, i agree, we should use existing protocols whenever one exists
> > for a purpose already ...
> > 
> > libavformat supports, RTP, RTSP, MMS, HLS, RTMP and probably more
> > we support audio, video, data and text packets/streams
> > 
> > So adding support for some more secure/private protocols is
> > within the scope of libavformat.
> 
> I'm curious what protocols you have in mind, assuming we're still
> talking multimedia. Taking XMPP as an example, multimedia attachments
> are handled via HTTP upload, meaning playback only depends on HTTP(S)
> support. I expect most XMPP clients already leverage libav* for
> playback

Depending on the adversary. https can be a bad choice, as it can be
attacked by anyone in control of any single certificate authority so
https provides no security against nation-states / secret services or
determined large corporations.
So i would somwhat favor avoiding the dependance on such certificate authorities
also https seems it would make a central server mandatory which then
is a central point an adversary could use to monitor that being sub optimal


> 
> > And it would allow all multimedia players to use these more secure
> > means of communicating.
> 
> Why do media players need chat functionality? Should we implement email
> while we're at it?

Well, from the few conferences i did listen to (that being fflabs and IETF stuff)
its not uncommon someone has some text to pass along, like a URL or someones
microphone doesnt work. So id say the ability to exchange some text is
important.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240430/84a36629/attachment.sig>