Plausible deniability for blocks

The idea here is to be able to seed blocks without knowing what they contain.

there's an unrelated issue that is technically fine already, but i really wish was slightly different
file split into blocks -> uploaded with ID = hash of block
my own preference would be...
file split into blocks -> each block encrypted, symmetric key = hash of unencrypted block -> encrypted block uploaded with ID = hash of encrypted block
a DAG pointing to a bunch of blocks would include both ID and key in this case
but bitswap exchanges blocks using just the ID
that lets you have plausible deniability that you know what the contents of any given block is
but keeps de-duplication and all the other nice features of ipfs
Arceliar: i though we had de-dup. if you add a block that's already there, the hash matche
you do have de-dup
the above just lets you simultaneously have de-dup and 0 knowledge of what the files are
if someone has a block that i want, and i request a bunch of blocks they want and send them (to improve my ratio and get my block sooner), i'd like to have deniability that i knew what those blocks where
s/where/were
gotcha
yeah that makes sense
otherwise i'd be scared to download/forward blocks, for fear of copyright infringement or whatever
that's actually the main reason i'm not running ipfs this very second
we use afs at work. i like ipfs better, on paper, minus the issues outlined above
thank you Arceliar, that's good stuff
once again, you're encouraged to forward that idea to anyone else who might care

[jbenet]

cc @Arceliar

quick note: content encryption is coming, but not yet in. depends on keystore + keychan specs, and implementation on go-ipfs. we're very close. additionally, it is trivial to:

hash=$(cat file1 | encrypt <algo> <key> | ipfs add -q)
ipfs cat $hash | decrypt <algo> <key> >file2

the above just lets you simultaneously have de-dup and 0 knowledge of what the files are

not true. this is not plausible deniability. this is known as convergent encryption and anyone with the source material would be able to find out who has it, is requesting it, or is serving it. Network authorities can simply publish hash blocklists and make node operators subscribe to them. We already plan to run blocklists that nodes can subscribe to (eg for DMCA), for users who use schemes such as these for "bad bits", or who transmit plaintext.

Better ways of achieving the desired effect:

• using network / erasure coding unknown to the transmitters.
• using proper encryption with randomly-generated keys (no-dedup, but safer)
• build a proper ORAM (inpractical for most uses of IPFS)
• use shamir secret sharing to tangle up all the data (inpractical for most uses of IPFS).
• these can be achieved both on top of ipfs and under/in ipfs. we'll move towards under/in, but please know you can already write it on top with IPFS doing much of the heavy lifting.
• also, we do not want all content to be encrypted/erasure coded. think about public data (like github public repos, wikipedia. datasets, etc)

important note: encryption of the content (with randomly generated keys, without sharing/converging on them, and thus without dedup), is still not enough. Information can still be derived from the accesses. (See "the ORAM problem" in crypto). The standard IPFS stack described in the paper is not an ORAM, but can serve as a substrate for one.

otherwise i'd be scared to download/forward blocks, for fear of copyright infringement or whatever
that's actually the main reason i'm not running ipfs this very second

Currently, IPFS does not make any request for data not explicitly requested. Any bitswap strategy that may do so would be optional and opt in. It is a strong goal of the IPFS project that standard IPFS distributions/configurations never download content not explicitly requested. This means it is as safe for use anywhere as {HTTP, FTP, TCP, IP}.

[seidtgeist]

We already plan to run blocklists that nodes can subscribe to (eg for DMCA), for users who use schemes such as these for "bad bits", or who transmit plaintext.

It's really great this is being planned! If I may add something if that wasn't part of the agenda yet: Let's not just think of handling DMCAs, but social abuse prevention. Specifically the technical capability for having effective blocklists for content that is violating a code of conduct (ipfs' CoC) that users of the network or the software might opt into by default. Now, before anyone inevitably loses their shit: Think of how long it has been since you pressed "Accept Terms and Conditions" just because you wanted to use some popular piece of software, or even hardware. I understand that there's no difference between the handling of two different blocklists. But since the issue is not just about blocklists and also very important for the immutable web I thought I'd explicitly bring that up.

It is a strong goal of the IPFS project that standard IPFS distributions/configurations never download content not explicitly requested

👏

[Arceliar]

Apologies if I was incorrect in my interpretation of how ipfs works, I distinctly recall reading somewhere that blocks could be downloaded and forwarded to someone else for the purpose of improving share ratio, but it's entirely possible that I misremembered or that it was just a comment someone left somewhere about possible future extensions of bitswap.

But just to clarify, if I was downloading blocks just to forward them to another person, using convergent encryption on the blocks would in fact give me deniability that I knew what I was forwarding, at least according to my local laws as I understand them. It would not give me deniability that I had received, stored, or forwarded the data; that's a separate issue.

If the blocks are not encrypted, then it is extremely unlikely but still arguable that I could have reasonably looked at the plaintext and determined what it was (especially in the case of small files that fit into 1 block), and then taken whatever action might be legally required.

Whether or not that's useful depends on where the burden of proof lies for cases of copyright infringement (or whatever the person would be charged with for forwarding an unidentified block), which depends on where you live / are being charged.

I only mentioned it because 1: since you already need to get a list of hashes to find the blocks in a file, and you could just as easy get a list of hash:key pairs, it looks like it would be transparent to the average user, and 2: it seems like it's low hanging fruit if there's anyone who would find it useful.

The blacklist sounds like it could be useful.

[the8472]

Specifically the technical capability for having effective blocklists for content that is violating a code of conduct (ipfs' CoC) that users of the network or the software might opt into by default.

Official, default block lists are dangerous, they make the maintainer a target of law enforcement requests and bring lots of political hassle with them over what belongs on such a list and what doesn't.

Block lists should require explicit and separate user opt-in to reduce censorship incentives. Having them maintained by a 3rd party also helps to unburden developers from such politics.

Currently, IPFS does not make any request for data not explicitly requested. Any bitswap strategy that may do so would be optional and opt in. It is a strong goal of the IPFS project that standard IPFS distributions/configurations never download content not explicitly requested.

This is a privacy concern in a different form because it makes it possible to determine what a user has downloaded in the past, assuming an IPFS node can be associated with that user.

Downloading random, non-requested content may actually provide limited plausible deniability that any particular download has been initiated by the user at the cost of risking false accusations. That is a difficult tradeoff to make.

[mitar]

Downloading random, non-requested content may actually provide limited plausible deniability that any particular download has been initiated by the user at the cost of risking false accusations. That is a difficult tradeoff to make.

What about if downloaded random non-requested content would be encrypted on disk in some way and only when you request that data it gets decrypted? I think Freenet has a similar feature. Where you cannot really know which data you are hosting.

Not sure how this would be implemented and where would that key come from. Conceptually, it should not be stored locally until you request it.

Also, not sure if this would help one in legal case at all. But maybe it would. You did not know what you are storing, you could not know what you are storing, you just stored, not modified, not selected which data to store, and did not have means to check what you are storing.