Privacy concerns of transmitting the plaintext of all local models

Our method can integrate Local Differential Privacy (LDP) or Homomorphic Encryption (HE) to enhance privacy, ensuring that sensitive information remains protected while maintaining robustness. Our framework, like traditional FedAvg, is susceptible to privacy leakage if plaintext local model parameters are exposed. However, it can incorporate LDP, where clients add noise to the model before transmission, maintaining DP while creating behavioral planes. Although this process may result in some performance loss, it is comparable to other robust aggregation methods that calculate client similarities using differentially private model parameters. To further enhance privacy, our framework can integrate HE, which masks client models while allowing for inference on the validation set. Although this increases computational time during the aggregation, it ensures that sensitive information remains completely concealed from the server, thereby addressing privacy concerns effectively. We added a sentence in L348: "Since our method allows the integration of privacy-enhancing techniques such as LDP and HE, a promising future direction would be to analyze their impact on performance and efficiency".

Insufficient experimental evidence regarding the distinction of client behaviors through Behavioral Planes (BPs). Expected more results, e.g. the client behavioral scores

We have strengthened the experimental evidence by analyzing behavioral scores extracted from BPs, demonstrating that our method accurately identifies and mitigates malicious clients across all attacks. As suggested, we analyze the behavioral scores of honest and malicious clients across all attacks (Fig. B), which are calculated over the BPs. The 5-fold experiments were conducted on the CIFAR10 (most complex dataset), and show the mean and 95% confidence intervals during the training rounds. Statistically, our method consistently identifies malicious clients, effectively excluding or reducing their weights during aggregation. These results further demonstrate that BPs accurately describe malicious clients during the training process.

How sensitive the proposed method is to the intensity of the attacks

Our method remains stable and unaffected by increasing attack intensity, demonstrating robustness against model poisoning attacks. We analyzed the sensitivity of our method to attack intensity by increasing the amount of noise $\beta$ that attackers add to the global model before sending it to the server [L677]. We conducted 5-fold experiments on both the Breast Cancer and MNIST datasets. As shown in Fig. E, increasing attack intensity decreases FedAvg’s performance, while our methods (using all planes and only the counterfactual plane) remain stable and unaffected by the attack intensity. Interestingly, our methods’ accuracy slightly increased as attack intensity rose, likely because the malicious models became more degraded and, therefore, less stealthy.

A framework overview is missing, which makes it hard to understand how the planes are created throughout the FL iterations

We thank the reviewer for this observation. To address this limitation, we have provided a detailed algorithm (Algorithm 1) for our method to create the behavioral planes and implement our robust aggregation (FBSs). While Algorithm 1 covers the server operations, we will also include the algorithm for the client operations in the Appendix A.5 of the paper, which reflects the traditional FL algorithm.

Results in Table 1 make me confused whether the whole method is still run in a cannonical FL setting

Yes, our method operates within a canonical FL setting, with changes to server-side aggregation and the introduction of the counterfactual (CF) generator. The CF generator is trained jointly with the local client and does not alter the performance of the predictor alone (Table 1). For clarity, we updated L230-231: "We compared model accuracy across four settings: two centralized learning (CL) and two FL, using three different datasets under non-IID conditions. For FL experiments, we used the traditional FedAvg approach with two variations: predictor-only and predictor with CF generator."

What is the difference between proximity and sparsity?

These are standard metrics to quantitatively evaluate counterfactuals (CFs) [19, 35 in the paper]. Proximity measures how much our CFs are closer to our data distribution (distance between the CF and the closest data point in the training set with the same label), while sparsity measures how many features were changed between the initial sample and the CF. For clarity, we updated L208-209: “proximity (↓) [35], assessing the realism of CFs by their closeness to the training data (distance between the CF and the closest data point in the training set with the same label); and sparsity (↓) [19], which quantifies the changes made to the input to generate the CFs (number of features changed between the initial sample and the CF).”

What purpose does Eq. 4 serve?

Eq. 4 provides a theoretical foundation for understanding FL dynamics, describing how client behaviors evolve during training and are influenced by intermediate steps. As mentioned by both Rev-eMJr and ULpn, our primary goal is to provide a general theoretical foundation for understanding FL dynamics, specifically how client behaviors evolve during training and how they are influenced by intermediate steps (e.g., local training and aggregation). Eq. 4 describes the dynamics of client behaviors in the FL system. Although we did not analytically solve it, we experimentally observe its solutions through client behaviors using our planes. For clarity, we modify L97-98: "These dynamics can be encapsulated in the following differential equation, which describes how client behaviors evolve during training and are influenced by internal forces within the FL system".

