Decoupled Subgraph Federated Learning

We appreciate the reviewer’s thoughtful comments and address them in detail below. If our responses satisfactorily address the reviewer’s concerns, we would be grateful if they would consider adjusting their score accordingly.

Weakness 1: We sincerely thank the reviewer for their thorough analysis and for highlighting the potential confusion surrounding Equations (30), (31), and (32) in the paper. We confirm that the symbol $K$ should indeed be replaced by $k$, which represents the client index in these equations. Additionally, the dimensions of $\boldsymbol{\tilde{A}}^{[i]}_j$ and $\boldsymbol{\hat{A}}^{[i]}_j$ are $\vert\mathcal{V}_i\vert \times \vert\mathcal{V}_j\vert$, as noted. We have incorporated these corrections in the revised paper.

To clarify how our privacy-preserving scheme works in practice (i.e., to show how each client obtains its local partition of L-hop combined adjacency matrix without sharing the L-hop global adjacency matrix), we start by outlining the information accessible to each client $i \in [K]$ at the outset:

Each client $i$ has access to:

• $\\boldsymbol{\\tilde{A}}^{[i]}_j \\in \\mathbb{R}^{\\vert\\mathcal{V}_i\\vert \\times \\vert\\mathcal{V}_j\\vert}$ for all $j \\in [K]$ : representing the outgoing edges from client $i$ to client $j$ .

• $\\boldsymbol{\\tilde{A}}^{[j]}_i \\in \\mathbb{R}^{\\vert\\mathcal{V}_j\\vert \\times \\vert\\mathcal{V}_i\\vert}$ for all $j \\in [K]$ : representing the incoming edges from client $j$ to client $i$ .

Using $\boldsymbol{\tilde{A}}^{[i]}_j$, Client $i$ can compute both the degree matrix $\boldsymbol{\tilde{D}}^{[i]}$ and the normalized adjacency matrix $\boldsymbol{\hat{A}}^{[i]}_j$ for all $j \in [K]$ .

By induction, we can demonstrate that if each Client $i$ has access to $[\boldsymbol{\hat{A}}^{[i]}_j]^{\ell - 1}$ for all $j \in [K]$ , they can collaborate with each other to compute $[\boldsymbol{\hat{A}}^{[i]}_j]^{\ell}$ without accessing the global matrix. Here’s a step-by-step breakdown:

1. Base case: For $\ell = 1$ , we have $[\boldsymbol{\hat{A}}^{[i]}_j]^{1} = \boldsymbol{\hat{A}}^{[i]}_j$, which is available to Client $i$ from the start for all $j \in [K]$ .

2. Inductive step: Suppose each Client $i$ knows $[\boldsymbol{\hat{A}}^{[i]}\_j]^{\ell - 1}$ for all $j \in [K]$. Then, Client $k$ can compute the intermediate term $\boldsymbol{B}\_{ijk} = \boldsymbol{\tilde{A}}^{[i]}\_k [\boldsymbol{\hat{A}}^{[k]}\_j]^{\ell-1}$ for all $j \in [K]$ (since it knows $[\boldsymbol{\hat{A}}^{[k]}\_j]^{\ell - 1}$ and $\boldsymbol{\tilde{A}}^{[i]}\_k$ for all $i,j \in [K]$) and share it with Client $i$.
   Notice that Client $i$, by receiving $\boldsymbol{B}_{ijk}$,cannot reconstruct $[\boldsymbol{\hat{A}}\_j^{[k]}]^{\ell-1}$ due to the low rank nature of $\boldsymbol{\tilde{A}}\_k^{[i]}$. Moreover, Client $k$ also prunes $\boldsymbol{B}\_{ijk}$ to remove any concerns. Client $i$ can then compute $[\boldsymbol{\hat{A}}^{[i]}\_j]^{\ell}$ by

$

[\boldsymbol{A}_j^{[i]}]^l = (\boldsymbol{\tilde{D}}^{[i]})^{-1} \sum_{k\in [K]}{\boldsymbol{B}_{ijk}}.

