European subnet on the Internet Computer: A Step Toward GDPR-Ready Infrastructure

Governance
1

European subnet on the Internet Computer: A Step Toward GDPR-Ready Infrastructure

TL;DR

We are submitting a proposal to create a European subnet on the Internet Computer, which will offer a GDPR-aligned infrastructure for decentralized applications. The EU subnet is a significant step towards enabling data sovereignty in the EU, as it lays the foundation for developers and enterprises to actively ensure their applications are GDPR-compliant.

This post focuses on how the Internet Computer (IC) blockchain’s European subnet provides a GDPR-ready infrastructure.

Introduction

The General Data Protection Regulation (GDPR) imposes strict rules on data protection and privacy. Traditional blockchain technologies face challenges in complying with these regulations, due to their immutable and distributed nature. The Internet Computer differs for its ability to combine a set of permissioned subnet blockchains with a DAO-controlled governance system, which allows subnets to contain servers distributed within one geographical area. If the proposal for the European subnet is adopted, it would allow dapps to be compliant by:

  • Ensuring data is processed and stored within the EU to align with GDPR’s jurisdictional requirements.
  • Providing the platform and tamperproof infrastructure necessary to build GDPR-compliant applications.

Innovations Enabling the European Subnet

Due to its hybrid architecture and customizable canister smart contracts, the Internet Computer allows the following features that are crucial for GDPR compliance:

  • State on the Internet Computer is not public
  • Data amendment and deletion is possible
  • Dapps have full data and access control
  • Decentralized network, where node providers go through a rigorous vetting process before being voted in by token holders.

In addition to the above features, there are two upcoming features on the Internet Computer, that will enable developers to further enhance the privacy and security of user data within the regulation of GDPR:

  • VetKeys, currently under development, will allow distributed decryption, where no single node holds the complete decryption key. This approach enhances data security, preventing unauthorized access.
  • AMD SEV-SNP, also in development, aims to secure the boundary node Virtual Machine (VM), isolating it from potential external threats. This technology creates a digital fortress around data, ensuring that all node machines within the European subnet are shielded from all unauthorized access, keeping data secure and highly confidential – encrypted both at rest and in memory.

What the European Subnet Means for Developers

By creating a European subnet on the Internet Computer, developers and enterprises will become able to:

  • Build and deploy applications within a GDPR-aligned infrastructure.
  • Leverage a platform that balances blockchain’s decentralization with regional data sovereignty needs.

Note: the proposed creation of a European subnet only means that it will become possible to create GDPR-compliant applications. Developers and enterprises will still need to take further measures to ensure services and applications meet all GDPR requirements.

Having a European subnet on the Internet Computer is a pivotal step in enabling the development of applications aligned with the GDPR and paving the way for digital sovereignty in Europe.

Please feel free to give feedback or ask questions. Open discussion is welcome.

43 Likes
2

I am concerned about the safety of AMD SEV-SNP. There have been incidents of internal key leakage due to a bug in a different type of enclave TEE SGX (Æpic exploit) .
I don’t think private keys are stored in enclaves of SEV-SNP, but it is possible that confidential data could be leaked.
How do you plan to deal with this faile safe?

3 Likes
3

Hi @hokosugi the security team has actually looked into this potential exploit (if I am not mistaken you are referring to the same exploit, correct me if I am wrong), and assessed that for the IC this risk is limited: see this forum post How to check if Node Machines are GEN1 or GEN2 - #2 by SvenF.

By the way many thanks for the note as it is important that we need to keep reviewing potential exploits based on the hardware specification!

7 Likes
4

This is a significant step forward in promoting user-centric control over personal data, as individuals can have greater visibility and authority over how their information is utilized in various applications.

Influence on different market segments is substantial, especially in industries dealing with sensitive personal data such as healthcare, finance, and legal services. Health applications, for instance, can leverage the EU subnet to build decentralized health records systems that adhere to GDPR, ensuring secure and transparent data handling. In the financial sector, decentralized finance (DeFi) applications can benefit from the heightened privacy measures, attracting users concerned about data breaches and unauthorized access.

