IPFS and Their Gateways
daniel.haxx.se
IPFS and Their Gateways
1–10 of 63 posts
Re: IPFS and Their Gateways
#2The same argument basically applies to DoH (DNS over HTTPS).
Re: IPFS and Their Gateways
#3> the gateway is in full control and can inspect and tamper with the data as much as it likes
Inspect, yes, but tamper? IPFS content IDs are hashes, so it seems like it should be possible to verify what you have been sent if you really cared enough to do so.
Re: IPFS and Their Gateways
#4So basically CURL will get support for IPFS by using a proxy service (which is bad for user privacy).
And said proxy could bounce your request around for max 30 hops before a random IPFS-proxy honors the request. This is horrible for user privacy.
Brave browser [1] at least has a native support for IPFS and no need for proxies at all.
> Other IPFS privacy concerns: Brave, the browser, has actual native IPFS support (not using any gateway) and they have an informative page called How does IPFS Impact my Privacy?
Re: IPFS and Their Gateways
#5This is silly. You could say the same for files CURLd from servers over http today. Did you know that when you download files from the internet, you're putting yourself at risk of the server tampering with your file before serving it to you??
Re: IPFS and Their Gateways
#6The same argument basically applies to DoH (DNS over HTTPS).
The argument is that the user must choose their gateway, not that https gateways are bad in general.
With DoH generally must both opt in and must choose your provider.
Re: IPFS and Their Gateways
#7The same argument basically applies to DoH (DNS over HTTPS).
The argument is that the user must choose their gateway, not that https gateways are bad in general. With DoH generally must both opt in and must choose your provider.
I’ve seen a lot of defaults to use Google or Cloudflare as resolvers.
Re: IPFS and Their Gateways
#8So basically CURL will get support for IPFS by using a proxy service (which is bad for user privacy). And said proxy could bounce your request around for max 30 hops before a random IPFS-proxy honors the request. This is horrible for user privacy. Brave browser [1] at least has a native support for IPFS and no need for proxies at all. > Other IPFS privacy concerns: Brave, the browser, has actual native IPFS support (…
This blog post about cURL is saying that they will not do this, and will require a manual configuration of a gateway.
> By default, Brave will load the URI being requested via a public HTTP gateway; however, it will also show an infobar that asks you if you’d like to use a local node to resolve IPFS URIs.
So Brave by-default uses a public gateway.
Re: IPFS and Their Gateways
#9> the gateway is in full control and can inspect and tamper with the data as much as it likes Inspect, yes, but tamper? IPFS content IDs are hashes, so it seems like it should be possible to verify what you have been sent if you really cared enough to do so.
Possible, yes, but probably the most widely used IPFS implementation – the Brave browser – does not implement this yet. They say they plan to in the future.
Re: IPFS and Their Gateways
#10> the gateway is in full control and can inspect and tamper with the data as much as it likes Inspect, yes, but tamper? IPFS content IDs are hashes, so it seems like it should be possible to verify what you have been sent if you really cared enough to do so.
IPFS content IDs are hashes of the DAG of the content. That DAG chucks up the data and includes it directly in itself.
There isn't a tool today that can verify an IPFS address without actually downloading that file's DAG, which is basically downloading the entire file.