From 0ae6c03e84d72a1923353b90ce1eaedb7a6b0a3f Mon Sep 17 00:00:00 2001 From: David Dias Date: Tue, 10 Sep 2019 09:50:17 +0300 Subject: [PATCH 01/29] Create PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 71 ++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md new file mode 100644 index 0000000..5fa5490 --- /dev/null +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -0,0 +1,71 @@ +# Preseve full users' privacy when providing and fetching Content + +## Description + +The Web 2.0 and its centralized infrastructure missed to deliver full users' privacy when these are accessing and delivering content to other users in the Network. This can happen in one of two ways, either by simply transfering/storing the data uncrypted or by pattern analysis of access which can reveal users interest and intent. + +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 sidechannels/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, non is yet complete as in "it is always 100% private, period", requiring users to adapt and adopt certain strategies to annonymize 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 give access to others to access data and later revoke (Authorization), provide a users with the ability to know when a piece of data they have share is being accessed (Accounting) and offer a guarantee that the data is being shared with exactly the right user and no one else (Authentication), this 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. + +## State of the Art + +This survey on the State of the Art is not by any means complete, however, it should provide a good entry point to learn what are the existing work. If you have something that is fundamentally missing, please consider submitting a PR to augment this survey. + +### Within the IPFS Ecosystem +> Existing attempts and strategies + +##### Wire Encryption + +Thanks to libp2p, IPFS ensures that the communication between any two IPFS nodes is always encrypted. This is achieved through one of the many Crypto Channels that libp2p supports such as: SECIO, TLS 1.3, DTLS (in WebRTC) and NOISE. + +##### Data Encryption + +Data Encryption means that we encrypt data at rest and only decrypted to consume it. This means that only the owner of the decryption key can access it. Some solutions with this technique are: + +- [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symetrical key that is shared to the receiver through a sidechannel +- [peer-base cryptographic ACLs](https://github.com/peer-base/peer-base) - These are used by [PeerPad](https://peerpad.net). The way they work is that for each user, a Pub/Priv key pair is generated and every time a user wants to make a modification, signs that modification and then encrypts it with a symmetric room key, so that only owners of the symmetric key can change and only changes from valid peers are accepted. + +##### Private/Disjoint Networks + +Creating a separate IPFS Network will ensure that only the nodes can access the content within that network. [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). + +### Within the broad Research Ecosystem +> How do people try to solve this problem? + +- [TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. +- [DoubleRatchet](https://signal.org/docs/specifications/doubleratchet/) / [Matrix.org Olm/MegaOLM](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md#olm-a-cryptographic-ratchet) +- [Using Sphinx to Improve Onion RoutingCircuit Construction](https://www.cypherpunks.ca/~iang/pubs/SphinxOR.pdf) +- [Scuttlebutt Secret Handshare](https://dominictarr.github.io/secret-handshake-paper/shs.pdf) +- [Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) +- [Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) +- [Define privacy threat model for DHTs (and other overlay P2P networks)](https://github.com/gpestana/notes/issues/3) +- [Talek: a Private Publish-Subscribe Protocol](https://raymondcheng.net/download/papers/talek-tr.pdf) +- [SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) +- [Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) +- [Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) + +### Known shortcommins of existing solutions +> What are the limitations on those solutions? + +Some of the known shortcommings of existing solutions are: + +- They don't offer protection to network analysis (it is possible to infer what the user is doing by analysis the network traffic) +- Solutions that are more resistant (not fully resistent) typically trade off bandwidth + memory for creating that protection (e.g. creating noise in the network to make it hard to distinguish valid from dummy traffic) +- Lack of data encryption at rest +- Lack of complete authorization + revocation + +## Solving this Open Problem + +### What is the impact + +### What defines a complete solution? +> What hard constraints should it obey? Are there additional soft constraints that a solution would ideally obey? + +## Other + +### Existing Conversations/Threads + +### Extra notes From da6fa29cdf407176399c5d1f41d2ac51370fc9b9 Mon Sep 17 00:00:00 2001 From: David Dias Date: Tue, 10 Sep 2019 10:45:06 +0300 Subject: [PATCH 02/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 5fa5490..7687f8b 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -12,7 +12,7 @@ This happens to be one of the toughest problems to solve in order to provide a c ## State of the Art -This survey on the State of the Art is not by any means complete, however, it should provide a good entry point to learn what are the existing work. If you have something that is fundamentally missing, please consider submitting a PR to augment this survey. +> This survey on the State of the Art is not by any means complete, however, it should provide a good entry point to learn what are the existing work. If you have something that is fundamentally missing, please consider submitting a PR to augment this survey. ### Within the IPFS Ecosystem > Existing attempts and strategies From 6a5c7df94855f721986b32a69f022bd23e6e8709 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 11 Sep 2019 09:50:18 +0300 Subject: [PATCH 03/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 7687f8b..e0b5199 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -26,11 +26,16 @@ Thanks to libp2p, IPFS ensures that the communication between any two IPFS nodes Data Encryption means that we encrypt data at rest and only decrypted to consume it. This means that only the owner of the decryption key can access it. Some solutions with this technique are: - [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symetrical key that is shared to the receiver through a sidechannel + +##### Capability Systems / Cryptographic ACLs + - [peer-base cryptographic ACLs](https://github.com/peer-base/peer-base) - These are used by [PeerPad](https://peerpad.net). The way they work is that for each user, a Pub/Priv key pair is generated and every time a user wants to make a modification, signs that modification and then encrypts it with a symmetric room key, so that only owners of the symmetric key can change and only changes from valid peers are accepted. ##### Private/Disjoint Networks -Creating a separate IPFS Network will ensure that only the nodes can access the content within that network. [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). +Creating a separate IPFS Network will ensure that only the nodes can access the content within that network. + +- [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). ### Within the broad Research Ecosystem > How do people try to solve this problem? @@ -61,6 +66,10 @@ Some of the known shortcommings of existing solutions are: ### What is the impact +Finding a complete solution to this Open Problem will grant the ability for any human in the planet to privately share information, read content without leaking their intent to anyone else other than the provider of that content, or even possibly, not even to the provider. + +It will lead to a generation of safer applications, both consumer level and business critical, that require full control of one's data (e.g. Health Data). + ### What defines a complete solution? > What hard constraints should it obey? Are there additional soft constraints that a solution would ideally obey? @@ -68,4 +77,11 @@ Some of the known shortcommings of existing solutions are: ### Existing Conversations/Threads +- [Censorship resistance on IPFS](https://github.com/ipfs/notes/issues/281) +- [Content Encryption](https://github.com/ipfs/notes/issues/270) +- [Shared Secret constructions for Private Networks](https://github.com/ipfs/notes/issues/177) +- [Search over encrypted data](https://github.com/ipfs/notes/issues/128) +- [Plausible deniability for blocks](https://github.com/ipfs/notes/issues/21) +- [Alternative BitSwap strategies](https://github.com/ipfs/notes/issues/20) + ### Extra notes From 11900e3439bff78c5630eb9330e93117453c68e3 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 11 Sep 2019 10:09:34 +0300 Subject: [PATCH 04/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index e0b5199..c9074b7 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -37,6 +37,12 @@ Creating a separate IPFS Network will ensure that only the nodes can access the - [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). +##### Onion Routing + +Onion routing is a technique for anonymous communication over a computer network. In an onion network, messages are encapsulated in layers of encryption, analogous to layers of an onion. The encrypted data is transmitted through a series of network nodes called onion routers, each of which "peels" away a single layer, uncovering the data's next destination. + +- [libp2p-onion](https://github.com/OpenBazaar/go-onion-transport) + ### Within the broad Research Ecosystem > How do people try to solve this problem? @@ -51,6 +57,7 @@ Creating a separate IPFS Network will ensure that only the nodes can access the - [SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) - [Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) - [Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) +- [HOPR - privacy-preserving messaging protocol ](https://github.com/validitylabs/hopr) ### Known shortcommins of existing solutions > What are the limitations on those solutions? @@ -63,6 +70,17 @@ Some of the known shortcommings of existing solutions are: - Lack of complete authorization + revocation ## Solving this Open Problem +> What are the hard constraints for a complete solution. + +Valid solutions should improve the current state of the art or offer definitive solutions for: + +- [ ] Two users can transfer a piece of information that no other user knows or can guess: what it is, why it is being transfer, between whom and when. +- [ ] No single central authorities are required to mediate the communication +- [ ] A provider has a way to grant and revoke access to information. + +As additional constraints + +- [ ] Mechanism to prevent data exfiltration (e.g. when a user goes rogue) ### What is the impact @@ -83,5 +101,10 @@ It will lead to a generation of safer applications, both consumer level and busi - [Search over encrypted data](https://github.com/ipfs/notes/issues/128) - [Plausible deniability for blocks](https://github.com/ipfs/notes/issues/21) - [Alternative BitSwap strategies](https://github.com/ipfs/notes/issues/20) +- [Anonymous IPFS](https://github.com/ipfs/go-ipfs/issues/6430) +- [Privacy preserving DHTs](https://github.com/gpestana/notes/issues/8) +- [DHT improvement ideas](https://github.com/libp2p/research-dht/issues/6) +- [Tor onion integration](https://github.com/ipfs/notes/issues/37) +- [Identity RFC](https://github.com/ipfs-shipyard/peer-star/pull/15) ### Extra notes From 1742eb1a7ca98352898657eb333d03835d38fee8 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 11 Sep 2019 11:55:54 +0300 Subject: [PATCH 05/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index c9074b7..35fa396 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -70,7 +70,15 @@ Some of the known shortcommings of existing solutions are: - Lack of complete authorization + revocation ## Solving this Open Problem -> What are the hard constraints for a complete solution. + +### What is the impact + +Finding a complete solution to this Open Problem will grant the ability for any human in the planet to privately share information, read content without leaking their intent to anyone else other than the provider of that content, or even possibly, not even to the provider. + +It will lead to a generation of safer applications, both consumer level and business critical, that require full control of one's data (e.g. Health Data). + +### What defines a complete solution? +> What hard constraints should it obey? Are there additional soft constraints that a solution would ideally obey? Valid solutions should improve the current state of the art or offer definitive solutions for: @@ -82,15 +90,6 @@ As additional constraints - [ ] Mechanism to prevent data exfiltration (e.g. when a user goes rogue) -### What is the impact - -Finding a complete solution to this Open Problem will grant the ability for any human in the planet to privately share information, read content without leaking their intent to anyone else other than the provider of that content, or even possibly, not even to the provider. - -It will lead to a generation of safer applications, both consumer level and business critical, that require full control of one's data (e.g. Health Data). - -### What defines a complete solution? -> What hard constraints should it obey? Are there additional soft constraints that a solution would ideally obey? - ## Other ### Existing Conversations/Threads From f556ca0c8d9291795bfe8b010fb83671652b044e Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:11:56 +0300 Subject: [PATCH 06/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 35fa396..431123a 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -6,7 +6,7 @@ The Web 2.0 and its centralized infrastructure missed to deliver full users' pri 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 sidechannels/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, non is yet complete as in "it is always 100% private, period", requiring users to adapt and adopt certain strategies to annonymize 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 give access to others to access data and later revoke (Authorization), provide a users with the ability to know when a piece of data they have share is being accessed (Accounting) and offer a guarantee that the data is being shared with exactly the right user and no one else (Authentication), this while not letting a third party understand what is being shared, how and with whom. +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 give access to others to access data and later revoke (Authorization), provide users with the ability to know when a piece of data they have shared is being accessed (Accounting) and offer a guarantee that the data is being shared with exactly the right user and no one else (Authentication), this 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. From 3772447a58b15c00ff766a18e36edf88b4ced941 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:12:37 +0300 Subject: [PATCH 07/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 431123a..0c10fd9 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -25,7 +25,7 @@ Thanks to libp2p, IPFS ensures that the communication between any two IPFS nodes Data Encryption means that we encrypt data at rest and only decrypted to consume it. This means that only the owner of the decryption key can access it. Some solutions with this technique are: -- [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symetrical key that is shared to the receiver through a sidechannel +- [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symmetric key that is shared to the receiver through a sidechannel ##### Capability Systems / Cryptographic ACLs From c05467bb32433181f6a54a8dbeea93d7d8fa433d Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:12:44 +0300 Subject: [PATCH 08/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 0c10fd9..e9175cf 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -33,7 +33,7 @@ Data Encryption means that we encrypt data at rest and only decrypted to consume ##### Private/Disjoint Networks -Creating a separate IPFS Network will ensure that only the nodes can access the content within that network. +Creating a separate IPFS Network will ensure that only member nodes can access the content within that network. - [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). From f6f69c44467953c9a5b474b5acc5bdab74d91dee Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:12:49 +0300 Subject: [PATCH 09/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index e9175cf..b8a30cf 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -29,7 +29,7 @@ Data Encryption means that we encrypt data at rest and only decrypted to consume ##### Capability Systems / Cryptographic ACLs -- [peer-base cryptographic ACLs](https://github.com/peer-base/peer-base) - These are used by [PeerPad](https://peerpad.net). The way they work is that for each user, a Pub/Priv key pair is generated and every time a user wants to make a modification, signs that modification and then encrypts it with a symmetric room key, so that only owners of the symmetric key can change and only changes from valid peers are accepted. +- [peer-base cryptographic ACLs](https://github.com/peer-base/peer-base) - These are used by [PeerPad](https://peerpad.net). For each user, a Public/Private key pair is generated. Every time a user wants to make a modification, the user signs that modification and encrypts it with a symmetric room key so that only owners of the symmetric key can change and only changes from valid peers are accepted. ##### Private/Disjoint Networks From e33b9c775882bd8273725cf36966644218ed03e3 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:13:01 +0300 Subject: [PATCH 10/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index b8a30cf..aff7cab 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -64,7 +64,7 @@ Onion routing is a technique for anonymous communication over a computer network Some of the known shortcommings of existing solutions are: -- They don't offer protection to network analysis (it is possible to infer what the user is doing by analysis the network traffic) +- They don't offer protection against network analysis (it is possible to infer what the user is doing by analysing network traffic) - Solutions that are more resistant (not fully resistent) typically trade off bandwidth + memory for creating that protection (e.g. creating noise in the network to make it hard to distinguish valid from dummy traffic) - Lack of data encryption at rest - Lack of complete authorization + revocation From 3fbe5617128a15e470f494683671280019ac755c Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:13:09 +0300 Subject: [PATCH 11/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index aff7cab..ee73399 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -82,7 +82,7 @@ It will lead to a generation of safer applications, both consumer level and busi Valid solutions should improve the current state of the art or offer definitive solutions for: -- [ ] Two users can transfer a piece of information that no other user knows or can guess: what it is, why it is being transfer, between whom and when. +- [ ] Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom. - [ ] No single central authorities are required to mediate the communication - [ ] A provider has a way to grant and revoke access to information. From dbc6882efe49ef6135a808d3bc0d04b550de22c7 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 08:13:16 +0300 Subject: [PATCH 12/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index ee73399..0193cd9 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -73,7 +73,7 @@ Some of the known shortcommings of existing solutions are: ### What is the impact -Finding a complete solution to this Open Problem will grant the ability for any human in the planet to privately share information, read content without leaking their intent to anyone else other than the provider of that content, or even possibly, not even to the provider. +Finding a complete solution to this Open Problem will grant any human in the planet the ability to privately access or share information without leaking their intent to non-local observers other than the provider of that content. Solutions may also be able to hide said intent from the content provider. It will lead to a generation of safer applications, both consumer level and business critical, that require full control of one's data (e.g. Health Data). From ac31e22f17ee3c3650a2bb0806472c1746c87d7b Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 12:12:18 +0300 Subject: [PATCH 13/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 0193cd9..d9c621a 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -23,7 +23,7 @@ Thanks to libp2p, IPFS ensures that the communication between any two IPFS nodes ##### Data Encryption -Data Encryption means that we encrypt data at rest and only decrypted to consume it. This means that only the owner of the decryption key can access it. Some solutions with this technique are: +Data Encryption means that we encrypt data at rest and only decrypt it to consume it. This means that only the owner of the decryption key can access it. Some solutions using this technique are: - [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symmetric key that is shared to the receiver through a sidechannel From a9eab40c439956abecc7a9b7c7092a6ab9078136 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 12:12:55 +0300 Subject: [PATCH 14/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index d9c621a..9de0087 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -2,7 +2,7 @@ ## Description -The Web 2.0 and its centralized infrastructure missed to deliver full users' privacy when these are accessing and delivering content to other users in the Network. This can happen in one of two ways, either by simply transfering/storing the data uncrypted or by pattern analysis of access which can reveal users interest and intent. +The Web 2.0 and its centralized infrastructure fail to protect users' privacy when they exchange data with other users. This can happen in one of two ways, either by simply transferring/storing the data unencrypted or by pattern analysis of access which can reveal interest and intent. 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 sidechannels/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). From df2e8f30d018e6f13b1689dad024649ac63d19d1 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 12 Sep 2019 12:16:54 +0300 Subject: [PATCH 15/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 9de0087..2b24a74 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -2,7 +2,7 @@ ## Description -The Web 2.0 and its centralized infrastructure fail to protect users' privacy when they exchange data with other users. This can happen in one of two ways, either by simply transferring/storing the data unencrypted or by pattern analysis of access which can reveal interest and intent. +The Web 2.0 and uses by default a 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 while transfering; users interactions with services leaks their intent, which creates the opportunity for a pattern analysis attack. 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 sidechannels/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). @@ -23,7 +23,7 @@ Thanks to libp2p, IPFS ensures that the communication between any two IPFS nodes ##### Data Encryption -Data Encryption means that we encrypt data at rest and only decrypt it to consume it. This means that only the owner of the decryption key can access it. Some solutions using this technique are: +By encrypting the data at rest and only decrypting it when it needs to be used, we can ensure that only someone with access to the decryption key can indeed access that data. Some solutions using this technique are: - [ipfs-senc](https://github.com/jbenet/ipfs-senc) - Encrypts the data with a symmetric key that is shared to the receiver through a sidechannel From e8bf0e5467764f7027e9ee83436968b06ad5ea68 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:31:38 +0300 Subject: [PATCH 16/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 2b24a74..d003873 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -1,5 +1,10 @@ # Preseve full users' privacy when providing and fetching Content +## Short Description +> In one sentence or paragraph. + +How to ensure that the user's of the IPFS network can collect and provide information while mainting their full anonymity. + ## Description The Web 2.0 and uses by default a 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 while transfering; users interactions with services leaks their intent, which creates the opportunity for a pattern analysis attack. From 38b8f894c870c3c56aaf7371a106f42487f5405f Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:31:52 +0300 Subject: [PATCH 17/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index d003873..e539431 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -7,7 +7,7 @@ How to ensure that the user's of the IPFS network can collect and provide inform ## Description -The Web 2.0 and uses by default a 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 while transfering; users interactions with services leaks their intent, which creates the opportunity for a pattern analysis attack. +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 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 sidechannels/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). From 5bef461ff4f37d3c10c9e7363e7edbd44dbe6913 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:32:00 +0300 Subject: [PATCH 18/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index e539431..f503ecf 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -9,7 +9,7 @@ How to ensure that the user's of the IPFS network can collect and provide inform 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 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 sidechannels/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). +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 give access to others to access data and later revoke (Authorization), provide users with the ability to know when a piece of data they have shared is being accessed (Accounting) and offer a guarantee that the data is being shared with exactly the right user and no one else (Authentication), this while not letting a third party understand what is being shared, how and with whom. From 35f2ed7d50700d76b2e1cafc7eea7c9b4080d03f Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:32:18 +0300 Subject: [PATCH 19/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index f503ecf..bb728e4 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -11,7 +11,7 @@ The Web 2.0 implements a default centralized infrastructure design that fails to 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 give access to others to access data and later revoke (Authorization), provide users with the ability to know when a piece of data they have shared is being accessed (Accounting) and offer a guarantee that the data is being shared with exactly the right user and no one else (Authentication), this while not letting a third party understand what is being shared, how and with whom. +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 shared 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. From b9d960d399890a1759b594880a58eaaa6d018984 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:32:52 +0300 Subject: [PATCH 20/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index bb728e4..815450c 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -88,7 +88,7 @@ It will lead to a generation of safer applications, both consumer level and busi Valid solutions should improve the current state of the art or offer definitive solutions for: - [ ] Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom. -- [ ] No single central authorities are required to mediate the communication +- [ ] No single central authority are required to mediate the communication - [ ] A provider has a way to grant and revoke access to information. As additional constraints From 490f404a8b2684e8155abdbf476d69949c555ba4 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 14:52:10 +0300 Subject: [PATCH 21/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 30 +++++++++++++++----------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 815450c..e76049c 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -51,18 +51,24 @@ Onion routing is a technique for anonymous communication over a computer network ### Within the broad Research Ecosystem > How do people try to solve this problem? -- [TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. -- [DoubleRatchet](https://signal.org/docs/specifications/doubleratchet/) / [Matrix.org Olm/MegaOLM](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md#olm-a-cryptographic-ratchet) -- [Using Sphinx to Improve Onion RoutingCircuit Construction](https://www.cypherpunks.ca/~iang/pubs/SphinxOR.pdf) -- [Scuttlebutt Secret Handshare](https://dominictarr.github.io/secret-handshake-paper/shs.pdf) -- [Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) -- [Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) -- [Define privacy threat model for DHTs (and other overlay P2P networks)](https://github.com/gpestana/notes/issues/3) -- [Talek: a Private Publish-Subscribe Protocol](https://raymondcheng.net/download/papers/talek-tr.pdf) -- [SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) -- [Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) -- [Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) -- [HOPR - privacy-preserving messaging protocol ](https://github.com/validitylabs/hopr) +- Authorization, Authentication, Accounting + - [TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. +- Data Encryption + - [DoubleRatchet](https://signal.org/docs/specifications/doubleratchet/) / [Matrix.org Olm/MegaOLM](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md#olm-a-cryptographic-ratchet) +- M2M Private Communication + - [Scuttlebutt Secret Handshare](https://dominictarr.github.io/secret-handshake-paper/shs.pdf) + - [HOPR - privacy-preserving messaging protocol ](https://github.com/validitylabs/hopr) + - [SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) + - [Talek: a Private Publish-Subscribe Protocol](https://raymondcheng.net/download/papers/talek-tr.pdf) + - [Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) +- Content Routing + - [Define privacy threat model for DHTs (and other overlay P2P networks)](https://github.com/gpestana/notes/issues/3) + - [Using Sphinx to Improve Onion Routing Circuit Construction](https://www.cypherpunks.ca/~iang/pubs/SphinxOR.pdf) + - [Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) +- Traffic Analysis resistant + - [Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) +- Other + - [Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) ### Known shortcommins of existing solutions > What are the limitations on those solutions? From 79ac089d24337cc95732de13f42d7be2be693204 Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 15:04:58 +0300 Subject: [PATCH 22/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index e76049c..1cf229c 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -41,6 +41,7 @@ By encrypting the data at rest and only decrypting it when it needs to be used, Creating a separate IPFS Network will ensure that only member nodes can access the content within that network. - [libp2p-pnet](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) takes that one step forward and creates a protection using a pre-shared key. This means that only the owners of that key can join this network (to prevent from mistakenly joining two networks and making all data accessible). + - See a demo of it at https://youtu.be/fObld4alGag?t=47 ##### Onion Routing From 6cf3036ffb39740305852068ec24d7ce3402732b Mon Sep 17 00:00:00 2001 From: David Dias Date: Wed, 18 Sep 2019 16:30:56 +0300 Subject: [PATCH 23/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 1cf229c..98e8198 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -3,7 +3,7 @@ ## Short Description > In one sentence or paragraph. -How to ensure that the user's of the IPFS network can collect and provide information while mainting their full anonymity. +How to ensure that users of the IPFS network can retrieve and provide information while maintaining full anonymity. ## Description From 7137622e8c0562d6174860aa9c3fbff36674400d Mon Sep 17 00:00:00 2001 From: Yiannis Psaras <52073247+yiannisbot@users.noreply.github.com> Date: Thu, 26 Sep 2019 17:27:51 +0800 Subject: [PATCH 24/29] Preserve users privacy (#10) * Initial input * Background Update * Related works update. * Update PRESERVE_USER_PRIVACY.md * Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 50 +++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 98e8198..b67485a 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -3,21 +3,33 @@ ## Short Description > In one sentence or paragraph. -How to ensure that users of the IPFS network can retrieve and provide information while maintaining full anonymity. +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 decouple actions from the entities that perform them. ## 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. +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 shared 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. +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. + +Assuming that Data Authenticity can be supported by default through hash-based names and always-signed content, we identify the following categories that need immediate attention in this area: + +- Node privacy: IPFS is working on content hashes, but libp2p is using the IP address of requesting and serving nodes. This has implications to anonymity of both requesting and serving nodes. We should find a way to hide or obfuscate the source IP address, as together with the content hash (at the IPFS layer), they are revealing what content each requesing node is consuming. +- Name privacy: Content addressing comes with the invaluable advantage of enabling the network to know what content it is actually transmitting. This is in contrast to current IP address-based communication, where the network is forwarding packets based on IP addresses and only Deep-Packet Inspection (DPI) techniques can reveal what are the contents inside the packet. Although this feature of content addressable networks brings huge advantages in terms of performance and security as mentioned elsewhere, it comes with some privacy concerns. In particular, *the content that the network is transferring is now "in the clear" and anyone can see what is being transmited, even if the content itself is encrypted.* Ephemeral signatures and even ephemeral names have been proposed in the past to deal with the issue, but there is no widely adopted solution to date. +- Cache privacy: Similarly to being able to see what the network is transferring through content names, seeing the contents of a cache is another feature that is becoming possible with explicitly named content. This can be tremendously beneficial in terms of performance (i.e., find content closer and faster), but it can also reveal what content a node has consumed in the recent past. This is especially so in the case of IPFS where node caches hold content that the user has either explicitly agreed to store, or content that it has recently consumed and has not expired from the cache yet. +- Producer or signature privacy: Content authenticity in content-addressable networks is guaranteed through signatures. This is a very powerful feature, but at the same time it always reveals the identity of the signing authority or producer. Although techniques such as ephemeral signatures and anonymous credentials have been proposed, there isn't yet a widely accepted and tested solution. + + ## State of the Art -> This survey on the State of the Art is not by any means complete, however, it should provide a good entry point to learn what are the existing work. If you have something that is fundamentally missing, please consider submitting a PR to augment this survey. +> This survey on the State of the Art is not by any means complete, however, it should provide a good entry point to learn what are the past and existing efforts in the area. If you have something that is fundamentally missing, please consider submitting a PR to augment this survey. ### Within the IPFS Ecosystem > Existing attempts and strategies @@ -52,6 +64,33 @@ Onion routing is a technique for anonymous communication over a computer network ### Within the broad Research Ecosystem > How do people try to solve this problem? +A general and rather simple approach and rule of thumb is to use an anonymising proxy which is placed between a sender and a receiver of traffic. This inevitably means that there is trust placed on this proxy to behave as desired. Decentralised approaches (that don't necessarily have to trust proxies or proxy operators) rely on layered encryption and multiple extra hops of routing so that any message cannot be linked to its originator/source. + +Research has generally fallen into one of two areas: i) those solutions that target non-delay-sensitive applications (e.g., email or FTP) and ii) those that do (e.g., VoIP, web). Traditionally, those classes have different requirements and therefore, different tradeoffs in terms of performance-anonymity requirements. + +Solutions to the first category include mix-network techniques, where, for instance, there is extra (spurious) traffic inserted in the network to obfuscate the environment and make it difficult to correlate traffic with senders and receivers. Artificially adding extra delay on the path from source to destination has also been a popular technique in this area. + +On the other end of the spectrum, anonymisation approaches that target delay-sensitive applications mainly consist of choosing random next hops to add an extra indirection (and encryption) on the path from source to destination. + +Past research has indicated several approaches to anonymisation and privacy, but very little has seen adoption to date (e.g., Tor, I2P). We believe that with the renewed interest in P2P, decentralised networks a fresh look is nedeed in order to either identify or re-design techniques that fit present-day challenges. + +- ICN-related Literature + - On preserving privacy in content-oriented networks (ACM ICN 2011) + - ANDaNA: Anonymous Named Data Networking Application (NDSS 2011) + - Content-Centric and Named-Data Networking Security: The Good, The Bad and The Rest (IEEE LANMAN 2018) + +- Non Delay Sensitive Applications: + - Mixing email with Babel (NDSS 1996) + - Mixmaster Protocol -- IETF Internet Draft 2003 + - Maxminion: Design of type III anonymous remailer protocol (IEEE S&P 2003) + +- Delay-Sensitive traffic + - Passive attack analysis for connection-based anonymity systems, 2003 + - Anonymity for web transactions (ACM Transactions on Information and System Security 1998) + - Morphmix: peer-to-peer based anonymous internet usage with collusion detection, 2002 + - Tarzan: A peer-to-peer anonymising network layer, (ACM CCS 2002) + + - Authorization, Authentication, Accounting - [TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. - Data Encryption @@ -80,6 +119,7 @@ Some of the known shortcommings of existing solutions are: - Solutions that are more resistant (not fully resistent) typically trade off bandwidth + memory for creating that protection (e.g. creating noise in the network to make it hard to distinguish valid from dummy traffic) - Lack of data encryption at rest - Lack of complete authorization + revocation +- Lack of solutions to ensure content name privacy ## Solving this Open Problem @@ -89,6 +129,8 @@ Finding a complete solution to this Open Problem will grant any human in the pla It will lead to a generation of safer applications, both consumer level and business critical, that require full control of one's data (e.g. Health Data). +Such solutions will bring P2P, decentralised storage and delivery networks to a different level and will establish related platforms (such as IPFS) as the de facto standard for anonymous communication. + ### What defines a complete solution? > What hard constraints should it obey? Are there additional soft constraints that a solution would ideally obey? From 399fe13304b37bc5c0d95167117cf94389b8976d Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 26 Sep 2019 17:29:13 +0800 Subject: [PATCH 25/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md Co-Authored-By: Jorge Soares --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index b67485a..6f5483e 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -1,4 +1,4 @@ -# Preseve full users' privacy when providing and fetching Content +# Preserve user privacy when providing and fetching content ## Short Description > In one sentence or paragraph. From 141439089be4fab59de7a5363c32ce854de70b36 Mon Sep 17 00:00:00 2001 From: David Dias Date: Thu, 26 Sep 2019 17:30:33 +0800 Subject: [PATCH 26/29] Update OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 6f5483e..62217da 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -15,7 +15,7 @@ Some solutions exist to mitigate this problem (see the State of the Art section 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 +### 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. From e42a20e1336c8c48655b507fb35d4eaba1153fbe Mon Sep 17 00:00:00 2001 From: David Dias Date: Mon, 21 Oct 2019 15:59:27 +0200 Subject: [PATCH 27/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 52 +++++++++++++------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 62217da..bd8c1a9 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -66,7 +66,10 @@ Onion routing is a technique for anonymous communication over a computer network A general and rather simple approach and rule of thumb is to use an anonymising proxy which is placed between a sender and a receiver of traffic. This inevitably means that there is trust placed on this proxy to behave as desired. Decentralised approaches (that don't necessarily have to trust proxies or proxy operators) rely on layered encryption and multiple extra hops of routing so that any message cannot be linked to its originator/source. -Research has generally fallen into one of two areas: i) those solutions that target non-delay-sensitive applications (e.g., email or FTP) and ii) those that do (e.g., VoIP, web). Traditionally, those classes have different requirements and therefore, different tradeoffs in terms of performance-anonymity requirements. +Research has generally fallen into one of two areas: + +- i) those solutions that target non-delay-sensitive applications (e.g., email or FTP) +- ii) those that do (e.g., VoIP, web). Traditionally, those classes have different requirements and therefore, different tradeoffs in terms of performance-anonymity requirements. Solutions to the first category include mix-network techniques, where, for instance, there is extra (spurious) traffic inserted in the network to obfuscate the environment and make it difficult to correlate traffic with senders and receivers. Artificially adding extra delay on the path from source to destination has also been a popular technique in this area. @@ -74,41 +77,38 @@ On the other end of the spectrum, anonymisation approaches that target delay-sen Past research has indicated several approaches to anonymisation and privacy, but very little has seen adoption to date (e.g., Tor, I2P). We believe that with the renewed interest in P2P, decentralised networks a fresh look is nedeed in order to either identify or re-design techniques that fit present-day challenges. -- ICN-related Literature +- **ICN-related Literature** - On preserving privacy in content-oriented networks (ACM ICN 2011) - ANDaNA: Anonymous Named Data Networking Application (NDSS 2011) - Content-Centric and Named-Data Networking Security: The Good, The Bad and The Rest (IEEE LANMAN 2018) - -- Non Delay Sensitive Applications: +- **Non Delay Sensitive Applications** - Mixing email with Babel (NDSS 1996) - Mixmaster Protocol -- IETF Internet Draft 2003 - Maxminion: Design of type III anonymous remailer protocol (IEEE S&P 2003) - -- Delay-Sensitive traffic - - Passive attack analysis for connection-based anonymity systems, 2003 +- **Delay-Sensitive traffic** - Anonymity for web transactions (ACM Transactions on Information and System Security 1998) - Morphmix: peer-to-peer based anonymous internet usage with collusion detection, 2002 - Tarzan: A peer-to-peer anonymising network layer, (ACM CCS 2002) - - -- Authorization, Authentication, Accounting - - [TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. -- Data Encryption - - [DoubleRatchet](https://signal.org/docs/specifications/doubleratchet/) / [Matrix.org Olm/MegaOLM](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md#olm-a-cryptographic-ratchet) -- M2M Private Communication - - [Scuttlebutt Secret Handshare](https://dominictarr.github.io/secret-handshake-paper/shs.pdf) - - [HOPR - privacy-preserving messaging protocol ](https://github.com/validitylabs/hopr) - - [SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) - - [Talek: a Private Publish-Subscribe Protocol](https://raymondcheng.net/download/papers/talek-tr.pdf) - - [Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) -- Content Routing + - Passive attack analysis for connection-based anonymity systems, 2003 +- **Authorization, Authentication, Accounting** + - [2017 TahoeLAFS Capability System](https://en.wikipedia.org/wiki/Tahoe-LAFS) - The peer-base Cryptographic ACLs were inspired by TahoeLAFS Capabolity System. +- **Data Encryption** + - [2016 DoubleRatchet](https://signal.org/docs/specifications/doubleratchet/) / [Matrix.org Olm/MegaOLM](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md#olm-a-cryptographic-ratchet) +- **M2M Private Communication** + - [2014 Ricochet](https://github.com/ricochet-im/ricochet/blob/master/doc/protocol.md) + - [2015 Scuttlebutt Secret Handshare](https://dominictarr.github.io/secret-handshake-paper/shs.pdf) + - [2015 SoK: Secure Messaging](https://ieeexplore.ieee.org/document/7163029) + - [2016 Talek: a Private Publish-Subscribe Protocol](https://raymondcheng.net/download/papers/talek-tr.pdf) + - [2018 HOPR - privacy-preserving messaging protocol ](https://github.com/validitylabs/hopr) +- **Content Routing** - [Define privacy threat model for DHTs (and other overlay P2P networks)](https://github.com/gpestana/notes/issues/3) - - [Using Sphinx to Improve Onion Routing Circuit Construction](https://www.cypherpunks.ca/~iang/pubs/SphinxOR.pdf) - - [Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) -- Traffic Analysis resistant - - [Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) -- Other - - [Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) + - [2010 Using Sphinx to Improve Onion Routing Circuit Construction](https://www.cypherpunks.ca/~iang/pubs/SphinxOR.pdf) + - [2012 Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) + - [2019 Encrypted Distributed Hash Tables](https://eprint.iacr.org/2019/1126) +- **Traffic Analysis resistant** + - [2015 Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) +- **Other** + - [2018 Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) ### Known shortcommins of existing solutions > What are the limitations on those solutions? From b070a22f315642bfa40817a094851442d8f07802 Mon Sep 17 00:00:00 2001 From: David Dias Date: Mon, 21 Oct 2019 16:02:44 +0200 Subject: [PATCH 28/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index bd8c1a9..58a3fb2 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -60,6 +60,7 @@ Creating a separate IPFS Network will ensure that only member nodes can access t Onion routing is a technique for anonymous communication over a computer network. In an onion network, messages are encapsulated in layers of encryption, analogous to layers of an onion. The encrypted data is transmitted through a series of network nodes called onion routers, each of which "peels" away a single layer, uncovering the data's next destination. - [libp2p-onion](https://github.com/OpenBazaar/go-onion-transport) +- [p3lib-sphinx](https://github.com/hashmatter/p3lib/tree/master/sphinx). Implements the sphinx onion packet format along with logic for packet construction and relaying. This protocol is used in lightning network and in Nym and there is also [a demo of p3lib-sphinx working with libp2p](https://github.com/hashmatter/libp2p-onion-routing), [and a video](https://www.youtube.com/watch?v=j64C5CTb8J8). (Basically it allows libp2p nodes to delegate DHT requests using other libp2p nodes as relayers. This is pretty cool since you don't have to plug in/depend on any other overlay (i2p/Tor) and provide similar unlikeability and privacy properties (providing that you have enough entropy in the network and do not leak the circuit path). ### Within the broad Research Ecosystem > How do people try to solve this problem? From e0a8fc3b918974ab513cceaa05ec751c573daf18 Mon Sep 17 00:00:00 2001 From: David Dias Date: Mon, 21 Oct 2019 16:07:40 +0200 Subject: [PATCH 29/29] Update PRESERVE_USER_PRIVACY.md --- OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md index 58a3fb2..9d98c0b 100644 --- a/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md +++ b/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md @@ -107,7 +107,11 @@ Past research has indicated several approaches to anonymisation and privacy, but - [2012 Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005) - [2019 Encrypted Distributed Hash Tables](https://eprint.iacr.org/2019/1126) - **Traffic Analysis resistant** + - [2009 ShadowWalker: peer-to-peer anonymous communication using redundant structured topologies](https://dl.acm.org/citation.cfm?id=1653683) - [2015 Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf) +- **Private Information Retrieval** + - [XPIR : Private Information Retrieval for Everyone](https://eprint.iacr.org/2014/1025.pdf) + - [PIR with compressed queries and amortized query processing](https://eprint.iacr.org/2017/1142.pdf) - **Other** - [2018 Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf) @@ -117,6 +121,7 @@ Past research has indicated several approaches to anonymisation and privacy, but Some of the known shortcommings of existing solutions are: - They don't offer protection against network analysis (it is possible to infer what the user is doing by analysing network traffic) +- Some of the solutions (e.g. OctopusDHT) rely on centralised certificate authorities for reputation management - Solutions that are more resistant (not fully resistent) typically trade off bandwidth + memory for creating that protection (e.g. creating noise in the network to make it hard to distinguish valid from dummy traffic) - Lack of data encryption at rest - Lack of complete authorization + revocation @@ -137,13 +142,18 @@ Such solutions will bring P2P, decentralised storage and delivery networks to a Valid solutions should improve the current state of the art or offer definitive solutions for: -- [ ] Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom. -- [ ] No single central authority are required to mediate the communication -- [ ] A provider has a way to grant and revoke access to information. +- Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom. +- No single central authority are required to mediate the communication +- A provider has a way to grant and revoke access to information. +- A user can discover public information without leaking information about their interest. An adversary should not be able to link two or more discovery requests either. As additional constraints -- [ ] Mechanism to prevent data exfiltration (e.g. when a user goes rogue) +- Mechanism to prevent data exfiltration (e.g. when a user goes rogue) + +Also, contributions towards solving this Open Problem can be in the form of answers to the following questions: + +- How to measure privacy? ## Other