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 F1BDE43461 for ; Fri, 12 Aug 2022 13:43:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 601CD68B926; Fri, 12 Aug 2022 16:43:27 +0300 (EEST) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C6E5C68B58E for ; Fri, 12 Aug 2022 16:43:20 +0300 (EEST) Received: by mail-ej1-f54.google.com with SMTP id y13so2069847ejp.13 for ; Fri, 12 Aug 2022 06:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=UhiGt2EuAboUYMt+ZJxPzOA6xJXj1HkP40e+gNDYmzg=; b=Y7+GIZQABYhEibJRRpHK0UwWzog/M5CXsQ+FtkikuicyP8l+tpsPUIdnxYsh5z9IDB lwykIRcJp/ExRk9U5A3UPKmME/YmoL9TO9ZoY8j2JX5ptSxLAOGGVTBXS4IeYAL0FsLC pEAIYOmxN0Ik2t4bgqoQcAqAHcfyyxaEfyqZg9oTGjFf9qNZ7AeAjp30r8iLQn39/+JW 6Iaz65zow2dQiZzpQUXOYJ438ouBTQkR5Yj/agmmyii+u50D8IS63oa+0NYc7Ehkf95F yQfW7ZKDfw9QE5SamDa9IWFd2a2iREDQ+UIQVJUpZfIlmP3D60TfUY40BHaCXkYOYKWv 4jxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=UhiGt2EuAboUYMt+ZJxPzOA6xJXj1HkP40e+gNDYmzg=; b=4qQHhm2gMAqWhwABRjWfuqPJHwriUJY1JHU6bRlwLXOMM8wyRzH3mo8PYmx2y9VDR9 XUmPdTLAMaLsYzxPz55r8dQhxXXLf2/e5ihyovc3B3NxI6G4a3A4h+7ktueKgxSsjo30 LJuWqSiot7Vq6/08/12WoFhQWvuBAgx9mqNt/6pqLKeNAFj6RFei2ipXyQ1x/XJLGgVa vhUnpkeJ0pGkRVCKunt/CmdC/PY3tZwhXzOAAMTU9TR1SjpRddfxTeiXfWZgH9O5r+GJ Q3I0uVatQfv625kDNFbp+G8N+8hGoU26Kd6Vj8kZY3Kns2LhH7nWakM11gWI7KA6Cl2x z4eg== X-Gm-Message-State: ACgBeo1JIZzDTES5zbAuaSHtC3biIrT47fnaFrxVhpY1InqbiAN8vsHS DRrVk5QuUZv0algpon0MhTgHLFdHLTTvqL79ED/302/O X-Google-Smtp-Source: AA6agR5CVnnYZDewo2JHj627DvJLRBpxKJ7ZmlnyOdGmoqymC1lwQDlfkF3cObffvNCMwVLp7P5HBvGScRb/elsCsOg= X-Received: by 2002:a17:906:fd84:b0:730:acee:d067 with SMTP id xa4-20020a170906fd8400b00730aceed067mr2834035ejb.206.1660311799578; Fri, 12 Aug 2022 06:43:19 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Mark Gaiser Date: Fri, 12 Aug 2022 15:43:03 +0200 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis < derek.buitenhuis@gmail.com> wrote: > On 8/11/2022 11:03 PM, Timo Rothenpieler wrote: > > Any kind of built in hardcoded server is not acceptable imo. > > Even with it pointing to our own infrastructure, we can't really > > guarantee its availability, specially should the protocol gain traction > > and heavy use. > > I agree... we should never send a users data through *any* service they > haven't explicitly asked for. Ever. Regardless of who runs it and who > is deemed "trustworthy". > > > The patch wasn't on my radar at all. I had assumed it was actually > > implementing IPFS in some fashion. > > Yes, I had assumed the same too, and thus wasn't following the sets > at all. > > As it exists right now though, I don't really see why lavf needs what > amounts to a URL builder for a service as a "protocol" - this totally > the wrong layer to do that at... > > - Derek > (not a specific reply to you, Derek, just a reply to the latest message in this discussion.) First I'd like to highlight the idea of security here. As that seems to play a big part in this thread. The points Michael makes with regards to letting a user find a gateway are in my opinion valid. If a user googles for a gateway, you hope they would find/use dweb.link, as it is a safe option. Now I'm not saying other gateways are "less safe", not at all! But the dweb.link gateway is run by protocol labs themselves and is used a lot. It has a team behind it monitoring it who have a quite high responsibility of keeping the gateway functioning properly. Not many gateways have the resources behind it that dweb.link has. Also, with regards to video playback, that is guaranteed to work on dweb.link whereas less resource heavy gateways could potentially throttle such traffic. I won't call out names but i do know of at least 1 very popular one that does this. I don't know how far I can answer organizational details about dweb.link, but I do know that it's of high importance for Protocol Labs to make sure the gateway functions normally. If there are questions about security audits or guarantees about "user data" [1] policies then I can forward those to the persons who know or have the ability to get answers. That all being said. In the case where the user has no local gateway (still a likely fact) it would be far more secure to have a fallback one (dweb.link) then to let the user google one. Just pushing a sensationalized view of "it has to go because of security" might actually have the adverse effect so be very careful and constructive when you say that. Now to play devel's advocate for a moment. Say dweb.link remains as default, how likely is it to be hacked and truly causing harm for ffmpeg users? A lot of steps have to happen before that harm really can be done, here's a list of things i can come up with (but it's likely much longer). - the gateway would have to be hacked and that would not be detected (unlikely) - the malicious party would have to change gateway code and still remain undetected (again unlikely) - ffmpeg users would actually get malicious data (unlikely) - that malicious data would have to be able to cause actual harm (yet again unlikely, ffmpeg is more likely to crash with malicious data [2]) So in realistic terms, how likely is it that dweb.link causes an actual security risk for the user? The more I think about it, the less likely I think that's going to be. On the other hand, removing the default gateway very definitely has a much higher potential for a security risk. I hope we can proceed this discussion in a more mature way with actual constructive arguments. Passionate and emotional calls to remove this "just because" won't help the discussion forward by any means. I also ask to refrain from arguments like "it should've never been merged and therefore removed", that's like a very demotivating response to even consider responding to. So keep it nice and constructive and we'll figure out a way that works for everyone :) [1] there are no users.. At most you have webserver logging winch, with other data, could be used for tracking purposes perhaps. [2] for malicious data to be successfully abused there would also have to be at least 1 severe bug in ffmpeg itself. Probably in the http stack but if that passes in the codec itself. _______________________________________________ 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".