$

This summation allows Client $i$ to update its local adjacency matrix without requiring the entire global adjacency matrix.

At each step $\ell$, Client $i$ only accesses $[\boldsymbol{\hat{A}}^{[i]}\_j]^{\ell}$ forall $j \in [K]$ without learning the entire global matrix $[\boldsymbol{\hat{A}}]^{\ell}$. Furthermore, if additional security is required, the summation over $\boldsymbol{B}_{ijk}$ can be performed on a secure server using homomorphic encryption.

We hope this explanation clarifies the feasibility and privacy mechanisms of FedStruct. In response to your comment, we have also provided a more detailed explanation in Appendix D of the paper to address this point thoroughly. We appreciate your detailed feedback, which has helped strengthen our manuscript.

I have known all details of my questions and I keep my rating to this submission.

We appreciate the reviewer’s thoughtful comments and address them in detail below. If our responses satisfactorily address the reviewer’s concerns, we would be grateful if they would consider adjusting their score accordingly.

Weakness 1:

Thank you for your comment. In response, we will revise the abstract accordingly in the final version of the paper, if accepted, to better address your feedback. However, due to the page limit constraints in this submission (which are relaxed for accepted papers), we are unable to modify the abstract within this response.

Here is the revised abstract that we plan to include in the final version of the paper if accepted:

Many real-world data are inherently graph-structured. In practice, such graph data is often distributed across multiple clients, each holding private subgraphs, as in transaction networks. Direct data sharing is typically restricted due to privacy concerns, regulatory constraints, and proprietary limitations. Federated learning (FL) provides a promising solution by enabling collaborative model training without exposing raw data. However, in subgraph federated learning (SFL), where clients possess non-overlapping subgraphs and there are interconnections between subgraphs, such as in transaction networks, effective model training is challenging due to privacy constraints.

This paper introduces FedStruct, a novel SFL framework designed to tackle this challenge. To uphold privacy, unlike existing methods, FedStruct eliminates the necessity of sharing or generating sensitive node features or embeddings among clients. Instead, it leverages explicit global graph structure information to capture inter-node dependencies. We validate the effectiveness of FedStruct through extensive experimental results conducted on six datasets for semi-supervised node classification, showcasing performance close to the centralized approach across various scenarios, including different data partitioning methods, varying levels of label availability, and number of clients.

Weakness 2:

We thank the reviewer for the comment. We actually cited Figure 1 in the introduction section, Page 2, line 89 as "Fig. 1". We have changed the wording to "Figure 1" to remove the confusion.

We also modified Figure 2 in the paper to make it clearer.

Weakness 3:

To clarify, note that FedStar is not a subgraph FL method but rather a graph classification method that utilizes structural information to improve the performance of graph classification. Prior research has shown that explicitly incorporating structural information can improve GNN performance.

A key novelty of our paper is the use of explicit structural information within an SFL framework, specifically to improve subgraph federated learning accuracy and enhance privacy. We also introduce a new structure embedding method, Hop2vec, designed to capture these structural dependencies effectively.

In this paper, we use "structural knowledge" and "structural information" interchangeably, with no intended difference in meaning. To avoid any ambiguity, we have rephrased the last sentence of the related work section to consistently use ``structural information'' and avoid the term "structural knowledge."

Weakness 4:

We thank the reviewer for bringing this to our attention. We have added a comma and checked all other equations so that they are consistent with this style.

Weakness 5:

We appreciate your feedback. Our scheme provides enhanced privacy compared to existing approaches, as it significantly reduces the amount of shared information among clients.

While it is straightforward to identify schemes that lack privacy entirely (for instance, previous solutions that share node features or embeddings, as well as FedGCN, where clients access aggregated node features of other clients (thus breaching privacy), and the server requires access to the global adjacency matrix), precisely quantifying the privacy level of a scheme like FedStruct remains very challenging. Developing a mathematical measure or bounds for privacy in subgraph federated learning, federated learning more broadly, and even general machine learning is an open problem that is still being researched. Although we are actively working on establishing privacy bounds for FedStruct, these results are part of our ongoing research and therefore outside the scope of the current paper.

