# What about privacy?

**URL:** <https://discuss.ipfs.tech/t/what-about-privacy/13667>\
**Category:** Ecosystem and Usage\
**Created:** [March 6, 2022, 4:02pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667 "2022-03-06T16:02:23Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 4:02pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/1 "2022-03-06T16:02:23Z")

</div>

At the time being, building decentralized social media applications on top of ipfs seems to me quite an hazard.

Imagine participating to a social network in which people can easily track and link your activity to your IP address. That is not good for social media app, it’s too risky.

My two cents. I might be wrong but to me it seems that the safest way to connect to the IPFS network is by means of a star-signaling-node - which however requires trust.

In addition, it might be unfeasible to delete some contents. This is a huge issue which, in my opinion, does not have enough attention. Let us move away for a second from IPFS and consider the Bitcoin Blockchain. What if someone decides to publish really sensitive data on the bitcoin blockchain? Imagine the crazy stuff people are willing to do during a war and imagine what could happen.

All in all, I think that it will be difficult to reach end-user at this stage and I suspect that what people are going to build will not help the end user having better products and experiences.

Finally, whatever the protocol, it’s hardly impossible to move away from the requirement of having a VPS.

---

<div class="post-metadata">

**Author:** ![markg85](https://avatars.discourse-cdn.com/v4/letter/m/41988e/32.png) [@markg85](https://discuss.ipfs.tech/u/markg85)\
**Post date:** [March 6, 2022, 4:25pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/2 "2022-03-06T16:25:38Z")

</div>

> [@LucaPanofsky](#):
>
> Imagine participating to a social network in which people can easily track and link your activity to your IP address. That is not good for social media app, it’s too risky.

Please do explain how you think that can happen?  
What you describe is how the “old web” works. There you have a central server that serves the site. That central server can monitor (just the webserver logs really) and try to track users.

How does that same logic apply to a distributed network? You miss the central part to even be able to monitor. The **most** you can do is monitor who accesses the files on nodes you control. But if you site is populated on more nodes then even that kind of monitoring will - at the very least - be inaccurate and more likely to be just useless.

> [@LucaPanofsky](#):
>
> My two cents. I might be wrong but to me it seems that the safest way to connect to the IPFS network is by means of a star-signaling-node - which however requires trust.

If you think that way, just use central servers. Why do you need trust? In IPFS the trust is guaranteed due to the hashing going on that your node internally verifies for you.

> [@LucaPanofsky](#):
>
> In addition, it might be unfeasible to delete some contents. This is a huge issue which, in my opinion, does not have enough attention. Let us move away for a second from IPFS and consider the Bitcoin Blockchain. What if someone decides to publish really sensitive data on the bitcoin blockchain? Imagine the crazy stuff people are willing to do during a war and imagine what could happen.

That’s both a strength and a weakness. A well known one.  
While the data might be online and available through the network, that doesn’t mean it’s easy to find. Let’s continue your hypothetical case with something more tangible. Lets say a “youtube on IPFS” alternative exists. Somehow somewhere there needs to be a list of “files” to present on that site. You can - and in a distributed world should - use a mechanism where there is still a certain amount of control on that list. That would allow those in control to prevent certain entries from getting on it or remove them if they got on it. This doesn’t mean the data is gone. It only means the easy access point is gone.

> [@LucaPanofsky](#):
>
> All in all, I think that it will be difficult to reach end-user at this stage and I suspect that what people are going to build will not help the end user having better products and experiences.

Explain that please? You sound like you’re skeptical and try to motivate people not to use IPFS. Why?

> [@LucaPanofsky](#):
>
> Finally, whatever the protocol, it’s hardly impossible to move away from the requirement of having a VPS.

? That makes 0 sense to me.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 4:57pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/3 "2022-03-06T16:57:29Z")

</div>

![Schermata da 2022-03-06 17-51-45](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/c/c7752abc0100220228200bacd4d052025ce82fbf.png)

> **[How does IPFS Impact my Privacy?](https://support.brave.com/hc/en-us/articles/360051406452-How-does-IPFS-Impact-my-Privacy-)**
>
> The InterPlanetary File System (IPFS) is a protocol enabling a globally distributed, peer-to-peer network for storing and accessing files, websites, applications and data. IPFS uses content address...

Have a look at this (which does not depend on Brave by the way). If one develops a social media application he MUST informs users about that. Also, it seems that VPN and TOR might not be enough to really protect the ip address. And this is a problem.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 5:03pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/4 "2022-03-06T17:03:00Z")

</div>

If you have a solution, please tell me. Cause I wanted to build social application but I will not allow user to run their local node cause I will not jeopardize their privacy. Because of that, I prefer a star signaling server which must be deployed somewhere. And here is were trust is needed for the provider sees the connections. Yet, I still prefer this model.  
Alternatively, the network could be really distributed with just local nodes and that would be really cool. Unfortunately it’s too risky. That’s my opinion.

---

<div class="post-metadata">

**Author:** ![noname](https://avatars.discourse-cdn.com/v4/letter/n/58f4c7/32.png) [@noname](https://discuss.ipfs.tech/u/noname)\
**Post date:** [March 6, 2022, 5:04pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/5 "2022-03-06T17:04:18Z")

</div>

> [@LucaPanofsky](#):
>
> In addition, it might be unfeasible to delete some contents. This is a huge issue which, in my opinion, does not have enough attention. Let us move away for a second from IPFS and consider the Bitcoin Blockchain. What if someone decides to publish really sensitive data on the bitcoin blockchain? Imagine the crazy stuff people are willing to do during a war and imagine what could happen.

I don’t think you can just put any information on Bitcoin blockchain.  
It wouldn’t be possible to remove content easily, but that doesn’t seem to be a problem to me, this problem also exist centralized applications. Suppose you post a picture on Instagram, and someone have seen it and downloaded it. And later you delete the post, now there is no way for Instagram to remove the copy from the person who downloaded it. (Think this as caching in IPFS, and there is no difference)

A simple thing to remember, anything on client side isn’t secure, either it be centralized or decentralized apps.

> [@LucaPanofsky](#):
>
> All in all, I think that it will be difficult to reach end-user at this stage and I suspect that what people are going to build will not help the end user having better products and experiences.

I would agree on this, the end user doesn’t care anything about whether the backend is centralized or decentralized. At this stage the creators/developers of applications using these technologies are going to benefit more than the end user.

> [@LucaPanofsky](#):
>
> Finally, whatever the protocol, it’s hardly impossible to move away from the requirement of having a VPS.

You may need a VPS in the beginning, so that at least one guaranteed peer will have the replicated database. This will ensure that your site won’t disappear into nothingness. But the advantage would be, the more the number of users the less you spend on resources.

You can think about BitTorrent, it is a technology useful for sharing large files and will cost less for creator of the file to distribute the file. But it is has become a synonym for piracy, I can think the same thing will happen to IPFS, it’s features will do more bad than good.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 5:10pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/6 "2022-03-06T17:10:08Z")

</div>

On the bitcoin blockchain you can post string data, the only constraint, as far as I know, is that the more data you write the higher the fee you have to pay. However, nothing prevents you from delivering the contents in different transaction would there be a kind of max size limit.

Thank for your first point and example with Instagram, I think you are correct.  
Could you explain more in depth your point “anything on client side is not secure”, what do you mean precisely?

---

<div class="post-metadata">

**Author:** ![markg85](https://avatars.discourse-cdn.com/v4/letter/m/41988e/32.png) [@markg85](https://discuss.ipfs.tech/u/markg85)\
**Post date:** [March 6, 2022, 5:16pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/7 "2022-03-06T17:16:52Z")

</div>

So you want full 100% anonymity.  
Using IPFS would already be many many many times better then a normal website.

I think you’re misreading the notes from Brave as a concern for you.  
Let me put it in the most clear terms i can imagine: **you don’t know who visits your site therefore you can’t track your users**.

Now that statement is true if your site is distributed enough. As the users amongst themselves keep the site online.

Even when users interact with your site you only - **i repeat, only!** – see their CID. A CID (in IPFS, not true for IPNS) cannot be traced back to a specific user.

As for your local node reluctance. Forget it. If you don’t want a local node then just forget about IPFS. IPFS lives by the sheer number of users running a node. If you don’t want to participate then don’t use it.

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [March 6, 2022, 5:21pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/8 "2022-03-06T17:21:04Z")

</div>

> [@LucaPanofsky](#):
>
> Also, it seems that VPN and TOR might not be enough to really protect the ip address.

It will be, the issue is that IPFS is BIG and we need to cover anything.  
For example a dumb Tor transport might work but will not protect you from DNSLink leaks, so you need to cover that too. You also need to cover the `0.0.0.0` resolver, maybe it also leaks IPs.

It’s not so much of “can’t be done”. But more of: “require A LOT of security audits”

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 5:22pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/9 "2022-03-06T17:22:43Z")

</div>

lol watch your tone.  
First, I do not want 100% anonimity I am just trying to understand. You said I did not understand, so please explain, if you can of course.  
It seems to me that the ip can be linked to the peer ID thorugh the DHT table. If this is not possible just tell me it is not possible and this is fine.  
[https://news.ycombinator.com/item?id=12719771](https://news.ycombinator.com/item?id=12719771)

> [@markg85](#):
>
> Now that statement is true if your site is distributed enough. As the users amongst themselves keep the site online

And about your final point. I was just thinking about that running a browser node is MORE SAFE than a local node, so please teach me coding not decentralization

---

<div class="post-metadata">

**Author:** ![noname](https://avatars.discourse-cdn.com/v4/letter/n/58f4c7/32.png) [@noname](https://discuss.ipfs.tech/u/noname)\
**Post date:** [March 6, 2022, 5:23pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/10 "2022-03-06T17:23:43Z")

</div>

If you want 100% anonymity then,  
IPFS with I2P is best for protecting everyone’s privacy, nobody reveals there IP address but still use BitTorrent like technologies, only significant drawback the network is too slow, which would change as the number of nodes increase on I2P network.

> [@LucaPanofsky](#):
>
> Could you explain more in depth your point “anything on client side is not secure”, what do you mean precisely?

Let’s take example of Netflix, anything available on Netflix is being pirated easily, now Netflix maybe using encryption and other standards to protect there content from being pirated, but anything that is delivered to client side will be misused in someway.  
YouTube Vanced is a mod version of YouTube where there are no ads, now this is a different client that the original YouTube, but Google simply can’t stop this from happening.

People think encryption will protect everything, this is good for transferring something between 2 trusted parties, so that middleman couldn’t do anything, but whenever you are sending to a client, you should never trust it.

That’s why these companies trust on law and order not there client side apps.

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [March 6, 2022, 5:25pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/11 "2022-03-06T17:25:35Z")

</div>

> [@LucaPanofsky](#):
>
> It seems to me that the ip can be linked to the peer ID thorugh the DHT table. If this is not possible just tell me it is not possible and this is fine.

Ju_ST Do_Nt PUt _youR IP_ In T_hE Dh_T T_hEN_. (_use IPFS over Tor or i2p_). 🙂  
The issue again, is that writing a good tor or i2p transport require covering lots of conner cases and features.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 5:25pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/12 "2022-03-06T17:25:36Z")

</div>

Thank you very much, I will also have a look at I2p

---

<div class="post-metadata">

**Author:** ![markg85](https://avatars.discourse-cdn.com/v4/letter/m/41988e/32.png) [@markg85](https://discuss.ipfs.tech/u/markg85)\
**Post date:** [March 6, 2022, 5:27pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/13 "2022-03-06T17:27:55Z")

</div>

> [@LucaPanofsky](#):
>
> It seems to me that the ip can be linked to the peer ID thorugh the DHT table. If this is not possible just tell me it is not possible and this is fine.

Again.  
You don’t know the peer id’s.  
There is no central place for you to “monitor for peer id’s”.  
You’re concerned about something you should just forget. You don’t see peer id’s. Period.

You will see CID’s (content identifiers). You cannot trace back a CID to a peer id.  
So therefore you cannot trace a CID back to an IP.

I’d advice you to just try and make something. You’re scared of problems that are really the least of your concerns when using a distributed technology.

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [March 6, 2022, 5:35pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/14 "2022-03-06T17:35:14Z")

</div>

> [@markg85](#):
>
> You will see CID’s (content identifiers). You cannot trace back a CID to a peer id.  
> So therefore you cannot trace a CID back to an IP.

Maybe I’m being pedentic, but you do see Peer IDs, you just don’t really know what they do.

For example you can do

```auto
ipfs dht findprovs Qmfoo

```

To find peerIDs that host the file Qmfoo.  
Then:

```auto
ipfs dht findpeer 12DFoo

```

To find their addresses (so IPs if they don’t use Tor).

But you don’t know if that is caching, if this node is lying when they say they host that file just to throw you off or if they actually created a file.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 6, 2022, 5:36pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/15 "2022-03-06T17:36:11Z")

</div>

I have an application built on top of ipfs + orbitId. Peers use their peer id to identify themeselves.

 ![Schermata da 2022-03-06 18-31-30](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/c/c5e541b98b19d7ab53085013824739530d3bb432.png)

This is what I found on the Ipfs docs about privacy. It seems to me that what you are saying is, if not totally false, at least misleading. In any case, a social media app in which IP are easily linked to id it’s dangerous. If you think it is not it’s the problem of your end users, not mine.

Finally, thank for your advice but I am building something. What I am saying is that for now i prefer using the star signaling server. You are just saying the problem does not exist. Maybe I have to study more, and I will continue to do it.

---

<div class="post-metadata">

**Author:** ![markg85](https://avatars.discourse-cdn.com/v4/letter/m/41988e/32.png) [@markg85](https://discuss.ipfs.tech/u/markg85)\
**Post date:** [March 6, 2022, 5:37pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/16 "2022-03-06T17:37:07Z")

</div>

Correct me if i’m wrong, but that’s when you actively search for who hosts a given CID.  
In a website or app context you will never see that, right?

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 7, 2022, 12:46am UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/17 "2022-03-07T00:46:36Z")

</div>

I have found this github discussion which seems to clarify many of the issues I have been trying to discuss.

> <https://github.com/ipfs/notes/issues/37>
>
> chatting with Juan Bennet at c-base, Berlin about Tor onion service integration
> …
> here's what we've identified as necessary for proper Tor integration:
> 1. adding \`/onion\` to \[go-multiaddr\](https://github.com/jbenet/go-multiaddr) - \`/onion/\<onion-key\>/ipfs/\<ipfs-key\>\`
> 2. adding \`/onion\` dialing to \[go-multiaddr-net\](https://github.com/jbenet/go-multiaddr-net)
> 3. make a build of go-ipfs that:
> \- \*\*only\*\* uses \`/onion\`
> \- \*\*only\*\* bootstrap to onion nodes 
> \- disable mdns service
> \- disable NAT service
> 
> I know plenty of people who'd be willing to run some Tor onion bootstrap nodes.
> 
> (edited by @jbenet for links)

---

<div class="post-metadata">

**Author:** ![arunadaybasu](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/arunadaybasu/32/6206_2.png) [@arunadaybasu](https://discuss.ipfs.tech/u/arunadaybasu)\
**Post date:** [March 20, 2022, 6:13am UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/18 "2022-03-20T06:13:00Z")

</div>

Hey @LucaPanofsky

So I have begun working on something like that though it will probably turn out to be a microblogging platform eventually.

You have to think of this differently.

Data on the IPFS will ALWAYS be public, so f you are looking at privacy from the perspective of making it hard for people to download someone else’s photo or get someone’s personal details, then you need a more centralized approach. Maybe IPFS isn’t the best for that. I am sure that what you are storing with OrbitDB can also be accessed in some way from IPFS like @Jorropo demonstrated its possible to get peer ids for a file on IPFS.

Think of it like this:

SINCE you ALWAYS know WHO uploaded a file to IPFS, you can ALWAYS verify who is the OWNER of the file.

Maybe you can write a function that just checks whether the user has got the file from somewhere (that he is trying to upload to your website/app) or he created the file on his own system using the website/app. If he wants to still upload the file to IPFS, he can still do that but it won’t be part of YOUR network since YOU have complete control over that. You can list whichever files you want on your website/app and no one can inject files into your DAGs - which is why IPFS.

Your Merkle DAG is YOURS. Completely.

For more on that you should definitely do this course:

> **[IPLD Tutorial | Merkle DAGs: Structuring Data for the Distributed Web](https://proto.school/merkle-dags/)**
>
> Learn how we can use CIDs to create content-addressable data structures for the distributed web!

Thanks.

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [March 20, 2022, 10:23am UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/19 "2022-03-20T10:23:34Z")

</div>

Thank you for your answer. I completely agree with you, however to me the problem is not about the the fact that it’s possible to infer who is the owner of a file but the possibility of finding the link between her id and her ip through the dht

---

<div class="post-metadata">

**Author:** ![LucaPanofsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lucapanofsky/32/4868_2.png) [@LucaPanofsky](https://discuss.ipfs.tech/u/LucaPanofsky)\
**Post date:** [April 11, 2022, 10:46pm UTC](https://discuss.ipfs.tech/t/what-about-privacy/13667/20 "2022-04-11T22:46:45Z")

</div>

it seems to me that you are missing the point. The problem lies in the fact of being able to link ip addresses and peer identities through the dht

This is the issue, denying it won’t do any good.
