[FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

[Mark Gaiser]

On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
derek.buitenhuis at 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.