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 D8A9E43B28 for ; Fri, 12 Aug 2022 17:01:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8BCD768B924; Fri, 12 Aug 2022 20:01:56 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 82FDB68B7DF for ; Fri, 12 Aug 2022 20:01:50 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 27CH1nE3008743 for ; Fri, 12 Aug 2022 19:01:49 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 982C4E0101; Fri, 12 Aug 2022 19:01:49 +0200 (CEST) Date: Fri, 12 Aug 2022 19:01:49 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20220810222708.186270-1-derek.buitenhuis@gmail.com> <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> <20220811201834.GE2088045@pb2> <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> <20220812150517.GI2088045@pb2> MIME-Version: 1.0 In-Reply-To: <20220812150517.GI2088045@pb2> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Fri, 12 Aug 2022 19:01:49 +0200 (CEST) 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="===============1076356308353688770==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1076356308353688770== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FGFnlYuwsNeI+DVL" Content-Disposition: inline --FGFnlYuwsNeI+DVL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael Niedermayer (12022-08-12): > Maybe thinking about http is the wrong mindset. Maybe DNS is a better ana= log >=20 > to grab data from DNS you can implement a full DNS server which recursivly > resolves the request starting from the root name servers (which it needs = to have > hardcoded in some form) But this is something no application does because= of > latency and wide support of easier name resolution on platforms >=20 > So what one does is to connect to local of ISP DNS server which caches re= sults > and does resolve from the root servers if needed (either directly or thou= gh platform APIs) > Problem with IPFS is your ISP doesnt have a IPFS server nor do you have o= ne > locally normally >=20 > Below is how i understand IPFS, please someone correct me if iam wrong, i= am=20 > listing this here as i think it makes sense for the dicussion to better u= nderstand > what IPFS is before arguing about it >=20 > IPFS seems closer to DNS in how it works than to how http works > if you want to grab something from IPFS it cant just do it, it needs to c= onnect > to peers and find out which has the data.=20 > If you start from zero (and some hardcoded peer list) that will take more= time > than if there is a running node with active connections > So for better performance we want to use a IPFS node which persists befor= e and > after the process with libavformat. This is the same as with a DNS server. >=20 > I suspect IPFS provides little security against loging, > If you run a IPFS node, others can likely find out what your node cached = because > thats the whole point, of caching data, so that others can get it. > If you are concerned the http-ipfs gateway logs you, running your own nod= e might > be worse. IIUC thats like a public caching DNS server >=20 > the other threat of the http-ipfs gateway modifying data can possible be = prevented > with some effort. > IPFS urls IIUC contain the hash from a root of a merkle tree of the data = so one=20 > can take a subset of the data with some more hashes and verify that the d= ata > matcheswhat the URL refers to. This also makes data immutable. There is > mutable data in IPFS called IPNS. > IPNS uses a hash of a public key allowing the private key owner only to m= odify > the data. > again it can in principle be checked that this is all unmodifed by any in= termediate > that makes IPFS different fron DNS and HTTP(S) which cannot be checked fr= om the > URL alone All this looks a lot like =E2=80=9Cmagnet:=E2=80=9D URLs for torrents, and = we do not consider FFmpeg should support torrents. But the practice can make the difference: if leeching without seeding at all is supported, then it can make sense. The goal that everything works out of the box is limited by the need for safety for the user, and it is a concern for both a peer-to-peer protocol and for an external gateway. And it is not limited to technical security risks, it involves also legal liability: the information that somebody accessed a resource that is considered illegal in their country is more likely to leak. Also to consider: if FFmpeg hardcodes a default gateway, secondary distributors might change that default into a less trustworthy one. The simile with DNS has a significant limitation: DNS has been here since forever, and we can assume it is properly configured everywhere. In fact, FFmpeg does not use DNS, it uses the libc's resolver, which could be configured not to use DNS at all. This protocol is a newfangled thing, so the expectation that it just works is lower. It brings me to another point: how common is this thing? FFmpeg aims to support all protocols used in the world, but it is not meant to be a showcase for somebody's vanity project or some company's new commercial product. For this issue, I think the criterion the IETF uses to consider something a standard is a good touchstone: are there several independent and compatible implementations already out there? Regards, --=20 Nicolas George --FGFnlYuwsNeI+DVL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmL2h3sACgkQcZVLI8pN xgx+lA/6Am5L569IoTRzrtoSCTo6CBuSNuRLdWHYWnvKUthHQJUPIMW4i3YMrMpn a4rIGCQWCPrVP3nBAxtPjKPpwTZsF3DlI4alGLg1gME2SqN+yQyPkco7y3lPk5D3 +RBbYtWPijrAiI0zwF6lfk/GzqO88zutukwj0Hie1wjcgonEsN1hSKY2mARDHcXE o6UujNZzrQzN+61PKkbNws27m0p8xTKCzqOu3Fwh5gNkp1rU5hI+btrTXOO0t2DR bWqdb8GYgRzf7FjNo+5Kjkc7KxdFNocrCoHKeB5tsAQ22FqutMj5Oc6MMMppWCqI stKqsDuhZ4jH5lw0xovCa5dcAMqkzeEBoMCNR4Ziwzb1OyE0yXjtXemnEEa7NfiH vKbRDc0CWaPpVGkN+Z9SdNlttDUWELTwuL15oKqy8LGOcM6aXdukkSZcYZEtMDId qnD0xFg9xH6MonoDVuKqpZ5M8S2IrNL9wYPZDWgGsX+OOIXNemrEFxDZRQvfey25 bX50cxDPbsdMD+IpAJBpO15pv7VJCm4IVjF3yRm8iLDfDb01/CVt4b7bAM0L1+sV xSLlte5baP9vhxHo2Yd5eiUTR7k8mJcBpuWAB/UVFpC9CcT+Zmp3b1F7W8dPXRo6 7R/9kJQrtiMgIv+oe1VXpDw2vHfZSbitMGv9Rv2I+qEmEt1od+s= =XpQk -----END PGP SIGNATURE----- --FGFnlYuwsNeI+DVL-- --===============1076356308353688770== 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". --===============1076356308353688770==--