Private content over IPFS

koalalorenzo · August 18, 2017, 7:53am

Hello guys!
I am attending an hackathon, where we showcased our solution to some problems exposed.
OFC the main point of the public was: how do we secure the data, so that we have control to who can read it when we publish it?

The idea/answer that I was providing to the questions was related to private IPFS networks, combined with a PKI to encrypt the content, but this is not enough for corporates.

What are the current mechanisms used by you guys?
I am not just focusing just about basic privacy, but more a broad discussion

OffTopic: we used IPLD to publish some cool structured data

es_00788224 · August 19, 2017, 10:27pm

You can run a private IPFS network, look at ipfs-cluster.

stebalien · August 19, 2017, 10:46pm

At the moment, encryption + private networks. We’d really like an access control system but that will take quite a bit of design work.

koalalorenzo · August 20, 2017, 6:07am

yes, that is what I have provided

koalalorenzo · August 20, 2017, 6:08am

Do you know what is the plan for this feature? or an OTA?
Is one of the feature planned to be implemented with the Filecoin money?

HaakonME · August 20, 2017, 5:40pm

The Zot protocol of Red/Hubzilla might be interesting to you to allow access control in a decentralized manner.

stebalien · August 21, 2017, 10:42pm

Do you know what is the plan for this feature? or an OTA?

Nobody’s currently working on this feature at the moment.

Is one of the feature planned to be implemented with the Filecoin money?

The current proposal as described by the whitepaper relies entirely on encryption. I can’t give any promises on what may or may not exist in the initial release of Filecoin but we’d like to have a fully-functional smart-contract system and could conceivably implement some form of flexible authentication system using it. Even better than a simple authentication system, smart contracts can be used to flexibly rate-limit data access to make exfiltration hard.

Such a system is a bit at odds with the self-healing aspect of Filecoin but it that’s not a deal-breaker. As described in the whitepaper, arbitrary miners can, at least temporarily, take over abandoned contracts without interacting with owner of the contract to ensure that data isn’t lost. However, contracts could specify the precisely how and when this can happen (e.g., which miners are acceptable backups) so this isn’t a big issue, just a bit of a wrinkle.

daviddias · November 7, 2019, 1:14pm

https://github.com/ipfs/research/blob/master/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md packs some more information, historical context, description of previous attempts and where we still want to get at

Mikaela · February 5, 2020, 2:26pm

I seem to be reading a lot of threads late and that file has moved to

github.com

ipfs/notes/blob/master/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md

# Preserve user privacy when providing and fetching content

## Short Description
> In one sentence or paragraph.

How to ensure that users of the IPFS network can retrieve and provide (whether as original publisher or as a cache provider) information while maintaining full anonymity. In other words, we need to find and/or build tools, techniques and protocols that <strong>decouple actions from the entities that perform them</strong>.

## Description

The Web 2.0 implements a default centralized infrastructure design that fails to protect users' privacy. Some of the common patterns that we see making users vulnerable are: when data is not encrypted, both at rest and in transit, users' interactions with services leaks their intent, which creates the opportunity for a pattern analysis attack. In a content-addressable network, unencrypted *content names* also allow for identification of what users are requesting and matching of requests to users.

In the Web 3.0, the dWeb, users get the ability to share data with other peers without using an intermediary. However, a complete solution is still missing that can prevent users leaking what data they are serving and fetching through side channels/pattern analysis (e.g. when searches are made, either through a search engine or simply by searching for the blocks in a Distributed Hash Table).

Some solutions exist to mitigate this problem (see the State of the Art section below). However, none is yet complete as in "it is always 100% private, period", requiring users to adapt and adopt certain strategies to anonymize the content, depending on the type of interaction they have with other users. This Open Problem is beyond a data encryption or wire encryption problem; a complete solution will have to provide a way to grant and revoke other users' access to content (Authorization), provide users with the ability to know when a piece of content they have published is being accessed (Accounting), and guarantee that the users with whom the content is being shared are who they claim to be (Authentication), while not letting a third party understand what is being shared, how and with whom.

This happens to be one of the toughest problems to solve in order to provide a complete and human rights preserving fabric for knowledge.

### Background

One of the strongest advantages of a content-addressable, or content-centric network is the fact that (if natively deployed as a network-layer architecture) it can successfully hide the identity of requesting nodes. In contrast to the standard situation where every request is carrying the requestor's IP address, a native network-layer request for explicitly named content only carries with it the name of the content and *not* where the request is coming from (i.e., source IP address). In such an environment, only immediate neighbour observers can (potentially) identify which node a request is originating from, since after the first-hop requests get "blended" together making it impossible to identify the source of the request. This is in stark contrast to the IP approach, where the source address of any request or data packet is carried permanently in the packet itself on its way to the source of the content.

This file has been truncated. show original

Topic		Replies	Views
Encryption, private data, and private swarms with IPFS encryption , private-swarm	15	1556	June 4, 2023
Private overlay networks Ecosystem use-cases-and-apps	3	1351	March 7, 2018
Access control Old FAQ	4	2563	August 6, 2018
Interested in putting your IPFS use case onto Filecoin? Ecosystem	0	346	September 4, 2020
IPFS and Digital Asset protection Ecosystem use-cases-and-apps	5	643	February 3, 2022

Private content over IPFS

Related topics