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

31–40 of 63 posts

Re: IPFS and Their Gateways

#31

Post by trumpablehump »

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…

> you download a block of data containing what you're looking for and some other data

That IPFS does NOT put data I did not explicitly requested on my storage is exactly why I feel comfortable using it compared to some other distributed storage systems where I might end up with horrific data on my system.

Re: IPFS and Their Gateways

#32

Post by k__ »

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…

Isn't Filecoin Protocol Labs' solution to the cencorship problem?

Re: IPFS and Their Gateways

#33

Post by kordlessagain »

pastel-mature-herring~> What are the issues listed in these comments about IPFS?

victorious-capuchin|> The main issues seem to be that IPFS is not yet up to the standards that cURL should reasonably expect from a protocol asking for inclusion. In particular, there are concerns about the lack of censorship resistance and user privacy.

Re: IPFS and Their Gateways

#34

Post by londons_explore »

trumpablehump wrote: post #31
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…

> you download a block of data containing what you're looking for and some other data That IPFS does NOT put data I did not explicitly requested on my storage is exactly why I feel comfortable using it compared to some other distributed storage systems where I might end up with horrific data on my system.

Except you'd only have the keys for your data...

And encrypted data you don't have the key for is indistinguishable from random noise. 'Combined' blocks that you don't know which partner blocks are necessary for decoding are likewise useless.

You're being like a mailman handling mail - you can't look into the mail, so you can't know if you're delivering love letters, junkmail, or terrorist propaganda.

Re: IPFS and Their Gateways

#35

Post by zaik »

ilaksh wrote: post #20

It almost sounds like part of his concern is that the web server could view the content you are requesting. But this is always true for IPFS data since it's public and available to anyone with the CID. Also you can use the CID (which is a hash), to verify the content hasn't been tampered with.

If I understand correctly, IPFS will even re-advertise blocks you have downloaded on the DHT. So per default your whole browsing history is public on the IPFS network.

Re: IPFS and Their Gateways

#36

Post by drexlspivey »

Nemo157 wrote: post #26
waynenilsen wrote: post #24

This article made a false statement > the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening. Regarding data tampering; IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs:// /some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have…

You do not need to send the additional data out of band unless you are claiming that sha-2 (the hash function used in ipfs) is vulnerable to second preimage attacks.

Re: IPFS and Their Gateways

#37

Post by IggleSniggle »

sneak wrote: post #17
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??

http urls are not content-addressed. ipfs urls are. a better analogy than http urls would be git commit hashes.

Then like with git, couldn't you cryptographically sign ipfs urls to have a public-trust guarantee of provenance? Either GPG signed or perhaps a CA?

Re: IPFS and Their Gateways

#38

Post by sliken »

londons_explore wrote: post #34
trumpablehump wrote: post #31

Earlier quoted context omitted.

> you download a block of data containing what you're looking for and some other data That IPFS does NOT put data I did not explicitly requested on my storage is exactly why I feel comfortable using it compared to some other distributed storage systems where I might end up with horrific data on my system.

Except you'd only have the keys for your data... And encrypted data you don't have the key for is indistinguishable from random noise. 'Combined' blocks that you don't know which partner blocks are necessary for decoding are likewise useless. You're being like a mailman handling mail - you can't look into the mail, so you can't know if you're delivering love letters, junkmail, or terrorist propaganda.

While true, if the government downloads objectionable/illegal data and they detect that 10% of that data is coming from your IP address you'll likely have a very bad day. Sure weeks or months later you might convince a judge and/or jury that you had no access or control to that data, and you might even get your laptops, desktops, and external storage back.

ISPs and USPS have common carrier protection, by default a home user does not.

Re: IPFS and Their Gateways

#39

Post by andrius4669 »

waynenilsen wrote: post #24

This article made a false statement > the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening. Regarding data tampering; IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

Verification would require more data than CID itself provides (ipld document layout, chunking algorithm, max chunk sizes...).

See https://github.com/multiformats/cid/issues/22

Re: IPFS and Their Gateways

#40

Post by jmillikin »

drexlspivey wrote: post #36
Nemo157 wrote: post #26

Earlier quoted context omitted.

The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs:// /some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have…

You do not need to send the additional data out of band unless you are claiming that sha-2 (the hash function used in ipfs) is vulnerable to second preimage attacks.

It's not possible to verify a file downloaded from IPFS using only its CID, because an IPFS CID does not contain a checksum of the file content. It contains the checksum of a meta-file, which contains the hashes of further meta-files.

For example, debian-10.7.0-amd64-netinst.iso has SHA256 checksum b317d87b0a3d5b568f48a92dcabfc4bc51fe58d9f67ca13b013f1b8329d1306d. Here are two example CIDs generated from that file:

https://cid.ipfs.tech/#bafybeihjy54iyvheotna2aeqmzhqnro6yot4...

https://cid.ipfs.tech/#bafybeihfqpypuhmtyzazrj3g4b4f4nqk2ziy...

Notice that neither one contains the original checksum.

Post reply on HN