From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 806294A464 for ; Tue, 30 Apr 2024 18:14:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 26B2568D5D4; Tue, 30 Apr 2024 21:14:29 +0300 (EEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8872C68C0C3 for ; Tue, 30 Apr 2024 21:14:22 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id D898C1BF205 for ; Tue, 30 Apr 2024 18:14:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1714500862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uy/WlputkwYYDC9DQzSDewdYv93a48dIzVnYwWDE7Q0=; b=oKm/682XQeUzDa49Dk6/M9YM4CBeWJrnAhQxqHPOXcn93BOzFXymZ6vtMBU/kqzf5n7NQg 9GFAhCZKaqFRZOzzeEVAneRUiep1FVxaT2qygF4UOf+2orpLUq++gbXZWjdD2uzZPudIvg Uh9zxYqBHSUpQDgS9gX07jTH0xmJNJk5PEg1bu2PH1BpM+93qwM6RGKSqh+pfNzE2087Rk pmRpgZLrl2gxtaCptnCoR45lbJXaImOZb8iiHydmWafn/8a9bHpi6BrKx/c5Pi+Wc5QmmG RQQFgY4sT8p50es5y6NdR+vgLxI/7f38d+BYcwz3lYkAVuMzz9wfXo6gLEeheA== Date: Tue, 30 Apr 2024 20:14:21 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240430181421.GQ6420@pb2> References: <20240417135832.GJ6420@pb2> <20240425000702.GW6420@pb2> <585c2c9d567fca5a778d3f86a657e78c32c833cd.camel@haerdin.se> <20240427105359.GC6420@pb2> <61eafec98c54e862e645172d71259ee02e052280.camel@haerdin.se> MIME-Version: 1.0 In-Reply-To: <61eafec98c54e862e645172d71259ee02e052280.camel@haerdin.se> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============8331565427965165544==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============8331565427965165544== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1drMGP8YklN/Rf9s" Content-Disposition: inline --1drMGP8YklN/Rf9s Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 27, 2024 at 08:01:14PM +0200, Tomas H=E4rdin wrote: > l=F6r 2024-04-27 klockan 12:53 +0200 skrev Michael Niedermayer: > > On Thu, Apr 25, 2024 at 12:26:00PM +0200, Tomas H=E4rdin wrote: > > > tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer: > > > > On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas H=E4rdin wrote: > > > > > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer: > > > > >=20 > > > > > > * ffchat > > > > > > =A0=A0=A0 (expand into realtime chat / zoom) this would > > > > > > =A0=A0=A0 bring in more users and developers, and we basically = have > > > > > > almost > > > > > > =A0=A0=A0 all parts for it already but some people where agains= t it > > > > >=20 > > > > > You mean inventing a new chat protocol? If so then please > > > > > don't. We > > > >=20 > > > > If theres an existing protocol that serves the purpose then > > > > theres no > > > > need to invent a new one > > > >=20 > > > > 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) > > >=20 > > > "Security" and "privacy" are relative terms. > >=20 > > yes, more security and privacy is better >=20 > 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 its= elf 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. >=20 > 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. >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > There's also GNUnet and its associated protocols like psyc. > > >=20 > > > 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. > >=20 > > sure, i agree, we should use existing protocols whenever one exists > > for a purpose already ... > >=20 > > libavformat supports, RTP, RTSP, MMS, HLS, RTMP and probably more > > we support audio, video, data and text packets/streams > >=20 > > So adding support for some more secure/private protocols is > > within the scope of libavformat. >=20 > 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 author= ities 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 >=20 > > And it would allow all multimedia players to use these more secure > > means of communicating. >=20 > 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 [...] --=20 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. --1drMGP8YklN/Rf9s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZjE0+QAKCRBhHseHBAsP q6hdAJ4wWKUFM0WDqm79qJT9U/EddtdCAwCfYyz1PIuCofVDDtgej4ndFjPdJSQ= =ElOf -----END PGP SIGNATURE----- --1drMGP8YklN/Rf9s-- --===============8331565427965165544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============8331565427965165544==--