The HERO will be when IPFS CLIs/Libraries have the hash verification included. CLI & Library open source devs, please be our heros. We want IPFS and security (both)
IPFS and Their Gateways
41–50 of 63 posts
Re: IPFS and Their Gateways
#42Earlier 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.
I am not a mailman though, who surely have special protection. If you want an analogy, I would rather go the "carry a closed package for an anonymous stranger through airport security" danger way.
The danger is just too big, as my sibling commenter says.
Re: IPFS and Their Gateways
#43Earlier quoted context omitted.
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 ho…
This is such a key point that people forget: this isn’t some academic game theoretical debate but rather a question of how your actions will be perceived by society. If your IP is used to serve illegal content, saying “well actually, …” isn’t a defense and it most likely means you’re getting charged as an accessory to whatever that stranger did. Even if you can avoid legal penalties after years and significant expense, your reputation will be linked.
Re: IPFS and Their Gateways
#44Great to see the proposed fix in ffmpeg. Using a remote gateway should really not be a default but something the user has to consciously and deliberately configure.
Re: IPFS and Their Gateways
#45The HERO will be when IPFS CLIs/Libraries have the hash verification included. CLI & Library open source devs, please be our heros. We want IPFS and security (both)
The _real_ hero will be when locating a random IPFS file doesn't take 10+ minutes.
Re: IPFS and Their Gateways
#46Earlier 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.
You can, though, kinda.
In your mailman example, it would be like the FBI announcing exactly what the envelope looks like, uniquely identifiable, and if you encounter this letter to report it immediately or else your complicit. Or at least, that's the fear.
Yes, if it's encrypted you have no idea, but if anyone ever found out what was in it you can know who ever transmitted it. Unless everyone re-encrypts it repeatedly.. which then makes content address-ability awkward.
Re: IPFS and Their Gateways
#47It 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.
Yea, IPFS has a horrible issue with representing what it .. is.
People, even in this thread, keep spouting privacy.. when i'm not sure if i've ever seen that as a goal.
If anything content addressability makes privacy remarkably difficult.
Re: IPFS and Their Gateways
#48I will never run an IPFS gateway as long as there are no robust legal protections against someone provoking a downloads (and with IPFS, subsequent uploads) of content that's illegal to have on your hard drive (a universal example is CSAM).
And believe it or not - occasionally such content is used as a weapon. A Twitch streamer with an open Dropbox learned the hard way. It's used regularly on _that_ kind of imageboard to derail threads. I know because a naive version of me briefly ran an archive of a supposedly worksafe board about video games a decade ago and had their door knocked down at gunpoint about a year later.
I don't know how the Fediverse still exists, considering that most implementations are very eager to mirror all media they encounter.
I know HTTP can provoke the same caching, but for that there's actually much more robust legal precedent.
Re: IPFS and Their Gateways
#49[deleted]
Re: IPFS and Their Gateways
#50This 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.
As others have said, it's not as straightforward because the CID contains a hash of the data's encoding which is not the same as the data itself (files are chunked into pieces to facilitate incremental verifiability and better caching, the encoding supports directories, etc.).
Here is IPFS's master issue for "verifiable gateway responses", which summarizes the technical challenges and progress: https://github.com/ipfs/in-web-browsers/issues/128.