In Appendix G.1, we discuss the privacy properties of FedStruct, following an approach similar to [1] (FedCog), to provide insights into the privacy considerations of our scheme.

[1] Lei, R., Wang, P., Zhao, J., Lan, L., Tao, J., Deng, C., Feng, J., Wang, X. and Guan, X., 2023. Federated learning over coupled graphs. IEEE Transactions on Parallel and Distributed Systems, 34(4), pp.1159-1172.

We wanted to kindly follow up on the discussion regarding our paper.

We noticed that we have not yet received a response to our comments addressing your valuable feedback. We believe we have addressed your concerns thoroughly and would greatly appreciate any additional thoughts or input you may have. Thank you again for your time and effort in reviewing our work. We look forward to hearing from you and are happy to provide any further clarifications if needed.

We appreciate the reviewer’s thoughtful comments and address them in detail below. If our responses satisfactorily address the reviewer’s concerns, we would be grateful if they would consider adjusting their score accordingly.

Weakness 1:

The scheme for obtaining the local partitions of the $L$-hop combined adjacency matrix $\boldsymbol{\bar{A}}^{[i ]}$ is designed specifically to ensure that no client has access to the entire $\ell$-hop ($\ell\in[1,\ldots, L]$) adjacency matrix $\boldsymbol{\hat{A}}^\ell$. Also, due to the low-rank nature of the adjacency matrix, reconstructing the unknown entries is not possible.

We realize that our explanation of this mechanism may not have been sufficiently clear in the paper, and we appreciate your comment, which will allow us to improve the clarity of the paper.

Below, we provide a more detailed explanation and outline the improvements we plan to incorporate into the paper to address this point effectively, following your comment.

To illustrate our algorithm and its privacy mechanism, we provide an example to compute the 2-hop combined adjacency matrix, denoted as $\boldsymbol{\bar{A}}$.

Consider a graph with 9 nodes, partitioned across 3 clients, given by the following adjacency matrix:

$

\mathbf{A} = \begin{bmatrix} 0 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 1 & 0 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 1 & 1 & 1 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 1 & 1 & 0 \\ \end{bmatrix}

$

where each entry $A_{ij} = 1$ indicates a connection between nodes $i$ and $j$, and $A_{ij} = 0$ indicates no connection.

Clients are assigned subsets of nodes: Client 1 has nodes 1, 2, and 3; Client 2 nodes 4, 5, and 6; and Client 3 has nodes 7, 8, and 9.

Each client has information about its internal nodes and connections. Furthermore, it knows the incoming and outgoing connections between its internal nodes and nodes located in other clients. Hence, client $i$ knows a subset of the global adjacency matrix $\mathbf{A}$, called $\boldsymbol{\tilde{A}}^{[i]}$, corresponding to the connections between its own nodes and to some nodes in other clients. In particular, Client 1 knows

$\text{internal connections (including self loops): } \boldsymbol{\tilde{A}}\_1^{[1]} = \begin{bmatrix} 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ \end{bmatrix}$

