IPFS Website & GDPR Compliance

Dear IPFS users, developers, community,

first of all I would like to introduce myself, since this is my very first post. My name is Thomas and together with my colleague we developed a small data-science service, where the results from the user’s requests are uploaded on IPFS. Our site will be reachable via IPNS and we will set a DNS Link to “convert” the IPNS hash to a simpler format. This will allow users to access IPFS more easily. Some might not have IPFS installed and will use the Gateway.

Our product is actually finished. So why do I post in “Help” and not “Announcement”?

The problem is the uncertainty of the European GDPR. As a German startup we must follow the GDRP law and the derived rules. More specific: what happens with the personal data (IP addresses)? This can be easily answered if you have a central server. However, our service will exclusively be on IPFS. Some users might access it via the official Gateway, however, we do not know how the Gateway behaves, what kind of data it stores, etc. Shall / must we contact the IPFS developer team to set up a form, where all details are provided?

We would really like to establish a startup and a web service using exclusively IPFS. We are very keen to try this, but are (maybe too much) concerned about the ambiguous new data policy laws.

Best regards from Germany,


I don’t have a solid answer but ultimately I see this breaking down into 2 different scenarios.

####Primary/Native IPFS connectivity
This is where you would need to be to be sure you are compliant as it is how you officially designed and intended the users to transfer, store, and consume data.

With that said I am unsure if IPFS would be compliant as the current implementation has not been hardened yet so it leaks a lot of metadata to connected peers. (Requested blocks, ip addresses, request timestamps, etc)

####Secondary/Gateway connectivity
IMHO this would fall under the same situation as if users connected via an 3rd party proxy/VPN to a traditional centralized service.
It would be unreasonable for developers to be responsible for what a 3rd party collects when the user has chosen to pass data through them. Although I may be wrong and you could be responsible under this scenario as-well, unreasonable or not.

Hello Chris,

thank you for your answer and thoughts on this topic.

Exactly, the sending and receiving of several meta data is exactly the problem. And I also agree, that developers cannot be responsible for the “entire Web 3.0” behavior. The biggest issues is, that politics and law makers are beyond current technological possibilities. Just a quick off topic remark: I had a talk with some federal state politicians and entrepreneurs during a startup get-together meeting and literally nobody heard about Web 3.0, its technological and data political implications (though: most of them very really interested in this topic, after I explained the basic concepts).

Maybe the safest approach would be to put information in the “Terms & Conditions” as well as in the “Data Policy” section. Informing users and possible customers, that they use a Web 3.0 website and that certain meta data can be fetched by third parties without or consent and that using e.g. a VPN or Tor network would be recommended. I would suggest to list the connection possibilities as you did: Primary / Native IPFS connectivity; Secondary / Gateway connectivity. Again, one cannot know all peers, all their software, what they exactly do and who they are. It is absolutely impossible, and I think, that mentioning these problems in the corresponding web site sections (T&C, Policy), should be fair enough until Web 3.0 becomes more mainstream.

If you would like to add something, or if others want to participate, please do so! Its not a fun topic at all, I agree. But if Web 3.0 and IPFS shall become adapted by more people, or even startups (like us), we have to discuss data political implications.