Skip to content

GDPR Questions

Xenia Bogomolec edited this page Apr 8, 2018 · 10 revisions

Xenia Bogomolec -


Blockchain based applications are the perfect tools for data retention. Physical deletion of data from the chain is not possible without destroying the integrity of blockchain itself.

The GDPR (General Data Protection Regulation) is a regulation by which the European Parliament, the Council of the European Union and the European Commission intend to strengthen and unify data protection for all individuals within the European Union from May 25th 2018.

Worldwide Uniqueness

While we can complain about weaknesses, loopholes or bad implementations of data protection, we have to appreciate the effort of the EU to protect its citizens. There is nothing similar being issued in the rest of the world.



The 6 basic technical requirements that have to be considered for an implementation are

  • Consent requires a clear understandable form which has to be agreed upon before a user signs up to an application.
  • Right of Access means that a user is allowed to have insight into the data relating to him/her.
  • Right to Erasure is handled by physical or logical deletion of data.
  • Right of Revocation means that users must be able to revoke their consent.
  • Blocking of Data is marking of data such that its processing can be restricted.
  • Right to Portability requires the possibility of data transfer to third parties.

High availability is another requirement which will depend on the kind of the implementation of the above properties served by the application.

Depending on the Ledger

The ledger, respectively the Ethereum Blockchain plays a special role in the context of data protection. Due to its design it comes with designated properties which are different from traditional data bases. Deleting data from it is not possible. Neither can be 100% controlled what happens to all copies of it on the machines all oveer the world. Therefore, the only way to meet

  1. Right to Erasure
  2. Right of Revocation
  3. Blocking of Data (Restriction of Processing)

in blockchain based applications, is to only upload anonymous data to the Ethereum blockchain, which can be mapped to natural persons by linking the data to their accounts. Like this, logical deletion, which is accepted by the GDPR can be be enabled within the application. When locigal deletion is possible, the base for revocation and restriction of processing is set too. TiiQu follows these principles consequently.

Independent from the Ledger

  1. Consent
  2. Right of Access
  3. Right to Portability

Those requirements can be implemented on top of the Ethereum VM layer. Consent will be intergrated in the TiiQu sign up form. The Right of Access is solved by default in Ethereum and will be respected by the functionality TiiQu implements on top of Ethereum. The Right to Portability will be under the control of the TiiQu members too.

Pseudonymization via cryptographic Hash Functions

The usage of those functions will serve the following benefits:

  1. Collision resistance of those functions will prevent any confusions of original inputs.
  2. The integrity of the source data is verified as well.
  3. A mapping to the source data is quickly computed by the owners of the source data
  4. No mapping tables have to be kept. The mapping can be done by only knowing the source data, a salt (random string) and the used hash function.
  5. Finding the source data by hacking the hash outputs from the TiiQu platform requires high cost computations and is not realizable within reasonable time.

Hashed data

Hashed data is considered pseudonymized rather that anonymized by a Working Party opinion of the EC. So purely hashed data in a blockchain cannot be considered GDPR compliant according to this opinion. TiiQu chose to use roots of Merkle Trees as pointers on the Ethereum Blockchain. Another option are Zero Knowledge Proofs.



Storage of Person Related Data

We do not store any person identifying data on the Ethereum network. We only store cryptographic references to identifying data. An example the techniques used are detailed in the verification section of the whitepaper

Personal details like name, DOB, address etc. are stored on our centralised servers with write and delete permissions given solely to the user for their data. Until decentralised databases can allow for data to be permanently removed they will not be suitable for GDPR compliance. Even with encrypted data on a decentralised DB, the exposure of the decryption key exposes all the data stored using that key.

Member Certificate Verification

The mechanism of the member certification includes both university and graduate computing

  1. hashes of the personal constituents
  2. hashes of the certification constituents

and upload the following data to the TiiQu Ethereum blockchain

  1. hash of the concatened hashes of 1. and 2. (→ certification hash)
  2. asymmetric signature of the upload
  3. public key of the account

If both upload’s certification hashes match and the signatures are verified by each other, the member certification is considered verified. This mechanism ansures an anonymous certificate verification which can only be related to a person if her or his ID is known. The content of the certificate is only visible to the TiiQu member and the university.


IDs and Names

On anybody can just enter any Ethereum ID and view the related transactions without further authentication.

Is it GDPR compliant if TiiQu members can see each other's Ethereum IDs?

The data uploaded by TiiQu is anonymous, but what about transactions from other applications?

Exchange of Person Related Data between TiiQu Members

For example if a company reads the name of a TiiQu member from the TiiQu servers and uses it in a contract.

How is our responsibility in this context?

Can we solve it by enabling direct communication between the TiiQu members?

Webcrawlers and third party JS libraries

The question of webcrawlers reading personal data from websites depends on how much can be accessed from a non TiiQu member or comes back to the question Exchange of Person Related Data between TiiQu Members if a webcrawler impersonates a TiiQu member. This question will have to be answered for applications in general.

How is our responsibility in this context?

Do we have to scan for webcrawlers and inform TiiQu members or can we solve it with the consent in the subscription?

Any third party JS library not being hosted on the TiiQu servers could get access to person related data without TiiQu noticing.

Are externally hosted third party JS libraries included in the Ethereum VW? If yes, do they access personal data?

Personal data delivered from trust sources

Trust sources will deliver us deliver sets of personal data from TiiQu members with confirmations and rating values. We will use those values to compute a trust quotient for this member.

Will we have to delete the relating child nodes in the TQ algorithm if the TiiQu member finishes their trust source membership?

The trust source owners will be ogligated to inform us about this. The deletion of the child node would lessen the trust score.

Can we let the TiiQu member decide if they want to keep the contribution of the finished membership in their trust quotient anyway?

How do we handle the same question if the data is not deleted but its processing is restricted at the trust source?

You can’t perform that action at this time.