Thank you for your valuable feedback. Please let us know if you have any further questions or if there are any points that need additional clarification. We would be grateful if you could consider updating your review in light of our responses.

The paper heavily relies on visual representations to explain client behaviors, infeasible for large FL systems.

Our method is scalable and automatically extracts and analyzes statistics from behavioral planes (BPs) to identify and mitigate malicious clients without relying on visual inspection. Visual inspection aids in understanding the characteristics under which malicious clients behave differently, but it is not necessary. Our defense extracts client-specific scores from BPs in large FL systems to reduce the impact of malicious clients. To further demonstrate scalability and automatic identification of malicious behaviors, we recorded client scores during training using CIFAR10 (Fig. B). These scores can identify malicious clients and reduce their contribution to the global model. Interestingly, as the model converges, more weight is given to the attacker with an inverted gradient, since its model closely resembles the global model from the previous round (plus a negligible inverted update). Visual inspection can still be useful for ML engineers to understand why certain clients are removed or contribute less, by visualizing on multiple planes where they differ from ‘honest’ clients (see Fig. 3). The experiments and discussion will be added to Appendix B.

Client selection at each round will affect trajectory on the planes.

Our method ensures that client selection does not impact the effectiveness of our defense (FBSs), as aggregation relies on both current and available historical behavior. Visualizations can track client trajectories based on selected rounds, maintaining a clear representation of client behavior. If a client is not selected in a round, its trajectory will not consider that particular round, but trajectories can still be created based on selected rounds. While the current focus is on evaluating client behavior over time, it is also possible to establish trajectories only for selected clients relative to the server’s position, ensuring accurate visualization not affected by client selection. Finally, although client selection influences the visual representation, it has no effect on FBSs, as aggregation depends on both current and historical client behavior (Moving Average in Sec. 3.5).

The method relies on a server validation set, which may be difficult to obtain without privacy concerns.

Several solutions can be integrated with our method to create a synthetic validation set on the server without transmitting sensitive information from clients. A clean validation set is a common assumption of existing methods [51, 45, 31 cited in paper]. To address this, some proposed solutions include optimizing for a clean validation set [15] and generating representative inputs through dimensionality reduction and stratified sampling [44]. As discussed in Sec. 6.2, we plan to:

• Apply an autoencoder or Bayesian probability conditioned on class labels to generate a synthetic dataset based on client data distributions
• Explore synthetic generation as in [44]

If the server has a validation set, our method weights each client to maximize global model performance on that test set, regardless of whether the model weights come from honest or malicious clients

When is the validation set fair to all clients? How to distinguish between an unfair validation set and an anomaly/attacker?

This is a great question, and that’s exactly why we proposed the multi-plane evaluation. Unlike traditional ML metrics such as accuracy or error, our defense method is not strongly influenced by the fairness of the validation set, as counterfactuals (CFs) are more closely related to the learned client decision process and data distribution than the evaluation set. Anomalous clients show unrelated CF distributions and high error, while underrepresented clients generate plausible CFs but are affected by the unfair validation set only in the error plane. To demonstrate effectiveness under an unfair validation set, we removed one client’s data from the validation set and recorded behavioral scores. Preliminary results (Fig. C) show that the 95% confidence interval of the unfair client’s score overlaps with those of other honest clients, distinguishing them from malicious clients. We introduce in L340: Considering the importance of fairness among clients and the promising results shown in Appendix B, the exploration of the impact of unfair validation sets and the development of other validation-independent descriptors, such as CFs, represent promising areas for future research.

Datasets are simple and baselines are not so recent

We have enhanced our experimental setup by introducing a more challenging dataset, CIFAR-10, with a 10-class classification task, and a recent robust aggregation baseline, RFA [Pillutla et al., 2022], into all our experiments to further demonstrate the robustness and effectiveness of our method. Even under these new conditions (Fig. A), our method outperforms or matches other baselines across all four datasets and all five attack conditions, except for Inv. gradient attacks in MNIST, where Trimmed mean performs better (1 out of 20 cases).

Is the counterfactual generator learned on the server?

No, the generator is simultaneously trained in an end-to-end fashion on the client-side along with the predictor [L139,L231]. Please refer to the common answers for model analysis.

How is the local CL’s accuracy computed, and why is it so much lower than FL in Table 1?

In Local CL, we train a separate model for each client’s private data, ensuring privacy by not sharing data across clients. In non-IID settings, training on single-client data reduces performance due to the lack of diverse data, explaining the lower accuracy of Local CL compared to FL, which uses data from all clients, in Table 1. We added in L235: For Local CL, we report the average accuracy of all models trained individually by each client and evaluated on a common test set

