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 C1012434C5 for ; Sat, 13 Aug 2022 19:06:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DC57C68B7D2; Sat, 13 Aug 2022 22:06:56 +0300 (EEST) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C7BDA68B580 for ; Sat, 13 Aug 2022 22:06:50 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 5A0B72F582C for ; Sat, 13 Aug 2022 21:06:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1660417610; bh=Y7blLruCvAID9aDZF1ltGf9voqgxnGlmXYVcYoQCh/E=; h=Date:Subject:To:References:From:In-Reply-To; b=E18DFzko5ZxDxjl5OhRUvYMbUxEsk0lgBblr/ilk/CJahI6Hv9EJ+uDtjScYUZiLw FwkzECXI5wJjrgqSHLGj9MuBCa0Pk3VE+L5u5sZCK2F6wCIv0JOkvHSQshieYDI3rA p66tG2sx5FIEY4yat2pypuqoN38uvi+jugcYg643s+n0awR2bFSzp7j0X5avNHFn1a Q0+4HAj7EBG8oQVuQe2j7aqNvHJmIiu5uQ0hhnHazMCQHQn100dqlevqtJU0Vvaf2A FsnZ7Fv7IaXg3ufsuxIrn5tsoOm7DyWPGEz7hTd6+0+sXcYCXyp2txstUcEXhzPM2t uzug0eK38oLPA== Message-ID: Date: Sat, 13 Aug 2022 21:06:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> <20220811201834.GE2088045@pb2> <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> <20220812150517.GI2088045@pb2> <20220812171843.GL2088045@pb2> <20220813162923.GN2088045@pb2> From: Timo Rothenpieler In-Reply-To: <20220813162923.GN2088045@pb2> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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. 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 distros, installed applications and who knows what else, for a very long time to come. 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. > If you use a gateway there are 2 options > A. the gateway is honest then you have decent privacy > B. the gateway logs you, in which case you have no privacy > > OTOH if you run a node > You have no privacy either way If you run a node, you have put enough effort in, that you at least understand what is happening. People understand torrents, which have the same issue, and manage to use them. > 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. > > If you used some public gateway, i would just log the time and IP of that > public gateway > > 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 unhappy > I also would very welcome more native IPFS support but that alone does not > fix the privacy / logging issue > > Also i would be VERY happy if iam wrong and running a IPFS node can be made > 100% secure and private I don't really understand how that is at all relevant to the issue at hand: We have hardcoded a companies server into our main codebase. Thus we endorse that company and basically say that we trust it. Which I for one do not. I don't 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. 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 does not instill trust. 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. > 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 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? _______________________________________________ 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".