In parallel to existing pull requests, please find attached the following complementary updates. The main changes are motivated hereafter.
In the beginning, only providing aggregation as a potential use-case of private computation (see e.g. the sentence "Private computation can be used to perform aggregation over inputs which, individually, must not be revealed.") might lead to think that the scope of private computation is limited to this use-case. It would be relevant to provide other examples of private computations adtech companies could perform using APIs based on TEEs or MPC. As an example, machine learning (ML) training for campaign optimization use-cases could be performed (albeit not currently proposed by existing APIs). Mentioning the latter use-case is important since it could be proposed in future APIs to offer adtech companies the opportunity to train private ML pipelines on non-aggregated data instead of resorting to ML training techniques taking as inputs noisy aggregated data obtained via Aggregation APIs.
Regarding the "Privacy" definition, "receive nothing beyond the intented result" instead of "learn nothing beyond the intented result" seems more appropriate. Indeed, even with a differentially private output, it could still be possible to learn some insights from the output. On the other hand, receiving a DP output allows to be clear on the threat model that is addressed.
In the beginning, entities (helper parties) on which MPC and TEEs rely are referred to as aggregators. In the sequel, aggregators are only associated with MPC. It might be more appropriate to state from the beginning that helper parties will be either referred to as aggregators for MPC and coordinators for TEE to avoid some misunderstandings.
As stated in Section 1.8, instantiating helper parties could be done on-premise or via cloud providers. Even if the on-premise solution might be less common a priori, it might be useful to analyze threat models in that case.
Hello,
In parallel to existing pull requests, please find attached the following complementary updates. The main changes are motivated hereafter.
In the beginning, only providing aggregation as a potential use-case of private computation (see e.g. the sentence "Private computation can be used to perform aggregation over inputs which, individually, must not be revealed.") might lead to think that the scope of private computation is limited to this use-case. It would be relevant to provide other examples of private computations adtech companies could perform using APIs based on TEEs or MPC. As an example, machine learning (ML) training for campaign optimization use-cases could be performed (albeit not currently proposed by existing APIs). Mentioning the latter use-case is important since it could be proposed in future APIs to offer adtech companies the opportunity to train private ML pipelines on non-aggregated data instead of resorting to ML training techniques taking as inputs noisy aggregated data obtained via Aggregation APIs.
Regarding the "Privacy" definition, "receive nothing beyond the intented result" instead of "learn nothing beyond the intented result" seems more appropriate. Indeed, even with a differentially private output, it could still be possible to learn some insights from the output. On the other hand, receiving a DP output allows to be clear on the threat model that is addressed.
In the beginning, entities (helper parties) on which MPC and TEEs rely are referred to as aggregators. In the sequel, aggregators are only associated with MPC. It might be more appropriate to state from the beginning that helper parties will be either referred to as aggregators for MPC and coordinators for TEE to avoid some misunderstandings.
As stated in Section 1.8, instantiating helper parties could be done on-premise or via cloud providers. Even if the on-premise solution might be less common a priori, it might be useful to analyze threat models in that case.