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 B915541126 for ; Sun, 14 Aug 2022 18:00:17 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9CD7968B7F3; Sun, 14 Aug 2022 21:00:13 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0D1C368B722 for ; Sun, 14 Aug 2022 21:00:06 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id D576E24000C for ; Sun, 14 Aug 2022 18:00:05 +0000 (UTC) Date: Sun, 14 Aug 2022 20:00:04 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220814180004.GO2088045@pb2> References: <20220811201834.GE2088045@pb2> <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> <20220812150517.GI2088045@pb2> <20220812171843.GL2088045@pb2> <20220813162923.GN2088045@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway 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="===============2398403928736237523==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2398403928736237523== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JIgDBBEDRU2Tt5Ar" Content-Disposition: inline --JIgDBBEDRU2Tt5Ar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2022 at 09:06:50PM +0200, Timo Rothenpieler wrote: > On 13.08.2022 18:29, Michael Niedermayer wrote: > > I fully support better IPFS support > > what iam a bit "upset" about is that running a IPFS node is presented as > > if that was more private than using a gateway. >=20 > That's not what people are suggesting. > The primary upset is about FFmpeg having hardcoded in a public gateway run > by some company. > That is unprecedented for FFmpeg. > You have to keep in mind that that code will make it into a ton of distro= s, > installed applications and who knows what else, for a very long time to > come. >=20 > What if in 5 years that company goes under, and the domain is sold? > Or it just decides to "become evil"? What if it already is? I don't know > that company, or how they earn their money with running a public service > like that. > There are so many issues with hardcoding a domain like that into FFmpeg, > that I'm surprised really anyone is defending it. I think i misunderstood your concern.=20 [...] > > Consider this: > > If i want to know who downloads assetXYZ i can simple create 1000 nodes= each > > sharing assetXYZ. (this can in reality be 1 node pretending to be 1000) > > If you now request assetXYZ from IPFS then the node you use will likely > > download it straight from one of my 1000 nodes, i get your IP, yes we > > have a encrypted connection but that goes straight to my attack nodes > > you notice nothing of this, i log your IP and time. > >=20 > > If you used some public gateway, i would just log the time and IP of th= at > > public gateway > >=20 > > If you want really private IPFS with you need TOR or something > > equivalent. > > If someone posts a patch to add native TOR support i surely wont be unh= appy > > I also would very welcome more native IPFS support but that alone does = not > > fix the privacy / logging issue > >=20 > > Also i would be VERY happy if iam wrong and running a IPFS node can be = made > > 100% secure and private >=20 > I don't really understand how that is at all relevant to the issue at han= d: > We have hardcoded a companies server into our main codebase. Thus we endo= rse > that company and basically say that we trust it. That default was in no way intended as an endorsment. That view that this c= an be seen as an endorsment is something i totally missed > Which I for one do not. I don't know it at all. i also dont know it at all > If it turns out that company is acting badly, it will also reflect badly = on > the project. We, as a project, simply cannot do that. >=20 > It's easy to say that "a user will just pick the first gateway found on > google anyway", but we cannot safe users from their own responsibility > there. > It's our responsibility to be trustworthy. Hardcoding servers like this d= oes > not instill trust. >=20 > Specially if the IPFS project then publishes a big blog post about ffmpeg > having gained "native" support, which makes the whole effort appear even > more dubious, since the support that was added is very much not native. >=20 > > independant of this, i would very much welcome the current gateway code= to > > be extended to verify the content so the gateway cannot modify it! > > And this should be enabled for non local gateways by default i think >=20 > Seems like a good idea in any case. No idea how ipfs works, but does the = url > not work as hash for the contents it points to? the way i understand it, it does. But IIRC its not just a hash its the hash= from the root of a merkle tree. That way it can verify partial data. And this is important for us. Consider someone downloads a 5gb file from ipfs to play it back, we cant re= ally wait to receive the whole 5gb before verifing also there are v0 and v1 of CIDs, version 1 seems quite rich in what it can represent, i presume only a small subset matters but all this would be bett= er to be explained by someone who knows this. Iam just reading the docs a bit and iam a bit curious. Everything i say about IPFS internals is based on how i understand it and could be inaccurate thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued --JIgDBBEDRU2Tt5Ar Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYvk4IAAKCRBhHseHBAsP q+GgAJwMG8X+K89uMv149R4Ne2ai4itzLwCdGwD4aBtAs9HQi9ws7MEoB148HFM= =Cs5t -----END PGP SIGNATURE----- --JIgDBBEDRU2Tt5Ar-- --===============2398403928736237523== 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". --===============2398403928736237523==--