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

[Nicolas George <george@nsup.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3998 bytes --]

Michael Niedermayer (12022-08-12):
> Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog
> 
> 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
> 
> So what one does is to connect to local of ISP DNS server which caches results
> and does resolve from the root servers if needed (either directly or though platform APIs)
> Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one
> locally normally
> 
> Below is how i understand IPFS, please someone correct me if iam wrong, iam 
> listing this here as i think it makes sense for the dicussion to better understand
> what IPFS is before arguing about it
> 
> 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 connect
> to peers and find out which has the data. 
> 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 before and
> after the process with libavformat. This is the same as with a DNS server.
> 
> 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 node might
> be worse. IIUC thats like a public caching DNS server
> 
> 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 
> can take a subset of the data with some more hashes and verify that the data
> 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 modify
> the data.
> again it can in principle be checked that this is all unmodifed by any intermediate
> that makes IPFS different fron DNS and HTTP(S) which cannot be checked from the
> URL alone

All this looks a lot like “magnet:” 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,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".