The project’s influence extends to sectors like education, where student data privacy is a significant concern, and e-commerce, where consumer trust in handling personal information is vital for sustainable growth.

3 Likes
5

Very critical feature! We had discussion on this topic while ago. GDPR compliant nodes and subnets. Also important for compliance in other jurisdictions like HIPAA/ Healthcare in US.

3 Likes
6

This is great! I’m excited to see dynamic network configuration for use cases like this.

3 Likes
7

Secure enclaves seems to provide a different kind of security and I mean, cryptography gives you a very low probability of someone hacking it, while hardware security gives you a very high tech barrier.
If a developer uses Vetkeys and nodes use secure enclaves, you get two layers of protection. One has to be able to hack enclaves and also gather the pieces from multiple nodes to finally read the private data.

3 Likes
8

Two levels of privacy protection are possible on top of the normal non-publicized state. It would be similar to the concept of a government cloud or sovereignty cloud to build nodes intra-regionally on top of it.
I expect the adaptable Service to be extensive.

2 Likes
9

When reading this I was just wondering the following:
Why wouldn’t you create a global framework that is superior than the protection GDPR offers and unequivocally respects and serves privacy beyond what any region can offer? Shouldn’t blockchain lead rather than follow?

2 Likes
10

@DukeNukem, EU data protection laws prescribe that personally identifiable information is only stored within, and does not leak outside, EU borders, where European privacy standards are legally enforceable. Anybody who wants to do business in the EU must follow these laws, and hence can only use a blockchain to store user data if it meets this requirement, regardless of other privacy advantages it may offer.

7 Likes
11

Will there be some mechanism to make it obvious to users that a subnet is hosted in one geographic region only? If the URL is the typical trust indicator, it might make sense to have a domain for EU/europe only. Of course we cannot restrict custom domains, but having default canister URLs as https://CANISTER_ID.EU_DOMAIN or something like that might help communicate where the computers are running.

2 Likes
12

So this is more about configurable geo-restriction in subnets. Thanks for clarifying.

2 Likes
13

Dear all, please note that the proposal for creation of the specific subnet type for the european subnet has been submitted for voting under proposal 126328.

Once approved two subsequent proposals will be submitted:

  • one proposal for the creation of a new subnet with only european node machines.
  • one proposal for assigning the new subnet type to the newly created subnet.

Please feel free and continue to give feedback or ask questions regarding the proposals, if any.

6 Likes
15

The proposal for creating the subnet is out. Please take a minute to vote.

For transparency, the Nakamoto coefficients across all 6 dimensions that we track are as follows:

image
image2045×811 185 KB

The way to read the above is:

  • 1 continent (Europe) can collude (work together) to halt the subnet, or otherwise behave maliciously
  • 2 countries would have to collude, 1 would not be able to do damage
  • 3 cities would have to collude, 2 or less would not be able to do damage
  • 4 DC owners would have to collude
  • 5 DCs (since some DCs share the owner) would have to collude
  • 5 node providers would have to collude

In other subnets we have better decentralization, but even this isn’t bad.

4 Likes
16

A principal-ID is not personally identifiable information.

So is this whole thing really needed?

Let us examine the intent behind GDPR:

  • GDPR has the goal to ensure that user privacy is garanteed.
  • To reach that goal, GDPR requires data to be hosted on servers that are GDPR compliant.
  • Since Europe can’t enforce this outside of Europe, they require European citizen’s data to be hosted in Europe.

We should focus on the intentor the law:

  • ICP’s architecture already is GDPR compliant, no matter where the servers are hosted.
  • Most ICP dapps don’t ask for user private data, and instead rely on ICP’s internet identity+principal model, which is already private. So what is it? Do Principal-ID’s respect privacy or not?
  • It depends more on developers to open source their dApps and respect user privacy.
  • It doesn’t make a difference if the subnet is in Europe, but the dApp track’s users private data and keeps it in a canister to which the admin has access to (though GDPR totally accepts that situation🙄)
  • If the dApp already is gdpr compliant, then the server locations make no difference in the sense or GDPR.

