Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPFS and Their Gateways

daniel.haxx.se

Post reply on HN
Print view View original

61–63 of 63 posts

Re: IPFS and Their Gateways

#61

Post by remram »

xd1936 wrote: post #5

This 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??

The server giving you the wrong file is not "tampering". The word refers to something in the middle making changes.

For the web, TLS provides tamper-resistance. Accessing the web through a HTTP proxy would allow tampering, similarly to accessing IPFS through a gateway.

Re: IPFS and Their Gateways

#62

Post by danpalmer »

jstanley wrote: post #27
danpalmer wrote: post #25

Earlier quoted context omitted.

> The verification is fast and cheap. And yet the most widely used IPFS client, Brave, does not implement this. The blog post is technically wrong, but I think it's worth accounting for the general state of the ecosystem in these decisions, and in whether to include IPFS in cURL, and it sounds like the general state of the ecosystem is not up to the standards that cURL should reasonably expect from a protocol asking…

Brave uses its own local gateway running go-ipfs. go-ipfs verifies the content, so Brave does not have to. You only have to verify the content yourself if it is not being verified by someone you trust (i.e. a local gateway that you're running yourself).

That's not what their documentation says. It says that it uses a public gateway, and prompts the user asking if they would like to use a local gateway, at which point it will download go-ipfs and run that. That's a fairly smooth UX to get a local gateway running, but I wouldn't bet money on it being used by the majority. Most people take the path of least resistance, and it's up to projects like Brave or cURL to ensure that the path is safe, which in this case it is not for Brave.

Re: IPFS and Their Gateways

#63

Post by ajconway »

londons_explore wrote: post #16

IPFS isn't fit for purpose. It needs censorship-resistance added. It needs user privacy added. Both of those could be enabled by combining data blocks semi-randomly. Ie. rather than downloading the data you're looking for, you download a block of data containing what you're looking for and some other data. Then nobody knows what it was you were looking at. Some combined blocks might contain a few bytes of data from t…

> Both of those could be enabled by combining data blocks semi-randomly. Ie. rather than downloading the data you're looking for, you download a block of data containing what you're looking for and some other data

What you're looking for is Oblivious Transfer or Mix Nets. Unfortunately, no practical solutions currently exist (except for Onion Routing).

> Remember that data can be encrypted by content hash, so there is no way to know what you're storing unless you go scouring the public internet for a key to decrypt it.

Censorship does not work this way. First, content that requires censorship resistance is usually public, otherwise one can employ a number of p2p or centralized solutions to share content directly.

Public content is easy to find, so step one: you find and identify the list of nodes that serve the content. Step two: you block the nodes on a level that's available to you (depends on the country). Step three: your users are unable to use the network effectively, because half of the nodes don't work, and revert to using Facebook.

Post reply on HN