$\text{outgoing connections: } \boldsymbol{\tilde{A}}\_2^{[1]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}\_3^{[1]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ \end{bmatrix}$

$\text{incoming connections: } \boldsymbol{\tilde{A}}\_1^{[2]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}\_1^{[3]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ \end{bmatrix}.$

Similarly, Client 2 knows

$\text{internal connections (including self loops): } \boldsymbol{\tilde{A}}\_2^{[2]} = \begin{bmatrix} 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ \end{bmatrix}$

$\text{outgoing connections: } \boldsymbol{\tilde{A}}\_1^{[2]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}_3^{[2]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}$

$\text{incoming connections: } \boldsymbol{\tilde{A}}_2^{[1]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}_2^{[3]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}$

and Client 3 knows

$\text{internal connections (including self loops): } \boldsymbol{\tilde{A}}\_3^{[3]} = \begin{bmatrix} 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ 1 & 1 & 1 \\\\ \end{bmatrix}$

$\text{outgoing connections: } \boldsymbol{\tilde{A}}\_1^{[3]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}\_2^{[3]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}$

$\text{incoming connections: } \boldsymbol{\tilde{A}}\_3^{[1]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ \end{bmatrix}\quad \boldsymbol{\tilde{A}}\_3^{[2]} = \begin{bmatrix} 0 & 0 & 0 \\\\ 0 & 0 & 0 \\\\ 0 & 0 & 1 \\\\ \end{bmatrix}$

Using $\boldsymbol{\tilde{A}}^{[i]}\_j, j =1,2,3$, Client $i$ can compute both the degree matrix $\boldsymbol{\tilde{D}}^{[i]}$ and the normalized adjacency matrix $\boldsymbol{\hat{A}}^{[i]}_j$ for all $j \in [K]$. For simplicity, we assume that $\boldsymbol{\tilde{A}}^{[i]}\_j = \boldsymbol{\hat{A}}^{[i]}\_j\quad \forall i,j \in [K]$ in this example, as they differ only by a normalization constant.

Weakness 2:

As discussed in our paper, any subgraph federated learning (SFL) method should be evaluated by balancing the communication-privacy-accuracy trilemma. At one extreme, disregarding communication and privacy concerns entirely would mean transmitting all node features and connections to a central server, where a centralized GNN could achieve high accuracy. Conversely, focusing solely on privacy and communication cost would result in each client training a local model in isolation, yielding poor performance. Thus, an effective SFL framework must strike a careful balance to achieve good performance while minimizing privacy leakage and reducing communication cost.

FedGCN is not a private framework, as it involves sharing aggregated node features across clients (aggregating node features does not provide privacy, as recently shown in [1]). This privacy leakage is exacerbated by the structured nature of node feature vectors, where each entry has a meaningful value. For instance, in the Cora dataset, each node (a paper) is represented by a 1,433-dimensional binary vector, where each entry indicates the presence or absence of a specific word in the paper (node). As a result, even receiving the summation of several vectors can enable a client to infer individual entries in other clients’ node features.

In the 2-hop FedGCN, each node is also required to send its list of neighbors to external neighbors (neighbors located on other clients) to compute the necessary summations. This process is detailed in Equation 3 on page 5 of the FedGCN paper (we elaborate more on this in the answer to your Weakness 3).

While Fedsage+ provides more privacy than FedGCN, it still involves sharing node feature embeddings with other clients, which makes it less private than FedStruct. Fedsage+ slightly outperforms FedStruct only on the Amazon Photo dataset, with a difference of approximately $1\\%$. On the other 5 datasets, however, FedStruct significantly outperforms Fedsage+. For example, for Cora and Chameleon, the improvement is $14\\%$ and $13\\%$, respectively.

Also, as shown in Table 2, methods like FedSGD, which do not leverage interconnections between clients, already perform close to a centralized approach on Amazon Photo, leaving little room for improvement. Consequently, for this dataset, the advantage of utilizing external nodes is less pronounced compared to other datasets.

Weakness 3:

Thank you for your comment. We recognize the need to clarify this aspect further.

In the FedGCN scheme, as detailed in Equation 3 on page 5 of the FedGCN paper, to calculate $\boldsymbol{\hat{y}}_i$, the following information must be sent to the server by Client $z$:

$

\begin{cases} \boldsymbol{h}_{zi} = &\sum_{j \in \mathcal{N}_i}{\mathbb{I}_z(c(j)) \boldsymbol{A}_{ij} \boldsymbol{x}_j}\\ \boldsymbol{h}_{zj} = &\sum_{m \in \mathcal{N}_j}{\mathbb{I}_z(c(m)) \boldsymbol{A}_{jm} \boldsymbol{x}_m} \quad \forall j \in \mathcal{N}_i \setminus i. \end{cases}

$

Once the server obtains $\boldsymbol{h}\_{zj}$ for all clients $z\in [K]$, it calculates the aggregate $\boldsymbol{h}\_{j} = \sum\_{z\in [K]} \boldsymbol{h}\_{zj}$ and forwards this result to the client where node $i$ resides. However, as $\boldsymbol{h}\_{j}$ is a quantity pertaining to node $j$, the server must know that $i$ and $j$ are connected. Similar arguments hold for all other nodes. Hence, the server needs access to the global adjacency matrix for this scheme to work with 2 hops.

To clarify this point in response to your comment, we have provided this explanation in Appendix C.4 of the paper and referenced it in the main text (Line 460).

[1] Ngo, K.H., Östman, J., Durisi, G. and Graell i Amat, A., 2024, August. Secure Aggregation Is Not Private Against Membership Inference Attacks. In Joint European Conference on Machine Learning and Knowledge Discovery in Databases (pp. 180-198). Cham: Springer Nature Switzerland.

Weakness 1 (Part 2):

Following Equation 32 in the paper, we define the intermediate matrix $\boldsymbol{B}_{ijk} = \boldsymbol{\tilde{A}}^{[i]}_k \boldsymbol{\hat{A}}^{[k]}_j$. The following steps outline the remaining computations:

1. Calculating $\boldsymbol{B}\_{ijk}$

Client $1$ calculates $\boldsymbol{B}\_{211},\, \boldsymbol{B}\_{221},\,\boldsymbol{B}\_{231}$ as follows

$

\boldsymbol{B}_{211} = \begin{bmatrix} 0 & 0 & 1 \\ 0 & 0 & 1 \\ 0 & 0 & 1 \\ \end{bmatrix}\quad \boldsymbol{B}_{221} = \begin{bmatrix} 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 1 \\ \end{bmatrix}\quad \boldsymbol{B}_{231} = \begin{bmatrix} 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 0 \\ \end{bmatrix}

$

Client 1 sends these matrices to Client $2$. Notice that Client $2$, by receiving $\boldsymbol{B}\_{211},\, \boldsymbol{B}\_{221},\,\boldsymbol{B}\_{231}$, cannot reconstruct $\tilde{A}_1^{[1]},\, \tilde{A}_3^{[1]}$ and $\tilde{A}_1^{[3]}$ due to the low-rank nature of the adjacency matrix. Moreover, Client 1 also prunes $\boldsymbol{B}\_{ijk}$ to remove any concern.

Similarly Client $3$ calculates $\boldsymbol{B}\_{213},\, \boldsymbol{B}\_{223},\,\boldsymbol{B}\_{233}$ as

$

\boldsymbol{B}_{213} = \begin{bmatrix} 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 0 \\ \end{bmatrix}\quad \boldsymbol{B}_{223} = \begin{bmatrix} 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 1 \\ \end{bmatrix}\quad \boldsymbol{B}_{233} = \begin{bmatrix} 0 & 0 & 1 \\ 0 & 0 & 1 \\ 0 & 0 & 1 \\ \end{bmatrix}

$

which are sent to the Client $2$ after pruning.

We follow a similar procedure for the other combinations of $\boldsymbol{B}\_{ijk}$, as outlined in Algorithm 3.

2. Calculating $[\boldsymbol{\hat{A}}^{[i]}_j]^{2}$

Upon receiving $\boldsymbol{B}\_{211},\, \boldsymbol{B}\_{221},\,\boldsymbol{B}\_{231}$ and $\boldsymbol{B}\_{213},\, \boldsymbol{B}\_{223},\,\boldsymbol{B}\_{233}$, Client $2$ can compute $[\boldsymbol{\hat{A}}^{[2]}_1]^{2},\,[\boldsymbol{\hat{A}}^{[2]}_2]^{2},\,[\boldsymbol{\hat{A}}^{[2]}_3]^{2}$ as

$

[\boldsymbol{\hat{A}}^{[2]}\_1]^{2} = (\boldsymbol{\tilde{D}}^{[2]})^{-1} 
\left( 
\boldsymbol{B}\_{211} + \boldsymbol{B}\_{212} + \boldsymbol{B}\_{213}
\right)\\\\
[\boldsymbol{\hat{A}}^{[2]}\_2]^{2} = (\boldsymbol{\tilde{D}}^{[2]})^{-1} 
\left( 
\boldsymbol{B}\_{221} + \boldsymbol{B}\_{222} + \boldsymbol{B}\_{223}
\right)\\\\
[\boldsymbol{\hat{A}}^{[2]}\_3]^{2} = (\boldsymbol{\tilde{D}}^{[2]})^{-1} 
\left( 
\boldsymbol{B}\_{231} + \boldsymbol{B}\_{232} + \boldsymbol{B}\_{233}
\right)

$

Note that $\boldsymbol{B}\_{212},\, \boldsymbol{B}\_{222},\,\boldsymbol{B}\_{232}$ can be computed locally in Client $2$. Using the above equations, Client $2$ can update its local 2-hop adjacency matrix without access to the global adjacency matrix. Clients $1$ and $3$ follow the same procedure to compute $[\boldsymbol{\hat{A}}^{[1]}_j]^{2}$ and $[\boldsymbol{\hat{A}}^{[3]}\_j]^{2}$ for each $j \in \{1,2,3\}$, respectively.

This procedure can be extended to any number of hops $\ell$. At hop $\ell$ , Client $i$ only accesses $[\boldsymbol{\hat{A}}^{[i]}\_j]^{\ell}$ for all $j \in [K]$ and does not learn the full global matrix $[\boldsymbol{\hat{A}}]^{\ell}$. Moreover, if additional security is required, the summation over $\boldsymbol{B}\_{ijk}$ could be performed on a secure server using homomorphic encryption.

In response to your comment, we have now added a more detailed explanation in Appendix D to address this point thoroughly. This clarification emphasizes that clients do not have access to the complete $\ell$-hop adjacency matrix.

We wanted to kindly follow up on the discussion regarding our paper.

We noticed that we have not yet received a response to our comments addressing your valuable feedback. We believe we have addressed your concerns thoroughly and would greatly appreciate any additional thoughts or input you may have. Thank you again for your time and effort in reviewing our work. We look forward to hearing from you and are happy to provide any further clarifications if needed.

For weakness 1, since the algorithm needs inter-client communication, the privacy of communicating with multiple clients can be better analyzed.

For weaknesses 2 and 3, in FedGCN, based on the reviewer's reading on the algorithm, since the server calculates the aggregation $h_j$ for each node $j$, the server then just needs to know the belonging of nodes for each client and sends those $h_j$ to clients. It does not need to know the global adj.

The privacy analysis sounds good to me.

As the reviewer mentioned and the authors may also have realized, in FedGCN, instead of broadcasting all embeddings, the server only needs to send the required embeddings without knowing the global adj. The server just needs to know the local node id and the 1-hop node id of each client, where the connection between nodes is unknown.

The reviewer may increase the score if the description on FedGCN can be corrected and the above private analysis with server aggregation can be included in the main paper.

Thank you for recognizing the thoroughness of our privacy analysis. We will incorporate the insights from the reviewer discussion into the final submission. Note, however, that we are unable to make revisions at this stage in the discussion as the deadline for edits has already passed. We would greatly appreciate any consideration for a score adjustment, as it is critical for the final decision.

Given authors did not correct the claim in the camera ready version, I have to decrease my score from 6 to 3.

Although the paper is accepted, the authors still did not correct the misunderstanding of FedGCN in the camera ready version. In FedGCN, instead of broadcasting all embeddings, the server only needs to send the required embeddings without knowing the global adj. The server just needs to know the local node id and the 1-hop node id of each client, where the connection between nodes is unknown.

It is clear that in FedGCN, the server just needs to know the local node id and the 1-hop node id of each client, where the connection between nodes is unknown. https://github.com/FedGraph/fedgraph/blob/74292e3bc6cd28a9052c914d55e380be071e2cb8/fedgraph/federated_methods.py#L270

The authors have clear misunderstanding and are unwilling to modify the paper as promised. It is a serious ethics issue.