Paper: PlugVFL: Robust and IP-Protecting Vertical Federated Learning against Unexpected Quitting of Parties (ICLR-2024)

Reviewer comment (Experiments):
In §5.1, the authors briefly discuss a "naive" alternative to their approach of ensuring robustness in case of the second party quitting. This alternative, which is described as fine-tuning the head model after the passive party quits, is dismissed as time-consuming and impractical. However, it would be interesting to see how many training iterations are actually necessary (when shifting all training iterations where the passive party's representation is set to 0 till after the point when the passive party quits) until the model reaches accuracy that is somewhat similar to the case where the proposed mitigation is applied; especially when using small p, the required time to take the service offline might be very small.

Author response:
**W2&Q2**. Thanks for the constructive comment. Notably, sometimes the passive party quits temporarily due to the network crash without any warning. The active party still needs to provide decent services after a party quits, but finetuning the head model requires time and causes communication overhead, and the low performance before the completion of the finetuning is unacceptable. We target that the active party can continue providing high-quality services after a party quits without any shut-down period. In addition, even if finetuning is acceptable, our framework can reduce the time and communication cost of finetuning with a higher start accuracy. As suggested by the reviewer, we conduct experiments on CIFAR100, and the results show that finetuning the head model of the vanilla VFL requires more than 15 epochs to achieve an accuracy higher than 34\%, while finetuning the head model of our method (p=0.1) only requires 3 epoch to achieve the same accuracy, which reduces the time cost significantly by 5 times.

Reviewer comment (Experiments):
The work is somewhat limited in studying only a two-party setting where the accuracy drop as a direct consequence of the only other party quitting is obviously the strongest. This is somewhat fine since also many related works on VFL are restricted to the two-party case, which is also realistic in real-world settings. Nevertheless, a discussion on the likely impact of unexpected quitting of one party in a, e.g., five-party scenario would be appreciated.

Author response:
**W3.&Q3**. When there are more parties, our drop-out method will reduce the computational cost more compared with the multi-head training. To conduct multi-head training, the active party must compute all the terms in Equation 3, and the number of the terms in Equation 3 will increase rapidly when there are more parties. For the accuracy drop, it depends on the uniqueness and importance of the data provided by the passive party. It is reasonable that if a passive party’s data is more important, then the quitting of this party will cause worse performance degradation.  

We thank the reviewer for pointing it out and we will include the discussion in the final version.

Reviewer comment (Presentation):
In Figure 1, it is unclear which information the active party provides to the passive party for it to carry out the IP leakage attack.

Author response:
**W4**. We will refine Figure 1 in the final version. The active party will not “actively” provide any information to the passive party, and the feature extractor held by the passive party that was trained collaboratively with the active party’s labels is the only requirement for the passive party to conduct an IP leakage attack.

Reviewer comment (Presentation):
The authors have clearly answered all my questions. However, I think the fact that the IP leakage issue is not actually related to the passive party dropping out is a major flaw in the presentation of the work and would require a major revision to fix.

Author response:
Thanks for the reviewer's reply. Technically, the passive party does not have to conduct the attack after dropping out, and the same leakage could occur while the party is still online. The goal of our system is to make the passive party pluggable, which means that the active party does not need to put much additional effort into enhancing privacy and preserving the performance when the passive party quits. Thus, even though the active party's label IP leakage is not technically caused by the unexpected quitting, such leakage is the potential problem that the active party has to consider when the passive party quits the collaboration.

We agree with the reviewer that such label leakage is not technically limited to quitting, and our defense can also protect the IP leakage when the passive party is still online. We will include this point in our discussion.

Reviewer comment (Theory):
Is the IP leakage issue related to passive drop-outs at all?

Author response:
Thanks for the reviewer's reply. Technically, the passive party does not have to conduct the attack after dropping out, and the same leakage could occur while the party is still online. The goal of our system is to make the passive party pluggable, which means that the active party does not need to put much additional effort into enhancing privacy and preserving the performance when the passive party quits. Thus, even though the active party's label IP leakage is not technically caused by the unexpected quitting, such leakage is the potential problem that the active party has to consider when the passive party quits the collaboration.

We agree with the reviewer that such label leakage is not technically limited to quitting, and our defense can also protect the IP leakage when the passive party is still online. We will include this point in our discussion.

Reviewer comment (Evaluation):
Can you clarify if the "naive" alternative to robustness discussed in §5.1 is really impractical?

Author response:
**W2&Q2**. Thanks for the constructive comment. Notably, sometimes the passive party quits temporarily due to the network crash without any warning. The active party still needs to provide decent services after a party quits, but finetuning the head model requires time and causes communication overhead, and the low performance before the completion of the finetuning is unacceptable. We target that the active party can continue providing high-quality services after a party quits without any shut-down period. In addition, even if finetuning is acceptable, our framework can reduce the time and communication cost of finetuning with a higher start accuracy. As suggested by the reviewer, we conduct experiments on CIFAR100, and the results show that finetuning the head model of the vanilla VFL requires more than 15 epochs to achieve an accuracy higher than 34\%, while finetuning the head model of our method (p=0.1) only requires 3 epoch to achieve the same accuracy, which reduces the time cost significantly by 5 times.

Reviewer comment (Experiments):
How does the impact of drop-outs behave as a function on the number of passive parties? So is the presented accuracy drop also critical when one passive party in a, e.g., five-party setting drops out?

Author response:
**W3.&Q3**. When there are more parties, our drop-out method will reduce the computational cost more compared with the multi-head training. To conduct multi-head training, the active party must compute all the terms in Equation 3, and the number of the terms in Equation 3 will increase rapidly when there are more parties. For the accuracy drop, it depends on the uniqueness and importance of the data provided by the passive party. It is reasonable that if a passive party’s data is more important, then the quitting of this party will cause worse performance degradation.  

We thank the reviewer for pointing it out and we will include the discussion in the final version.

Reviewer comment (Evaluation):
Why is the evaluation in Table 3 only till p = 0.5; what happens in cases with high drop-out probability?

Author response:
**Q4**. It is unusual for the active party to rely more on the passive party than itself (I.e., by setting $p>0.5$). When $p$ is larger than 0.5, the accuracy before the passive party quits will converge to the accuracy of the Standalone accuracy of the passive party (i.e., p=1). However, we do not think it is a common case to set $p$ larger than 0.5.

Reviewer comment (Experiments):
The experiment data is based on the CIFAR dataset, and only split into two parties, one as active party and the other as passive party. Less than 1% (400) of the labeled data is used to fine-tune the model to perform a model completion attack, achieving comparable accuracy (~1% drop) compared to classifiers trained with all data just in part 2. Only two parties and only one experiment are included, so complexity is not guaranteed in larger and more complex federated tasks.

Author response:
We thank the reviewer for the benevolent reviews!  

We appreciate the reviewer thinks PlugVFL has **strong contributions** with good performance and the acknowledgement that we are the first to study the problem.  

We will answer the reviewer’s questions and concerns here one by one.  

We summarize the reviewer’s concerns into three major points.  

1. Experiments are limited to two-party experiments on CIFAR datasets.  

Notably, different from HFL, VFL does not have many parties. We follow previous works [1,2,3] to conduct experiments in the two-party scenario, which is widely used in the VFL community. 

We appreciate the reviewer’s suggestion about the datasets. We conduct experiments on the UCI_credit_card dataset [4] for the prediction of the default of credit card clients. We follow FATE [2] to assign ten attributes to one party and the rest to the other party. Due to the limited time, we currently can only report the results of the accuracy preservation against unexpected quitting, which are shown below:

|  | Accuracy before party 2 quits (%)  | Accuracy after party 2 quits (%)  |
|----------|----------|----------|
| Vanilla VFL     | 77.25 |74.22    |
| Standalone | N/A | 75.73    |
| Multi-head training | 76.57 | 75.24    |
|Ours (p=0.1) | 77.45 | 76.26 |
|Ours (p=0.3) | 77.64 | 76.34 |
|Ours (p=0.5) | 77.47 | 76.61 |

It is shown that our framework is also effective in preserving the accuracy against the unexpected quitting on categorical datasets. We will include more results of this dataset in the revision.

Reviewer comment (Experiments):
The paper mentions naive solutions for mitigating the accuracy drop, such as fine-tuning the head model after a passive party quits. To actually apply this method and get the accuracy result would be more convincing, because it is possible that this method could be better than the method proposed by the paper.

Author response:
We thank the reviewer for the benevolent reviews!  

We appreciate the reviewer thinks PlugVFL has **strong contributions** with good performance and the acknowledgement that we are the first to study the problem.  

We will answer the reviewer’s questions and concerns here one by one.  

We summarize the reviewer’s concerns into three major points.  

3. Fine-tuning the head model as baselines.  

Notably, the passive party sometimes quits temporarily due to the network crash without warning. The active party still needs to provide decent services after a party quits, but finetuning the head model requires time and causes communication overhead, and the low performance before the completion of the finetuning is unacceptable. We target that the active party can continue providing high-quality services after a party quits without any shut-down period. In addition, even if finetuning is acceptable, our framework can reduce the time and communication cost of finetuning with a higher start accuracy. We conduct experiments on CIFAR100, and the results show that finetuning the head model of the vanilla VFL requires more than 15 epochs to achieve an accuracy higher than 34\% while finetuning the head model of our method (p=0.5) only requires 1 epoch to achieve the same accuracy, which reduces the cost significantly.

Reviewer comment (Theory):
In federated learning, the label is counted as IP protection and considered valid because the label has useful representation that the passive model can extract. The logic is that passive parties normally will only have access to the representation extractors, which allow them to fine-tune classifier heads with very few labeled data. However, how is the difference of label type defined? Different label data types could have different presentations, and it is unclear how to ensure generalization beyond text labels. If the only representation that could be extracted is numeric matching, then it may not qualify for IP protection.

Author response:
We answer the reviewer’s questions here:  

**Q1**. Thanks for the constructive suggestion. To prove the generalization of our defense to different label types, we derive a theoretical robustness guarantee for our defense: 

**Theorem 1**. Let $g_{\psi}$ parameterize $q_{\psi}$ in Eq. 5. Suppose the passive party optimizes an auxiliary model $f^m(y|h^2)$ to estimate $p(y|h^2)$. For any $f^m$, we have: 

$\frac{1}{N}\sum\limits_{i=1}^N \log f^m(y_i|H^2_i) < \frac{1}{N}\sum\limits_{i=1}^N \log p(y_i) + \epsilon, $

where 

$\epsilon = {I_{vCLUB} {g_\psi}}(h^2;y) + KL(p(y|h^2)||g_\psi(y|h^2)). $


  

Notably, this theorem does not set any constraints or assumptions on the type of label. Specifically, if the task of collaborative inference is classification, we have the following results: 

$\frac{1}{N}\sum\limits_{i=1}^N\text{CE}\left[f^m(H^2_i), y_i\right] > CE_{random} - \epsilon, $

  

where CE denotes the cross-entropy loss, $\text{CE}_{random}$ is the cross-entropy loss of random guessing. 

Such a theorem can prove the effectiveness of our defense under all types of labels.

Reviewer comment (Theory):
Regarding reducing co-adaptation of the hidden neurons of the head predictor, similar to dropout, why would setting p = zero still result in accuracy after party 2 quits? Based on the definition, in each communication p will be zero, therefore making the model equivalent to calculating prediction performance.

Author response:
We answer the reviewer’s questions here:  

**Q2**. p=0 serves as a baseline reference, which is equivalent to vanilla VFL. In our final implementation and results shown in Figure 6, p is set as 0.5. As written in Eq. 3, when party 2 quits, we use zero vectors as the features from party 2.

Reviewer comment (Theory):
The link between the IP leakage issue and the deployment-time passive party dropping is not clear. The paper seems to conflate the solution to two unrelated problems. The "Active Model Completion (AMC)" is based on training time, which contradicts the deployment-time scenario.

Author response:
Specific response for **W1**. The AMC attack is employed by the passive party who quits from the collaboration at the inference stage to infer the label of the samples in the inference phase. AMC is very suitable for the passive party to acquire the label information with the feature extractor obtained from the collaboration in the deployment phase.

Reviewer comment (Experiments):
The discussion of party dropping only considers two parties with limited evidence (CIFAR-10). The impact on more parties should be explored.

Author response:
For the performance preservation against unexpected quitting, we conduct experiments with more than two parties. Due to the limited time, we can only have a part of the results of UCI_credit_card with three parties.

|  | Accuracy before any party quits (%)  | Accuracy after party 3 quits (%)  | Accuracy after party 2&3 quit (%) 
|----------|----------|----------|----------|
| Vanilla VFL     | 77.18| 74.32| 72.73   |
|Ours (p=0.1) | 77.36|76.36|75.68 |
|Ours (p=0.3) | 77.50|76.50|76.02 |
|Ours (p=0.5) | 77.43|76.58|76.18 |

It is shown that when there are more parties quitting, the accuracy drop will be more serious. Our method can still preserve the accuracy after quitting well. We will run the experiments with three parties on CIFAR datasets and include the results in the revised paper.

Reviewer comment (Theory):
The paper states that IP leakage is due to label information, supporting the design of mutual information regularization. However, the connection between IP leakage and label information is not well-established. Section 3.3 suggests that IP leakage is primarily about successful model completion, not direct extraction of labels from the active party. A counter-example is that a feature extractor can be learned without label information (i.e., unsupervised learning).

Author response:
Specific response for **W4**. In the VFL scenario, usually it is a collaboration between two big companies, where one of the companies (referred to as the active party) spends money, labor and their own techniques to annotate the data to acquire the label information. Hence, the label information represents the intellectual property of the active party. Unsupervised learning is applicable when the data have enough information infer the label. However, in VFL settings, the data of one party do not contain enough information to train a well performed feature extractor independently, which is also the motivation of VFL. Thus, the feature extractor trained in VFL will contain the label information, which is the important IP of the active party.

Reviewer comment (Experiments):
The scalability of the alternative training for multi-party cases is questionable. For instance, in a 3-party scenario, the performance should remain consistent in multiple cases (both passive party drops or either one party drops). The equation in Section 3 could be split into four, increasing computation overhead significantly.

Author response:
Specific response for W5. In the implementation, we adopt a mask that randomly mask the features from passive parties, and we do not need to compute all the terms in Equation 3 for each iteration. Hence the computational overhead remains the same for different number of passive parties. The loss function in Equation 3 represents the expectation of the loss function we actually computes.

Reviewer comment (Experiments):
The hyperparameter p setting for alternative training is debatable. Estimating the probability of dropping during training is challenging. The paper mentions that setting a relatively small p-value can improve the robustness of VFL. However, does this imply that the scheme should always set a small p?

Author response:
**W6**. A small p leads to good joint performance while a large p leads to good robustness against unexpected quit. The selection should depend on the trade-off between joint performance and the trustworthiness of the collaborator. Our focus is to provide the companies in the VFL system a feasible solution to improve the robustness against the unexpected quitting. Estimating the p value for each party will be very interesting in real life, and it is not always about the technics. Sometimes it might also be related to the risk and cost control. For example, if a passive party will pay higher Liquidated Damages for the quitting, we should set a higher $p$ for this passive party, since they can pay more compensation for the loss of service degradation. Even though this is out of the scope of this paper, we will include this discussion in our revised paper.

Reviewer comment (Theory):
There are inaccuracies in some statements, such as the assumption that "the service provider cannot afford to shut down the service while fine-tuning." In reality, the server could have a backup model to replace the running one without service disruption. Additionally, the statement, "Without loss of generality, we formulate our PlugVFL framework in the two-party scenario," should ideally be demonstrated in more than two-party scenarios, enabling downgrading to two-party scenarios.

Author response:
Specific response for **W3** and **W7**. We are proposing methods with minimal costs. The multi-head training will introduce extra computational overhead, as discussed in section 5.1 second last paragraph. And training a backup model from scratch will introduce extra costs. For reference purposes, to train a GPT-3 requires $450,000 in 2022, not to mention in VFL scenarios the communication costs are also tremendous.  

We will rephrase our statements accordingly.

Reviewer comment (Experiments):
Is there a naive way to mitigate performance degradation when a party drops? For example, could setting a mean vector value instead of zero help?

Author response:
**Q1**. We thank the reviewer for the constructive suggestions on further baselines, Notably, it is not always feasible for the active party to collect the passive parties’ features and calculate the mean vectors due to privacy concern. However, we still conduct experiments to illustrate the accuracy of using the mean vectors on CIFAR10 and CIFAR100. The results are shown below: 

Cifar10: 

Accuracy before quitting: 74.62\%   Accuracy after quitting using zero vectors: 53.04\%  Accuracy after quitting using mean vectors: 52.19\% 

Cifar100: 

Accuracy before quitting: 44.95\%   Accuracy after quitting using zero vectors: 26.65\%  Accuracy after quitting using mean vectors: 25.33\% 

 

It is shown that using the mean vectors does not improve the accuracy after quitting, and the accuracy is even lower. We analyze that the reason is the mean vectors contain information of the passive party, but such information does not correspond to the test samples and might confuse the classifier on the active party.

Reviewer comment (Experiments):
Image classifications like CIFAR-10/CIFAR-100 may not be ideal examples of VFL tasks. Is this framework effective on categorical datasets?

Author response:
**Q2**. We appreciate the reviewer’s suggestion about the datasets. We conduct experiments on the UCI_credit_card dataset [4] for the prediction of the default of credit card clients. We follow FATE [2] to assign ten attributes to one party and the rest to the other party. Due to the limited time, we currently can only report the results of the accuracy preservation against unexpected quitting, which are shown below: 

|  | Accuracy before party 2 quits (%)  | Accuracy after party 2 quits (%)  |
|----------|----------|----------|
| Vanilla VFL     | 77.25 |74.22    |
| Standalone | N/A | 75.73    |
| Multi-head training | 76.57 | 75.24    |
|Ours (p=0.1) | 77.45 | 76.26 |
|Ours (p=0.3) | 77.64 | 76.34 |
|Ours (p=0.5) | 77.47 | 76.61 |

It is shown that our framework is also effective in preserving the accuracy against the unexpected quitting on categorical datasets. We will include more results of this dataset in the revision.

Reviewer comment (Experiments):
The experiments are not well designed.

Author response:
Firstly, we would like to thank the reviewer for the acknowledgement of the meaningfulness of the problem we are studying. It is encouraging! However, we politely disagree with the reviewer’s comments that our experiments are not well designed, and we answer the reviewer's questions one by one.

Reviewer comment (Presentation):
Fig. 3 and 6 plot the relationships between the test acc before party 2 quit and after party 2 quit, while Fig. 4 and 5 plot the relationships between the test acc and attack acc. Do they share the same hyper-paramters? What do the lines (which connect the points) mean? I do not get the meanings and reasons of the figures.

Author response:
Q1. Figure 3 plots the relationship between test acc before party 2 quits and after party 2 quits. As stated in the title of section 5.1, these two figures are measuring the accuracy drops (also known as the performance preservation ability). Stated in the second sentence in section 5.1, lines demonstrate the trends of the trade-off between accuracy before and accuracy after the quit with different level of defense. The best trade-off is achieved at the top-right corner.  

Meanwhile, Figures 4 and 5 measure the defense ability against label leakage, as stated in the title of section 5.2. In the first sentence of section 5.2, we specify the changes in the hyper parameter p=0, while all other hyperparameter remains the same and detailed in the Hyperparameter configurations. paragraph in section 5. As stated in the second sentence in section 5.2, Figures 4 and 5 measure the trade-off between attack accuracy and test accuracy under different level defense. The Evaluation metrics. paragraph specifies our definition of the evaluation metrics.  

Figure 6 is results for the joint performance under the best trade-off we observed from previous sections, as stated in section 5.3, the third sentence.

Reviewer comment (Evaluation):
From Table 3, PlugVFL shows worse results than simply training independently. So does the proposed method make sense?

Author response:
Q2. When training independently, the active party achieves slightly higher accuracy compared with the accuracy of VFL after quitting. However, independent training does not allow the active party to utilize the passive party’s data and suffers from low accuracy before the passive party quits, which degrades the accuracy from 5% to 10%. Notably, it is also usually impractical and impossible to train independently. The company that deploys the system cannot afford the cost to shut down the service and retrain the model. The above discussion can found in last two paragraphs in section 5.1.