0: Determine suitable Privacy Enhancing Technologies based on high-level constraints (technical, legal, organizational). This tree assumes involvement of at least two parties, but should be traversed by every party individually. The references given in part of the nodes refer to sections in the accompanying Guide.
§1: Introduction
§2: Decision tree usage
§3: Scoping?Start of the tree. We stress the assumption that this tree is useful in cases where at least 2 parties are involved but that each party should traverse the tree separately. When parties come together afterwards it is assumed that the knowledge obtained, and the choices they made speed up the collaboration process.
1: Type of problem
§2.4: Type of problem.
§4: Legal considerations?The type of challenge that is to be tackled plays a big part in the choice of a PET as different applications have aspects that affect the choice differently. This should be clear later on. It could be that a problem can be solved in different ways (for example 'set intersection' or 'statistical analysis'), please use the tree multiple times to explore the possibilities. Besides playing with the tree we recommend reading the accompanied guide as soon as possible. Specifically if any data involved contains personal data, the GDPR legislation is important (see Section 4 in the Guide).
Machine learningFor the Machine Learning type of challenge, we consider problems where an actual model is involved, either by training or for evaluation. We do not consider other forms of statistical analysis as they are separately examined.
2: Type of machine learning
§4.2: GDPR principles and PET (fairness)?For the Machine Learning type of challenge, we consider problems where an actual model is involved, either by training or for evaluation. We do not consider other forms of statistical analysis as they are separately examined. If machine learning is trained on synthetic data, also the Synthetic Data path should be traversed.
Model evaluationBy Model Evaluation, we refer to cases where an existing model is to be evaluated on some data. The purpose could be a prediction or some metric computation to measure the performance of the model when applied on that data.
2.1: Single party provides input data??It is necessary to clarify whether the model evaluation will be performed on data belonging to one party.
No
2.1.1: Are the various data sources independent of each other from a ML perspective? (e.g. horizontally partitioned)
§6.1: Data sources independence?In the case of Machine Learning, the outcome of a model is a set of parameters where each roughly corresponds to a feature of the dataset. There are 2 distinct cases: a) each data owner owns the same features but on different subjects (horizontal partition) or b) each data owner owns different of the features but on the same subjects (vertical). We refer to the first case as data source independence.
No
2.1.1.1: Is the model sensitive?
§6.3: Data vs model and output sensitivity
§4.2: GDPR principles and PET (integrity and confidentiality)?By model sensitivity, we mean that the model itself is to be protected. This can occur either if there are serious concerns that the model can leak information about the data on which it was trained or if the model owner wishes to keep the model private for organizational reasons, such as commercial confidentiality.
No
2.1.1.1.2: Is the input data confidential?
§6.3: Data vs model and output sensitivity
§4.2: GDPR principles and PET (integrity and confidentiality)?We know that the model is not sensitive, but it is relevant to consider the data's sensitivity as well. In case the data is sensitive, one will need to consider whether the local computations are sensitive and thus potentially add a layer of privacy to protect them.
No
2.1.1.1.2.1: Probably solvable without privacy-preserving technologies or trusted third parties?In case neither the data nor the model are sensitive, or the model is but the data is not, there is no need for privacy-preserving technologies to evaluate the model considering the model is owned by one party.
Yes
2.1.1.1.2.2: When parties evaluate the model with a lot of data, might this evaluation potentially lead to (partially) confidential results?
§4.2: GDPR principles and PET (integrity and confidentiality)?At this point, we conclude that the local model evaluations are possible, either by: a) the data being sensitive but the model not -> each party receives part of the model b) the model being owned by multiple parties and sensitive but the input data not sensitive -> the data are sent to the equivalent parties c) each party owning equivalent features and model parameters -> each party immediately performs the local computations. The issue now is whether it is possible to combine the local computations in the clear. This might not be the case because of what these local results may reveal for the model and/or data, depending on which is sensitive.
No
2.1.1.1.2.2.2: Federated Analytics
§Appendix A: Federated Learning?Since the local computations themselves are not sensitive, federated analytics can be used to combine them without need for centralization.
Yes
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.1.1: Is the input data sensitive?
§6.3: Data vs model and output sensitivity
§4.2: GDPR principles and PET (integrity and confidentiality)?Data being sensitive means the data itself being under protection. This can be due to different reasons, including privacy or other legislations, commercial reasons or simply due to other policies of the organization owning the data.
No
2.1.1.1.1.2: Is the model owned by a single party?
§6.3: Data vs model and output sensitivity?We know that the model is sensitive but the input data is not. In the case where the model is owned by one party, the solution can be to have the data parties send their data to the model party and receive back the evaluation's result. If multiple parties own the model, it is not always possible to perform the evaluation in the clear.
No
2.1.1.1.2.2: When parties evaluate the model with a lot of data, might this evaluation potentially lead to (partially) confidential results?
§4.2: GDPR principles and PET (integrity and confidentiality)?At this point, we conclude that the local model evaluations are possible, either by: a) the data being sensitive but the model not -> each party receives part of the model b) the model being owned by multiple parties and sensitive but the input data not sensitive -> the data are sent to the equivalent parties c) each party owning equivalent features and model parameters -> each party immediately performs the local computations. The issue now is whether it is possible to combine the local computations in the clear. This might not be the case because of what these local results may reveal for the model and/or data, depending on which is sensitive.
No
2.1.1.1.2.2.2: Federated Analytics
§Appendix A: Federated Learning?Since the local computations themselves are not sensitive, federated analytics can be used to combine them without need for centralization.
Yes
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.1.2.1: Probably solvable without privacy-preserving technologies or trusted third parties?In case neither the data nor the model are sensitive, or the model is but the data is not, there is no need for privacy-preserving technologies to evaluate the model considering the model is owned by one party.
Yes
2.1.1.1.1.1: Do the parties have insight (in the clear) in the part of the model that relates to their attributes??Do all parties have the required information from the model to perform the model evaluation locally?
No
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.1.2.2: When parties evaluate the model with a lot of data, might this evaluation potentially lead to (partially) confidential results?
§4.2: GDPR principles and PET (integrity and confidentiality)?At this point, we conclude that the local model evaluations are possible, either by: a) the data being sensitive but the model not -> each party receives part of the model b) the model being owned by multiple parties and sensitive but the input data not sensitive -> the data are sent to the equivalent parties c) each party owning equivalent features and model parameters -> each party immediately performs the local computations. The issue now is whether it is possible to combine the local computations in the clear. This might not be the case because of what these local results may reveal for the model and/or data, depending on which is sensitive.
No
2.1.1.1.2.2.2: Federated Analytics
§Appendix A: Federated Learning?Since the local computations themselves are not sensitive, federated analytics can be used to combine them without need for centralization.
Yes
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.2: Is it possible for the parties to exchange model or data?
§6.3: Data vs model and output sensitivity?We know that the model is not sensitive, but it is relevant to consider the data's sensitivity as well. In case the data is sensitive, one will need to consider whether the local computations are sensitive and thus potentially add a layer of privacy to protect them.
No
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.2.2: Probably solvable without PETs or trusted third parties?We reached this decision because either: a) the model and data are owned by the same party or b)there is one data party and one model party and it is possible to exchange model or data or c) there is one model party, two or more data parties, each party's data is independent from the model's perspective and it is possible to exchange model or data between the model party and each of the data parties. In all of these cases, solving the problem does not require privacy enhancing technologies or usage of a third party.
Yes
2.1.2: Does the data party own the model??In case one party owns the data where the model will be evaluated, then we should know whether that data party owns the model as well. This will help decide the level of privacy protection needed.
No
2.1.1.2: Is it possible for the parties to exchange model or data?
§6.3: Data vs model and output sensitivity?We know that the model is not sensitive, but it is relevant to consider the data's sensitivity as well. In case the data is sensitive, one will need to consider whether the local computations are sensitive and thus potentially add a layer of privacy to protect them.
No
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
2.1.1.2.2: Probably solvable without PETs or trusted third parties?We reached this decision because either: a) the model and data are owned by the same party or b)there is one data party and one model party and it is possible to exchange model or data or c) there is one model party, two or more data parties, each party's data is independent from the model's perspective and it is possible to exchange model or data between the model party and each of the data parties. In all of these cases, solving the problem does not require privacy enhancing technologies or usage of a third party.
Yes
2.1.1.2.2: Probably solvable without PETs or trusted third parties?We reached this decision because either: a) the model and data are owned by the same party or b)there is one data party and one model party and it is possible to exchange model or data or c) there is one model party, two or more data parties, each party's data is independent from the model's perspective and it is possible to exchange model or data between the model party and each of the data parties. In all of these cases, solving the problem does not require privacy enhancing technologies or usage of a third party.
Model trainingBy Model Training, we refer to cases where one wishes to create a model by training on existing data and outputting a set of model parameters.
2.2: Single party provides input data??For Model Training, it is relevant to consider whether the training data is owned by one more parties. This is due to the fact that in the case of a single data owner, the output of the model is the only aspect that may require privacy layers and training can happen in the clear.
No
2.2.2: Are the various data sources independent of each other from a ML perspective? (e.g. horizontally partitioned)
§6.1: Data sources independence?When Model Training or Statistical Analysis is to be performed and the input data is split among parties, it is relevant to consider in what way it is split. There are 2 distinct cases: a) each data owner owns the same features but on different subjects (horizontal partition) or b) each data owner owns different of the features but on the same subjects (vertical). We refer to the first case as data source independence.
No
2.2.2.2: Is an MPC solution the result of the Set intersection route??In case the data sources are not independent, then the Set Intersection route applies as well. Hence, one should complete it before answering this question, and then observe whether the decided upon intersection method involves MPC or not.
No
2.2.2.2.2: Federated Analytics and/or MPC*?If a non-MPC method is used for the intersection, then either Federated Analytics, or MPC, or a combination of the two can be used for the statistics computation.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
2.2.2.1: Federated Analytics/Learning
§Appendix A: Federated Learning?In case the data sources are independent, then Federated Analytics (for Statistical Analysis) or Learning (for Model Training) should be performed. However, federation is not always sufficient to protect sensitivity, hence one should continue traversing the tree for additional measures.
2.2.2.1': Are the locally computed values to be exchanged sensitive?
§6.5: Sensitivity of locally computed values?Federated solutions assumes that some computations are locally performed by each data party and then are centrally aggregated. Hence, examining whether the results of the local computations are sensitive is a deciding factor for additional privacy layers.
No
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1': Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as Secret Sharing requires it. In case it is not possible, Homomorphic Encryption is suggested.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1': Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?If the application is not mainly based on multiple local multiplications and addition, then Secret Sharing is the best solution.
No
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.2': Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2: GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
2.2.1: Is there an output party that did not provide data??If there is a single data party, the question is whether that party is the only one seeing the resulting model or not.
No
2.2.1.2: Probably solvable without privacy-preserving technologies or trusted third parties?If the resulting model is not revealed to anyone but the data party, or it is but it is not sensitive, then the whole process can happen in the clear.
Yes
2.2.1.1: Is the model sensitive?
§4.2: GDPR principles and PET?In case there is a different output party, model sensitivity is a relevant factor. A model being sensitive in this context means that it can reveal information about the underlying training data.
No
2.2.1.2: Probably solvable without privacy-preserving technologies or trusted third parties?If the resulting model is not revealed to anyone but the data party, or it is but it is not sensitive, then the whole process can happen in the clear.
Yes
2.2.1.1.1: Differential privacy
§6.3: Data vs model and output sensitivity
§4.2: GDPR principles and PET?If the model is sensitive, then differential privacy should be incorporated to the training in order to avoid leaking information to the output party.
Set intersectionThe type of problem Set Intersection can be either a subproblem of any of the other problems, or a problem by itself. An example of the second scenario is when organizations wish to match their datasets without planning to perform a specific analysis per se. In this case, only the Set Intersection route shall be traversed. On the contrary, when additional analysis is intended, the tree shall be traversed twice: once for Set Intersection and once for said analysis (Machine Learning, Statistical Analysis or Synthetic Data Generation).
4: Can the identifiers be shared between the parties?
§4.2: GDPR principles and PET (integrity and confidentiality)?The most straightforward way to match the databases would be to share common identifiers of some sort. However, it is not always possible to do so as this would allow each party to know which subject the other parties own, even if the identifiers themselves are pseudonymized.
No
7.1: Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1: Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2: Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1: Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2: Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1: Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
7.1.1.1: Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
4.2: Probably solvable without privacy-preserving technologies or trusted third parties?If the identifiers can be shared freely, there is not a need to use PET or TTP, as the intersection can happen as it is using the identifiers.
Statistical analysisBy Statistical Analysis, we refer to cases where one or more parties wish to compute a set of statistical metrics (e.g. counts, averages, standard deviations, quantiles, histograms, frequency plots, ...) on their data and receive the results.
3: Single party provides input data??One or more parties may provide the data for the computation. It is important to clarify it as it may affect the privacy levels needed.
No
7.1': Are all parties able and willing to trust a common third party for data processing and computation?
§Appendix A: TTP?Such a party is also known as a 'trusted third party' or TTP. Does such a party exist for this application, and if so, are the involved parties able and willing to trust such a common third party for data processing and computation?
No
7.1.2': Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1': Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2': Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1': Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
2.2.2: Are the various data sources independent of each other from a ML perspective? (e.g. horizontally partitioned)
§6.1: Data sources independence?When Model Training or Statistical Analysis is to be performed and the input data is split among parties, it is relevant to consider in what way it is split. There are 2 distinct cases: a) each data owner owns the same features but on different subjects (horizontal partition) or b) each data owner owns different of the features but on the same subjects (vertical). We refer to the first case as data source independence.
No
2.2.2.2: Is an MPC solution the result of the Set intersection route??In case the data sources are not independent, then the Set Intersection route applies as well. Hence, one should complete it before answering this question, and then observe whether the decided upon intersection method involves MPC or not.
No
2.2.2.2.2: Federated Analytics and/or MPC*?If a non-MPC method is used for the intersection, then either Federated Analytics, or MPC, or a combination of the two can be used for the statistics computation.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
2.2.2.1: Federated Analytics/Learning
§Appendix A: Federated Learning?In case the data sources are independent, then Federated Analytics (for Statistical Analysis) or Learning (for Model Training) should be performed. However, federation is not always sufficient to protect sensitivity, hence one should continue traversing the tree for additional measures.
2.2.2.1': Are the locally computed values to be exchanged sensitive?
§6.5: Sensitivity of locally computed values?Federated solutions assumes that some computations are locally performed by each data party and then are centrally aggregated. Hence, examining whether the results of the local computations are sensitive is a deciding factor for additional privacy layers.
No
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1': Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as Secret Sharing requires it. In case it is not possible, Homomorphic Encryption is suggested.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1': Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?If the application is not mainly based on multiple local multiplications and addition, then Secret Sharing is the best solution.
No
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.2': Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2: GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
7.1.1': Is this trusted party legally allowed to have access to and process the raw data? And is it organizationally desirable?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness)?It is also important to note whether this trusted party is legally allowed to have access to the data.
No
7.1.2': Could data be allowed to leave the premises if it is aggregated and/or encrypted?
§4: Legal considerations
§4.2: GDPR principles and PET (lawfulness, international transfer)?If there is no such third party or it is not allowed at all to share raw data, the possibility of sharing aggregated and/or encrypted data should be explored. Please get yourself familiar with the legal considerations concerning data sharing in encrypted or unencrypted form in the guide to make a decision.
No
7.1.2.1': Is the use of a Trusted Execution Environment desirable from a legal and organizational perspective?
§Appendix A: TSE
§4.2: GDPR principles and PET (lawfulness, purpose limitation)?If it is not possible to share even encrypted data, then MPC is not possible. Hence, one should consider emulating a TSE on premise of one of the participating parties.
No
7.1.2.1.2': Impossible??If neither TTP, nor encrypted data sharing, nor TSE can be used, then the application cannot happen. One might want to consider loosing some restrictions or reevaluating the application's feasibility.
Yes
7.1.2.1.1': Trusted Secure Environment at the premises of one of the parties
§Appendix A: TSE?If TSE is possible, then one of the parties should emulate it at their own premises.
Yes
2.2.2: Are the various data sources independent of each other from a ML perspective? (e.g. horizontally partitioned)
§6.1: Data sources independence?When Model Training or Statistical Analysis is to be performed and the input data is split among parties, it is relevant to consider in what way it is split. There are 2 distinct cases: a) each data owner owns the same features but on different subjects (horizontal partition) or b) each data owner owns different of the features but on the same subjects (vertical). We refer to the first case as data source independence.
No
2.2.2.2: Is an MPC solution the result of the Set intersection route??In case the data sources are not independent, then the Set Intersection route applies as well. Hence, one should complete it before answering this question, and then observe whether the decided upon intersection method involves MPC or not.
No
2.2.2.2.2: Federated Analytics and/or MPC*?If a non-MPC method is used for the intersection, then either Federated Analytics, or MPC, or a combination of the two can be used for the statistics computation.
Yes
6.1: Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as secret sharing protocols send many messages among the involved parties. Even for simple protocols, hundreds or thousands of messages are exchanged. If your infrastructure does not support setting up connections that last for the entire protocol, the overhead of making a connection for every message may have significant negative impact on the duration of the protocol. In this case, homomorphic encryption may be a better option as it exchanges only few messages (although the messages themselves are larger).
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1: Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?Additively homomorphic encryption is most powerful if the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value. If more involved operations are foreseen, then Secret Sharing is probably better suited for the challenge at hand.
No
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
6.1.1.2: Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2 GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2: Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
Yes
6.1.1.1: Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
Yes
2.2.2.1: Federated Analytics/Learning
§Appendix A: Federated Learning?In case the data sources are independent, then Federated Analytics (for Statistical Analysis) or Learning (for Model Training) should be performed. However, federation is not always sufficient to protect sensitivity, hence one should continue traversing the tree for additional measures.
2.2.2.1': Are the locally computed values to be exchanged sensitive?
§6.5: Sensitivity of locally computed values?Federated solutions assumes that some computations are locally performed by each data party and then are centrally aggregated. Hence, examining whether the results of the local computations are sensitive is a deciding factor for additional privacy layers.
No
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1': Are parties able to maintain a connection for high-throughput communication during the computation?
§Appendix A: MPC?Whether it is possible to maintain high throughput communication between the parties during the computation is important, as Secret Sharing requires it. In case it is not possible, Homomorphic Encryption is suggested.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1': Multiple local multiplications and additions?
§Appendix A: MPC
§4.2: GDPR principles and PET (integrity and confidentiality)?If the application is not mainly based on multiple local multiplications and addition, then Secret Sharing is the best solution.
No
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.2': Is there need for a flexible implementation (frequent update of the architecture)?
§Appendix A: MPC
§4.2: GDPR principles and PET (accuracy, storage limitation)?If the required mathematical operations in the solution primarily consist of additions and multiplication by a locally known value, the need for flexibility is the deciding factor. If it is likely that, in time, new secure functionalities are to be implemented then it is convenient to have a flexible fundament. Solutions based on homomorphic encryption are often very tailored to the specific problem, whereas secret-shared based solutions are often more flexible and enable potentially frequent updates of functional requirements.
No
6.1.2': Homomorphic Encryption
§Appendix A: MPC?Overall, Homomorphic Encryption should be chosen if it is not possible to maintain high throughput communication or there is need for multiple local multiplications and additions and no need for flexibility. In any other case, Secret Sharing should be used.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
6.1.1.1': Secret Sharing
§Appendix A: MPC?Secret Sharing is generally an easier to use, more flexible solution and should be used unless there is a reason not to.
2.2.2.1.1: Is the output of the computation sensitive?
§6.3: Data vs model and output sensitivity?The analytics or learning performed will result to a statistic or model respectively. Thus, one should consider whether that result is in itself sensitive. Sensitive in this context means that it can reveal information about the underlying data on which it was computed.
Yes
2.2.2.1.1': Differential Privacy (complimentary to the solution already suggested)
§Appendix A: Differential privacy?In case the output of the computation is sensitive, Differential Privacy should be used during the computation to add noise and protect from information leakage.
Yes
7.1.1.1': Trusted third party
§Appendix A: TTP?In case there is a third party that the parties trust and are legally allowed to share information with, this party should be used for the computation.
Yes
3.2: Is there an output party that did not provide data??If there is a single data party, the question is whether that party is the only one seeing the resulting statistics or not.
No
3.2.1: Probably solvable without privacy-preserving technologies or trusted third parties?If the resulting statistics are not revealed to anyone but the data party, or they are but they are not sensitive, then the whole process can happen in the clear.
Yes
3.2.2: Is the output sensitive?
§6.5: Sensitivity of locally computed values?In case there is a different output party, output sensitivity is a relevant factor. A statistic being sensitive in this context means that it can reveal information about the underlying data on which it was computed.
No
3.2.1: Probably solvable without privacy-preserving technologies or trusted third parties?If the resulting statistics are not revealed to anyone but the data party, or they are but they are not sensitive, then the whole process can happen in the clear.
Yes
3.2.2.2: Differential privacy?If the output is sensitive, then differential privacy should be incorporated to the computation in order to avoid leaking information to the output party.
Synthetic dataSynthetic data generation refers to cases where one wishes to generate new data based on some other data's distribution and characteristics, e.g. with the purpose of creating larger datasets for testing. We assume that the original data used to generate synthetic data is sensitive. Else, it is immediately possible to synthesize data without employing some PET to protect the original data from potential reconstruction by using the synthetic data.
5: Single party provides input data??It is important to know whether a single party provides the original data from which synthetic data will be created.
No
5.2: Privacy-Preserving version of the technique used (see the start of the tree) & Differential Privacy?If there are multiple data providing parties, the data synthesizing algorithm will be applied on them combined, thus there may be a need for applying it in a privacy-preserving way. Thus, the tree should be traversed depending on the type of data synthesizing algorithm used (e.g. if Neural Networks are used, one should traverse the /Machine Learning/Model Training subtree). Differential Privacy should be also used as in 5.1.
Yes
5.1: Differential privacy
§Appendix A: Differential Privacy?If there is one data providing party, Differential Privacy can be used to ensure that there is enough noise on the synthesized data to protect the original data. The data synthesizing algorithm itself does not need to be applied in a privacy-preserving way.