Thank you for your valuable feedback. Please let us know if you have any further questions or if there are any points that need additional clarification. We would be grateful if you could consider updating your review in light of our responses.

Computational Overhead and Evaluation Metrics, the paper could benefit from a detailed analysis of the computational costs.

As suggested, we performed a detailed analysis of the computational overhead of our framework, examining all its components: Local Computation, Communication Overhead, and Server-side Computation. Our evaluation metrics include GFLOPs for local inference, megabytes for communication, time complexity for the aggregation process, and the duration of one training round. We also conducted a comprehensive comparison with other methods. Please refer to the common comment (@Rev-eMJr,ULpn,aREF) for detailed results and discussions.

Scalability concerns. “While the experiments are comprehensive, they are conducted on relatively small datasets” Question: “How does the proposed method scale with a larger number of clients and more complex datasets?”

We enhance the robustness of our method’s validation by: 1) Introducing a more complex dataset, CIFAR-10. 2) Adding a new baseline, [K. Pillutla et al., RFA, 2022], for all experiments. 3) Experimentally demonstrating that our methods scale effectively with a larger number of clients. We introduced an experiment on CIFAR10, which is a larger dataset and a recent FL benchmark [K. Pillutla et al., RFA, 2022]. This experiment significantly improves the robustness of our validation, and Fig. A further demonstrates our method’s effectiveness in complex FL scenarios. Our method outperforms or matches other baselines across all datasets (Breast, Diabetes, small-MNIST, small-CIFAR10) and conditions (No attack, MP noise, MP inverted gradient, DP label flipping, DP inverted loss), except for Inverted gradient attacks in small-MNIST, where Trimmed mean performs better (note that this is 1 out of 20 cases). Additionally, we tested the scalability of our framework with up to 200 clients. As shown in Fig. D, our method introduces 1 extra minute per round with 200 clients, compared to FedAvg. In contrast, the baseline Krum introduces over 15 minutes per round. This demonstrates the efficiency and scalability of our approach.

Generalization across different models.

Our method, while focused on neural networks (NNs) and traditional FL, theoretically applies to other ML models like decision trees, though it requires appropriate aggregation processes and counterfactual (CF) generation. We focused our study on NNs and traditional FL, using differentiable models capable of producing a global model through parameter aggregation. However, extending our method to other ML models, such as decision trees, presents an interesting and challenging opportunity for future work due to their discrete model parameters (e.g., splitting rules and thresholds). Our proposed method is based not on the similarity between client model parameters, which can be problematic with such heterogeneous architectures, but on the client model’s performance and their respective decision-making process. Therefore, in theory, our defense method (FBSs) of evaluating client behaviors still holds with these ML models but requires a suitable aggregation process and CF generation. Various aggregation methods have been proposed in the literature for such models, which can be adapted for this purpose [Wang et al., Decision Tree-Based Federated Learning, 2024]. Additionally, generating CFs from interpretable models, such as decision trees, is straightforward due to their inherently explainable nature.

Interpretability and Usability. “The paper, while clear in its technical explanations, may still be challenging for practitioners who are not experts”.

To broaden the audience and facilitate the comprehension of our method, we introduce the pseudocode of our algorithm (Algorithm 1) for creating the behavioral planes on the server and implementing our robust aggregation method (FBSs).

Visualizations and Trajectories. Question: Can you provide more detailed examples or visualizations of client trajectories in the Error Behavioural Plane and Counterfactual Behavioural Plane (CBP)? Suggestion: Include more visual examples and explanations of client trajectories

In addition to the trajectories presented in Fig. 3 of the main paper, we provided additional trajectories in the Appendix B (Fig. 8). Specifically, Fig. 8 illustrates client trajectories within the FBPs for different scenarios, including an Inverted Loss attack on the Synthetic dataset and a Data Flip attack on the Diabetes dataset, highlighting the distinct behavioral patterns of clients and attackers in these settings. These trajectories also demonstrate the possibility of identifying clusters of clients with similar data distributions, particularly on the CBP.

How does the method handle IID and non-IID data? Our method is robust in both IID and challenging non-IID scenarios, demonstrating higher accuracy in IID settings across most conditions. Please note that in the main paper, we conducted all experiments in non-IID scenarios (Section 4.1), which are the most realistic yet challenging for robust aggregation methods, as even honest clients behave differently. Additionally, we compared the performance of our defense method under No-attack, Crafted-noise, Inverted-gradient, Label-flipping, and Inverted-loss attacks in both IID and non-IID settings. The table below shows that higher accuracy is achieved in the IID setting under almost all conditions compared to the non-IID setting, highlighting the increased complexity of operating in non-IID environments (Appendix B).