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

Dear all, the proposal for linking the newly created subnet with only european node machines with the subnet type “european” is submitted for voting. Please find it under proposal 126391. Once this proposal is approved, the creating of the european subnet is completed.

Feel free to continue to discuss and give your feedback any of the aspects of a european subnet.

2 Likes

Yes, that’s what I was saying here:

So my key points summarized:

  • if the data is anonymous, it doesn’t need european servers to be GDPR compliant. ← this covers most current published ICP dApps and was important to mention to avoid misinformation.
  • if the dapp stores personal information, it requires the european subnet to be GDPR compliant.
  • but encourage dApps to not collect user information and/or anonymize user information.

IMO a good long-term strategy would look like this:

  • create an european subnet now.
  • incorporate rules to prioritize dApps in the European subnet that actually require personal data collection to function. Avoid those that simply didn’t bother to keep user data anonymous and/or unaccessible, because that could alienate users and hurt ICP.
  • optional: consider starting the work on getting ICP recognized as GDPR compliant by the government, because that could take years.

It would be amazing if ICP was the first blockchain to be recognized as GDPR compliant.

1 Like

Yes, I would completly agree with you that it is as simple as that @erikblues if there was not a statement of

ARTICLE 29 DATA PROTECTION WORKING PARTY
and it’s
Opinion 05/2014 on Anonymisation Techniques
Adopted on 10 April 2014

The above opinion - if still valid has to be taken into account as in EU nothing is as simple as it looks like :slight_smile:

3 Likes

I guess if a cautious European entity starts using the European subnet, they will start gaining experience of blockchain and with that their confidence will grow and maybe they will make the next step. Sometimes one needs to go where the customer is, even if that place has questionable advantages. :smiley:

2 Likes

DFINITY NexGen Canisters are the foundation for a European L-1, DLT Cloud Trust Ecosystem to monetize the world’s most robust cyber security data protection laws!

Designing a Use Case for regulatory-compliant multi-canister solutions will attract mass adoption to the IC!

Any clarification on these EU privacy directives assumptions will be well received.

If GDPR regulates companies, organizations or individuals that process the personal data of natural persons in the EU and defines anonymous data as personally identifiable information that can’t directly or indirectly identify a data subject:

  1. Wouldn’t processing the unique ID wallet address in an IC Canister for a user in the EU trigger GDPR compliance obligations?

  2. Wouldn’t processing pseudonymous IC identifiers representing a user within the EU require a node provider to comply with Schrems II’s SCC directives and Ch. 3 (Art. 12-23) of GDPR?

  3. What about specifically for the IC identity used by a fiduciary of non-canister principal ID accounts?

  4. Would the IC decentralized ID holder be considered a Joint Controller per Ch. 4, Art. 26?

  5. Wouldn’t a European legal entity be required to offer regulatory-compliant data processing services to individuals in the EU?

  6. Would an EEA-based node provider hosting a canister storing personal data attributes on an EU Subnet be subject to ePrivacy and DSA directives under GDPR?

The EU Data Protection Board’s assessment of the new EU-U.S. data transfer framework has fueled a lot of uncertainty, especially in light of last year’s new sensitive data provisions by the Swiss revFADP.

Canister-based EU subnets may add the missing technical link to the CJEU’s recurring legislative attempts—to harmonize data privacy regulations across the Digital Single Market.

The learning curve of the IC is making it challenging to receive clarification on these questions from EU compliance advocates.

Thanks for any feedback.

2 Likes

IIUC most if not all these exploits require physical access. They are generally difficult to pull of. GDPR requires you put security controls in place. I doubt that the history of secure enclave vulnerabilities would be considered sufficient to justify that AMD SEV-SNP is insufficient to protect PII from node operators.

That said, the IC will also provide the alternative of VetKeys in case you have greater confidentiality requirements than SEV-SNP could guarantee. The design of your dApp needs to allow the VetKeys approach.

1 Like