There is no need to move the servers outside of Europe unless the dApp plans to do KYC, and store the data, which is not the kind of project we should want on ICP. We should support dApps that implement new creative approaches to KYC that don’t require storing user data, or don’t require KYC at all.
We shouldn’t be storing personally identifiable information. This should be the rule across all of ICP, no just in Europe.

I think it is much more important to explain all this to European officials, to make them recognize ICP as GDPR compliant as a whole, then to create an exception subnet for Europe.

Heck: the ideal scenario would be to convince the European officials that, if they want to be truly GDPR compliant, dApps should be running on ICP, and not on centralized servers. (I’m allowed to dream, right?:smiling_face_with_tear:)

Now, the counter argument:

It is probably easier to implement this exception for Europe, to get faster recognition and acceptance from the same government officials that came up with the mess that is GDPR in the first place. These people probably won’t bother to understand ICP. They didn’t even bother to come up with a better system for GDPR. Probably no use trying to swim against the current.

And KYC is a mandatory reality for apps like DEX’s, which are forced by the government to identify their users. There is no way around that.

So from this perspective, we DO need an european subnet. I just hope that it is only used by dApps that can’t work otherwise, like DEX’s, and not by just every european company out there. It sounds like an excuse to track user’s data: “why are you complaining that we require your ID, email, phone number and address? we are GDPR compliant so its fine” is not really what I would like to see on ICP.

3 Likes
17

It would be nice to have a GDPR subnet. It is more of an ICP to be able to offer various types of subnets (chains), public chains, consortium chains, DeFi with no KYC, DeFi with KYC, etc. should all be offered.
Yumi is already a marketplace that does KYC. No wonder there are developers and service providers who want to do DeFi with KYC due to the strict regulations and RWAs involved in recent years.
I am concerned about the demand for the GDPR subnet based on the results of the market survey.

3 Likes
18

That is a great idea!

3 Likes
19

As much as you might wish otherwise: as is, the (global) IC is literally not compliant with regulations for personal data. No jurisdiction will recognise otherwise. It doesn’t help trying to define the problem away, you’d need the regulations to actually change. That however will take years, and the chances of success are slim. Lawmakers in this area are bombarded by lobbyism, so are not easily convinced. And Blockchain in particular isn’t exactly a tech too many outside our bubble care about – nor have we sufficiently demonstrated yet that they should wrt privacy!

5 Likes
20

From the official GDPR regulation:

Source: GDPR article 4: Definitions: 1. ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

“…an identifiable natural person is one who can be identified, directly or indirectly”

And you can find more on the handling of annonymous data uner Recital 26 and Article 11 of GDPR:

Recital 26: This recital addresses the concept of anonymous data. It states that the principles of data protection should not apply to anonymous information, meaning data that does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a way that the data subject is no longer identifiable.

Article 11 (Processing which does not require identification): This article specifies that the GDPR does not apply to the processing of personal data that does not fall under the definition of personal data or where the data subject is not identified or identifiable. This includes processing for statistical purposes, as long as appropriate safeguards are in place.

GDPR does NOT apply to annonymous data.

So, the questions relevant to ICP:

  • Can the principal-ID be used by Dfinity or make a connection to the internet identity?
  • And even if it did: does the internet identity link-to or store any personal data like email, IP address, etc?

If the answer to those questions is “no”, then it is not a metter of “wishing” ICP to be compliant. It is what is written in the law. This is not legal advice on the matter, but it states pretty clearly that ICP is GDPR compliant by default.

It only stops being compliant once the dApp oversteps its boundaries and stores personal data. Things like:

  • KYC
  • physical address
  • email / login with google
  • phone number
  • IP address / cookies

As long as elements like those aren’t included, the global ICP network is 100% GDPR compliant.

Unless I am overlooking something, of course. Can you send me the source that states otherwise?

1 Like
21

@erikblues, when somebody wants to do “physical” business with people, there is no way around storing personal identifiable information, like real name, post address, etc. This is essential for the majority of “real” businesses. Do we want the network to be usable for real business or do we want it to constrain itself to niche nonsense like NFTs?

5 Likes