Pith. sign in

REVIEW 4 major objections 4 minor 32 references

PRSI: Privacy-Preserving Recommendation Model Based on Vector Splitting and Interactive Protocols

T0 review · 4 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read PRSI claims to let a central server train any recommender on raw interaction data without learning which client produced which vector, while keeping interactions and recommendations hidden from other clients.

desk verdict The central privacy claim fails on the paper's own protocol: clients send directly to the server, so IPs are linkable to interaction vectors; the security experiment only re-confirms the reconstruction identity. read the letter →

arxiv 2411.18653 v1 pith:4C22NM6Z submitted 2024-11-27 cs.CR cs.AI

Xiaokai Cao , Wenjin Mo , Zhenyu He , Changdong Wang This is my paper · ORCID
classification cs.CRcs.AI
keywords privacy-preservingrecommendationvectorsplittinginteractiveprotocolssecuremultipartycomputingfakeinteractionitemsvirtualIDfederated
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes PRSI, a privacy-preserving recommendation pipeline for the setting where each client holds exactly one user's interaction vector. Its central claim is that vector splitting plus an interactive relay protocol lets the central server collect and reconstruct every user's interaction data and train any standard recommender on it, while the server cannot trace any interaction vector back to the client that sent it and other clients learn nothing about one another's interactions or recommendations. The method pads interaction vectors with fake items, splits them into random pieces, and forwards the pieces through other clients under a probabilistic routing rule; a second phase returns recommendation results along the reverse path. If the claim holds, PRSI would offer a model-agnostic privacy layer that avoids the gradient leakage problems of federated recommendation systems.

What carries the argument

The load-bearing object is the split-vector triple $(V_{\mathrm{ID}}^i, V_i^s, u_{i,1}^*)$: a virtual ID, one of $S_{\mathrm{spl}}$ random vectors with entries in $\{0,1,-1\}$, and the shuffled list of real and fake item indices. Summing the split vectors that share the same virtual ID reconstructs the masked interaction vector exactly, while each individual piece is meant to be useless on its own and the virtual ID is what decouples the data from the sending IP address. The routing rule, an exponentially decaying probability $p_{\mathrm{sto}} \leftarrow p_{\mathrm{sto}} \cdot \alpha$ for forwarding a triple to a peer versus sending it to the server, controls the privacy-communication trade-off, and the locally stored $(V_{\mathrm{ID}}^j, I_{\mathrm{IP}}^j)$ tuples provide the reverse path that lets recommendation results be delivered without broadcasting them.

What would settle it

Run the collection protocol with one adversarial client that accepts every relayed triple and records every $(V_{\mathrm{ID}}^j, I_{\mathrm{IP}}^j)$ tuple, then check whether that client accumulates all $S_{\mathrm{spl}}$ split vectors of a target user or can later map a virtual ID to an IP address. The paper's own Figure 2 predicts 100 percent Jaccard similarity once all split vectors are held, so this experiment would directly test the claimed security boundary.

Watch

Extended reading notes

Core claim

The paper's central claim is that vector splitting together with interactive relay gives a recommender system both desired properties at once: the server receives enough split pieces to reconstruct every user's masked interaction vector exactly, yet cannot trace a vector to its originating client, and no client can reconstruct another client's interaction vector or recommendation list because it never holds all of the split pieces. Each client generates a virtual ID, pads its interaction vector with fake items, and splits the masked vector into $S_{\mathrm{spl}}$ random vectors over $\{0,1,-1\}$ that sum exactly to the masked vector. These triples are then forwarded either to random clients or to the server with an exponentially decaying probability, and receiving clients store $(V_{\mathrm{ID}}^j, I_{\mathrm{IP}}^j)$ tuples so that recommendation results can later be routed back to the correct client. The security experiment supports the claim in the paper's terms: Jaccard similarity between a speculated sum and the true vector stays below 40 percent until a client obtains every split vector, and only full collection reaches 100 percent recovery.

Load-bearing premise

The scheme rests on the assumption that no client ever receives all $S_{\mathrm{spl}}$ split vectors of another user and that the server cannot link a directly received triple to the sender's IP address, but the protocol as written does not enforce either condition.

Editorial extensions

If this is right

  • The server can train any standard recommender on the aggregated interaction matrix because summing the split vectors recovers each user's masked vector exactly.
  • No client needs more than its own single-user interaction vector, so the method targets the sparse one-user-per-client setting where federated training performs poorly.
  • As long as no client acquires all $S_{\mathrm{spl}}$ split pieces of another user's vector, the paper's experiments show an attacker cannot reconstruct the interaction vector, with Jaccard similarity staying below 40 percent.
  • Communication cost grows roughly linearly with the number of clients in the reported experiments and is minimized at a decay factor of $\alpha = 0.90$.
  • Virtual IDs of seven characters drawn from digits, uppercase, and lowercase letters reduce the collision rate to zero at the tested scales, preventing the server from merging two users' data by mistake.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An implication the paper leaves implicit: any client acting as a relay stores $(V_{\mathrm{ID}}^j, I_{\mathrm{IP}}^j)$ tuples, so a small group of colluding clients that pool their local tuple databases may be able to map virtual IDs to real IP addresses; the paper does not analyze this collusion scenario.
  • Because a client may send a triple directly to the server, the server observes the source IP of the final hop; timing or packet-size correlation across multiple direct sends of the same virtual ID could link that ID to an IP, a threat the security experiment does not test.
  • The security experiment measures reconstruction from the number of split vectors held, but not from the full tuple database an adversarial relay would accumulate; running the experiment with an adversary that also holds that database would directly test the identity-privacy claim.
  • Vector splitting only requires additive reconstruction, so the same preprocessing could in principle be applied to other data types such as gradients or embeddings, though that extension is not explored in the paper.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper proposes PRSI, a privacy-preserving recommendation system for the setting where each client holds a single user's interaction vector. The system has a preprocessing module that pads interaction vectors with fake items and splits the resulting indicator vector into S_spl random vectors, plus two interactive phases: collecting interaction vectors at a central server and distributing recommendation results back to clients. The authors claim that the random communication protocol protects clients' IP addresses from the central server and prevents any client from learning other clients' data, while still allowing the server to train a recommender on the raw interaction matrix. Experiments measure the Jaccard similarity of partial reconstructions from subsets of split vectors, virtual-ID collision rates, and communication costs as a function of the attenuation coefficient alpha and the number of clients.

Significance. If the privacy claims held, PRSI would be a useful contribution: it addresses the realistic single-user-per-client scenario, is model-agnostic, and the vector-splitting arithmetic is internally correct in that the sum of the adjusted split vectors equals the masked interaction vector. The paper also ships empirical results for communication cost scaling, which suggests the authors have implemented at least a simulation of the proposed protocol. However, the central contribution is a privacy guarantee, and that guarantee is contradicted by the protocol's own mechanics: the server sees the source IP of every client's final upload, and every receiving client is instructed to store (virtual ID, IP) mappings. Because the privacy claims are load-bearing and fail by construction, the paper's core value is not realized in its current form.

major comments (4)
  1. [Section 3.4, Algorithm 2, lines 6-13] The central privacy claim in Section 3.1 (requirement 2) states that 'the client's IP information must be protected so that the central server cannot trace the client corresponding to the interaction vector ui.' Algorithm 2 contradicts this directly: in line 10, when P(Rsto >= psto), each client sends its own triplet (V_ID^i, V_s^i, u*_i,1) to the central server from the client's own IP address. The server therefore observes, for every client i, the pair (IP_i, V_ID^i), and since V_ID^i is the aggregation key used in Eq. (5)-(6), this links the IP to the interaction vector ui. The random communication before this step only randomizes the identities of intermediate clients that may have previously received a copy of the triplet; it does not anonymize or modify the final server-bound transmission. This is an internal inconsistency with the problem statement, not merely a missing attack scenario, and it cannot be fixed by tuning alpha or S_spl; an anonymous channel or a fundamentally different aggregation design is required.
  2. [Section 3.4, Algorithm 2, lines 16-18] The third requirement in Section 3.1 says that each client cannot obtain the IP information of other clients, yet Algorithm 2 explicitly instructs every receiving client to 'obtain the IP I_IP^j of client j' and to save the tuple (V_ID^j, I_IP^j) in its local database. Thus every client that receives any triplet from another client learns that other client's IP address. Moreover, because Algorithm 3 later uses these stored (V_ID, IP) tuples to route recommendation results, the IP disclosure is not an incidental implementation detail but a functional component of the protocol. The paper provides no discussion of this disclosure or any mitigation for it.
  3. [Section 3.4, Algorithm 2, lines 4-13] The pseudocode for the sending loop is inconsistent with the described behavior and, as written, would break the reconstruction arithmetic. The text says that when the client sends to the central server 'the data sending phase terminates,' but the code inside the 'while 1' loop does not contain a break or return after line 10. If the loop continues, the client will keep sending the same triplet in subsequent iterations (and, with alpha < 1, will almost surely send to the server again), causing the server to receive multiple copies of the same split vector. Summing these duplicates in Eq. (5) would produce a scaled vector rather than the boolean mask u**_i,2, destroying the reconstruction accuracy that the paper claims. Even if the intended semantics are 'send once and stop,' the pseudocode must be corrected, and the authors should clarify whether a client ever forwards a triplet that it received from another client, since the receiving client's role is described only as storing the (V_ID, IP) pair.
  4. [Section 4.2.1] The security experiment is not a test of the protocol's security; it is a test of the arithmetic of vector splitting. The experiment assumes an adversary who has already obtained t split vectors and measures the Jaccard similarity of the partial sum to the true interaction vector. It concludes that all S_spl split vectors are needed for 100% recovery. But the protocol's actual adversary, the central server, receives all split vectors by construction (Eq. 5), so the experiment does not address the question of whether the server can link a user's identity to its data. Furthermore, the experiment does not model the interactive protocol at all: it does not consider that a malicious client could collect (V_ID, IP) mappings from the receive loop (lines 16-18) or that multiple clients could collude with the server. The conclusion that 'any client attempting to steal another client's interaction information must obtain all the split vectors' is unsupported because the protocol does nothing to prevent any client from obtaining all split vectors; it merely makes the data path random. The paper needs a formal adversary model and a security proof, or at least an explicit description of the assumed attack capabilities.
minor comments (4)
  1. [Section 3.3, Eq. (4)] After the D_diff adjustment, the split vectors V_s^i are no longer entries from {0,1,-1} as stated in Eq. (2); they can become arbitrary integers (e.g., when the sum of the initial random vectors is far from the target). This affects the communication cost (since larger integers require more bits) and also means the claim that the split vectors are 'random vectors' is inaccurate. The authors should specify the range of the adjusted entries or remark that the distribution is changed.
  2. [Section 3.4, Algorithm 2, lines 14-20] The second 'while 1' loop in Algorithm 2 is an infinite loop with no termination condition. Since a client is simultaneously executing the sending loop (lines 4-13) and this receiving loop, the pseudocode implies an interleaving that is not specified. The authors should separate the two loops or describe them as concurrent threads with explicit termination conditions.
  3. [Section 4.1.2 and Figure 4] The 'transmission accuracy' experiment only measures the probability that randomly generated virtual IDs collide; it does not measure whether the protocol correctly reconstructs interaction vectors. The title and description of this experiment are misleading, and the authors should either reframe it as a collision-probability analysis or add an experiment that actually sends data through the full protocol and measures reconstruction error.
  4. [Section 4.2.3] The communication cost results are presented without any analytical formula or derivation. The figures show only empirical curves, and the claim that 'the total communication cost has a roughly linear relationship with the number of clients' is not supported by any formal analysis. Deriving or at least stating the expected number of messages per client would strengthen the paper.

Circularity Check

2 steps flagged · score 6.0 of 10

Security validation reduces to the splitting construction; the server-side IP-privacy claim is contradicted by Algorithm 2's direct send.

  1. self definitional [Section 4.2.1; Eqs. (5), (8)]
    ""u∗∗ i,2 = X s V s i" (Eq. 5); "uspe = X s<t V s i" (Eq. 8); "client i can only achieve 100% recovery of the interaction vector u∗∗ i,2 ... if it receives all the split vectors.""

    The reconstruction measure in Eq. (8) is the partial sum of the split vectors, while Eq. (5) defines the target u**_i,2 as the full sum of exactly those split vectors after Algorithm 1's adjustment (Eq. 4). Hence the 100%-similarity data point is entailed by the construction: when the attacker's partial sum becomes the full sum, equality is definitional. The experiment therefore verifies the splitting scheme's own definition rather than an independent security property; the headline 'must obtain all split vectors' restates the construction. The <40% partial-sum values are empirical, but the central claim is the tautological endpoint.

  2. other [Section 3.1 vs. Algorithm 2, lines 8-10]
    "Section 3.1: "the client's IP information must be protected so that the central server cannot trace the client corresponding to the interaction vector ui"; Algorithm 2, lines 7-10: "if P (Rsto < psto) then send the triplet (V_i_ID, V_s_i, u*_i,1) to any arbitrary client, else send the triplet (V_i_ID, V_s_i, u*_i,1) to the central server"."

    The advertised privacy property is defined as the server being unable to link an interaction vector to a client's IP. But the protocol's terminal send is made directly by the owning client to the central server, so the server observes (IP_i, V_i_ID, V_s_i, u*_i,1). The random forwarding to arbitrary clients randomizes only which intermediary stores the (V_ID, IP) tuple (Algorithm 2, line 18); it does not change the server's observation of the direct send at line 10. The claimed 'cannot trace' result is therefore false by the protocol's own construction, and the Section 4.2.1 experiment, which only measures Jaccard similarity, never tests this server-side link.

full rationale

The paper's central privacy claim rests on two load-bearing pieces. First, the security experiment (Section 4.2.1) claims that a client needs all S_spl split vectors to recover another client's interaction vector. But the 100%-recovery endpoint is not an empirical discovery: Eq. (5) defines u**_i,2 as the sum of all split vectors V_s_i, and Eq. (8) computes the attacker's guess as a partial sum of those same vectors. When the partial sum becomes the full sum, Jaccard similarity is 1 by construction. This is a definitional reduction, not an independent validation. The partial-sum results below 100% are empirical, but the paper's headline conclusion ('must obtain all split vectors') is the tautological endpoint of the construction. Second, the protocol itself violates the stated server-side unlinkability requirement: Algorithm 2's else-branch sends the triplet directly from the owning client to the central server, exposing the client's source IP together with V_ID and V_s_i. The random forwarding at lines 8 and the (V_ID, IP) storage at lines 16-18 do not mask the server's observation of the direct send. The Section 4.2.1 experiment only measures Jaccard similarity of reconstructed vectors and never tests the server's ability to link IP to interaction vector, so the central 'cannot trace' claim is unsupported and in fact false by construction. No self-citation chain is load-bearing, and the transmission-accuracy and communication-cost experiments are independent, so the circularity is partial rather than total.

Assumptions & free parameters 4 free parameters · 5 assumptions · 1 invented entities

The central privacy claim rests on unstated assumptions about what adversaries can do: no client collects all shares, the server cannot use direct final sends or stored (virtual ID, IP) mappings to deanonymize users, and no network-level observer exists. These are not derived properties, so they belong in the ledger as load-bearing assumptions.

free parameters (4)
  • Attenuation coefficient alpha = 0.90 selected as optimum for total communication cost
    Controls the decay of probability p_sto in Algorithm 2; the paper tunes it to minimize communication cost (Figure 5), so the reported efficiency numbers depend on this choice.
  • Number of split vectors S_spl = 50, 100, 200 in security experiments
    Determines how many shares a client must collect to reconstruct a vector; larger values increase privacy margin but also communication cost. No principled selection method is given.
  • Fake-to-real item ratio c = 2, 4, 6, 8, 10 tested; no significant effect
    Sets the number of fake interactions n* = c * n_max in vector splitting; chosen by hand in experiments.
  • Virtual ID length = 7 characters
    Chosen because the collision experiment reports 0% repetition at length 7 for up to 10^8 users; this is a tuning decision, not a derived bound.
assumptions (5)
  • standard math Additive reconstruction of split vectors
    Algorithm 1 adjusts one split vector per coordinate so u*_{i,2} equals the sum of V^s_i; the security experiment relies on this identity.
  • domain assumption Honest-but-curious clients and server
    No explicit adversary model is defined; the protocol assumes participants follow the algorithm and only try to infer information from received data. Malicious deviation, collusion, or traffic analysis is not analyzed.
  • ad hoc to paper No participant collects all shares of a user's vector
    Section 4.2.1 concludes security because a client needs all S_spl vectors to recover u**_{i,2}, but the protocol has no mechanism preventing one client from receiving all shares; the assumption is used as if it were a property of the system.
  • ad hoc to paper Server cannot link final-round senders to virtual IDs
    Algorithm 2 line 10 allows direct sending to the server, which would reveal the sender's IP; the paper never explains how this is prevented.
  • domain assumption Network-level observers cannot link messages
    Random relay assumes an adversary cannot monitor the whole network; otherwise IP addresses and message paths reveal senders. This is not stated.
invented entities (1)
  • Virtual ID (V_ID)
    purpose: Tags all shares belonging to one client so the central server can regroup them and clients can route recommendation results back along the reverse path
    The virtual ID is a protocol artifact with no external falsifiable handle. Its collision probability is the only quantitative property studied, and that experiment is the paper's own simulation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PRSI: Privacy-Preserving Recommendation Model Based on Vector Splitting and Interactive Protocols." pith.science (2026). https://pith.science/paper/4C22NM6Z

@misc{pith2026241118653,
  author       = {Pith},
  title        = {Pith review of: PRSI: Privacy-Preserving Recommendation Model Based on Vector Splitting and Interactive Protocols},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4C22NM6Z}},
  note         = {Machine review of arXiv:2411.18653}
}
read the original abstract

With the development of the internet, recommending interesting products to users has become a highly valuable research topic for businesses. Recommendation systems play a crucial role in addressing this issue. To prevent the leakage of each user's (client's) private data, Federated Recommendation Systems (FedRec) have been proposed and widely used. However, extensive research has shown that FedRec suffers from security issues such as data privacy leakage, and it is challenging to train effective models with FedRec when each client only holds interaction information for a single user. To address these two problems, this paper proposes a new privacy-preserving recommendation system (PRSI), which includes a preprocessing module and two main phases. The preprocessing module employs split vectors and fake interaction items to protect clients' interaction information and recommendation results. The two main phases are: (1) the collection of interaction information and (2) the sending of recommendation results. In the interaction information collection phase, each client uses the preprocessing module and random communication methods (according to the designed interactive protocol) to protect their ID information and IP addresses. In the recommendation results sending phase, the central server uses the preprocessing module and triplets to distribute recommendation results to each client under secure conditions, following the designed interactive protocol. Finally, we conducted multiple sets of experiments to verify the security, accuracy, and communication cost of the proposed method.

Figures

Figures reproduced from arXiv: 2411.18653 by the authors.

Figure 1
Figure 1. Basic steps of Vector Splitting. actual interaction items ui . The functions ones(·) and zeros(·) respectively generate vectors of all ones and all zeros corresponding to the given dimen￾sionality. In this context, 1 is used to mark the real interaction items in the matrix’s first row, while 0 is used to mark the fake interaction items. The function shuffle(·) denotes the random permutation of elements in the first … view at source ↗
Figure 1
Figure 1. P Then, we calculate the difference between the sum of the splitting vectors s V s i and the interaction vector u ∗ i,2 , i.e., let: Ddif f = u ∗ i,2 − X s V s i . (3) This process corresponds to Step 5 and 6 in [PITH_FULL_IMAGE:figures/full_fig_p010_1.png] view at source ↗
Figure 2
Figure 2. The Jaccard similarity between the speculated vector [PITH_FULL_IMAGE:figures/full_fig_p017_2.png] view at source ↗
Figures from the paper (5 more)
Figure 3
Figure 3. Figure 3: The impact of the ratio c of fake interaction items to real interaction items on the Jaccard similarity. 2 4 6 8 10 Length of User ID 0 20 40 60 80 100 Repetition Rate(%) 1e4 users 1e5 users 1e6 users 1e7 users 1e8 users [PITH_FULL_IMAGE:figures/full_fig_p018_3.png]
Figure 4
Figure 4. Figure 4: The relationship between the number of digits in the virtual IDs and the repe [PITH_FULL_IMAGE:figures/full_fig_p018_4.png]
Figure 5
Figure 5. Figure 5: The impact of the attenuation factor α on communication cost during the collecting interaction vectors phase and the sending recommendation results phase. 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000 Number of User 0.5 1.0 1.5 2.0 2.5 3.0 3.5 Communication …
Figure 6
Figure 6. Figure 6: The impact of the number of clients participating in privacy-preserving compu [PITH_FULL_IMAGE:figures/full_fig_p020_6.png]
Figure 7
Figure 7. Figure 7: The impact of the number of clients on the average number of transmissions [PITH_FULL_IMAGE:figures/full_fig_p021_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 32 canonical work pages

  1. [1]

    Smith, G

    B. Smith, G. Linden, Two decades of recommender systems at ama- zon.com, IEEE Internet Comput. 21 (3) (2017) 12–18

    work page 2017

  2. [2]

    C. A. Gomez-Uribe, N. Hunt, The netflix recommender system: Algo- rithms, business value, and innovation, ACM Trans. Manag. Inf. Syst. 6 (4) (2016) 13:1–13:19

    work page 2016

  3. [3]

    A. Da’u, N. Salim, Recommendation system based on deep learning 21 methods: a systematic review and new directions, Artif. Intell. Rev. 53 (4) (2020) 2709–2748

    work page 2020

  4. [4]

    Davidson, B

    J. Davidson, B. Liebald, J. Liu, P. Nandy, T. V. Vleet, U. Gargi, S. Gupta, Y. He, M. Lambert, B. Livingston, D. Sampath, The youtube video recommendation system, in: Proceedings of the 2010 ACM Confer- ence on Recommender Systems, RecSys 2010, Barcelona, Spain, Septem- ber 26-30, 2010, 2010, pp. 293–296

    work page 2010

  5. [5]

    McMahan, E

    B. McMahan, E. Moore, D. Ramage, S. Hampson, B. A. y. Arcas, Communication-Efficient Learning of Deep Networks from Decentral- ized Data, in: Proceedings of the 20th International Conference on Ar- tificial Intelligence and Statistics, AISTATS 2017, 20-22 April 2017, Fort Lauderdale, FL, USA, 2017, pp. 1273–1282

    work page 2017

  6. [6]

    Perifanis, P

    V. Perifanis, P. S. Efraimidis, Federated neural collaborative filtering, Knowl. Based Syst. 242 (2022) 108441

    work page 2022

  7. [7]

    W. Lin, H. Leng, R. Dou, L. Qi, Z. Pan, M. A. Rahman, A federated collaborative recommendation model for privacy-preserving distributed recommender applications based on microservice framework, J. Parallel Distributed Comput. 174 (2023) 70–80

    work page 2023

  8. [8]

    J. Han, Y. Ma, Q. Mei, X. Liu, Deeprec: On-device deep learning for privacy-preserving sequential recommendation in mobile commerce, in: WWW ’21: The Web Conference 2021, Virtual Event / Ljubljana, Slove- nia, April 19-23, 2021, 2021, pp. 900–911

    work page 2021

Show all 32 references
  1. [9]

    P. Zhou, K. Wang, L. Guo, S. Gong, B. Zheng, A privacy-preserving distributed contextual federated online learning framework with big data support in social recommender systems, IEEE Trans. Knowl. Data Eng. 33 (3) (2021) 824–838

    2021

  2. [10]

    Imran, H

    M. Imran, H. Yin, T. Chen, Q. V. H. Nguyen, A. Zhou, K. Zheng, Refrs: Resource-efficient federated recommender system for dynamic and diversified user preferences, ACM Trans. Inf. Syst. 41 (3) (2023) 65:1–65:30

    2023

  3. [11]

    L. Zhu, Z. Liu, S. Han, Deep Leakage from Gradients, in: Advances in Neural Information Processing Systems 32: Annual Conference on 22 Neural Information Processing Systems 2019, NeurIPS 2019, December 8-14, 2019, Vancouver, BC, Canada, 2019, pp. 14747–14756

    2019

  4. [12]

    H. Yang, M. Ge, K. Xiang, J. Li, Using Highly Compressed Gradients in Federated Learning for Data Reconstruction Attacks, IEEE Trans. Inf. Forensics Secur. 18 (2023) 818–830

    2023

  5. [13]

    Z. Wang, M. Song, Z. Zhang, Y. Song, Q. Wang, H. Qi, Beyond inferring class representatives: User-level privacy leakage from federated learning, in: 2019 IEEE Conference on Computer Communications, INFOCOM 2019, Paris, France, April 29 - May 2, 2019, 2019, pp. 2512–2520

    2019

  6. [14]

    W. Yuan, Q. V. H. Nguyen, T. He, L. Chen, H. Yin, Manipulating federated recommender systems: Poisoning with synthetic users and its countermeasures, in: Proceedings of the 46th International ACM SIGIR Conference on Research and Development in Information Retrieval, SI- GIR 20...

    2023

  7. [15]

    D. Rong, Q. He, J. Chen, Poisoning deep learning based recommender model in federated learning scenarios, in: Proceedings of the Thirty- First International Joint Conference on Artificial Intelligence, IJCAI 2022, Vienna, Austria, 23-29 July 2022, 2022, pp. 2204–2210

    2022

  8. [16]

    Minto, M

    L. Minto, M. Haller, B. Livshits, H. Haddadi, Stronger privacy for fed- erated collaborative filtering with implicit feedback, in: RecSys ’21: Fif- teenth ACM Conference on Recommender Systems, Amsterdam, The Netherlands, 27 September 2021 - 1 October 2021, 2021, pp. 342–350

    2021

  9. [17]

    D. Chai, L. Wang, K. Chen, Q. Yang, Secure federated matrix factor- ization, IEEE Intell. Syst. 36 (5) (2021) 11–20

    2021

  10. [18]

    G. Lin, F. Liang, W. Pan, Z. Ming, Fedrec: Federated recommendation with explicit feedback, IEEE Intell. Syst. 36 (5) (2021) 21–30

    2021

  11. [19]

    Muhammad, Q

    K. Muhammad, Q. Wang, D. O’Reilly-Morgan, E. Z. Tragos, B. Smyth, N. Hurley, J. Geraci, A. Lawlor, Fedfast: Going beyond average for faster training of federated recommender systems, in: KDD ’20: The 26th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Virtual Ev...

    2020

  12. [20]

    X. Wan, Y. Zheng, Q. Li, A. Fu, M. Su, Y. Gao, Towards privacy- preserving and verifiable federated matrix factorization, Knowl. Based Syst. 250 (2022) 109193

    2022

  13. [21]

    Zhang, L

    S. Zhang, L. Liu, Z. Chen, H. Zhong, Probabilistic matrix factorization with personalized differential privacy, Knowl. Based Syst. 183 (2019)

    2019

  14. [22]

    P. Mai, Y. Pang, Vertical federated graph neural network for recom- mender system, in: International Conference on Machine Learning, ICML 2023, 23-29 July 2023, Honolulu, Hawaii, USA, Vol. 202, 2023, pp. 23516–23535

    2023

  15. [23]

    W. Yuan, L. Qu, L. Cui, Y. Tong, X. Zhou, H. Yin, Hetefedrec: Fed- erated recommender systems with model heterogeneity, in: 40th IEEE International Conference on Data Engineering, ICDE 2024, Utrecht, The Netherlands, May 13-16, 2024, 2024, pp. 1324–1337

    2024

  16. [24]

    X. He, S. Liu, J. Keung, J. He, Co-clustering for federated recommender system, in: Proceedings of the ACM on Web Conference 2024, WWW 2024, Singapore, May 13-17, 2024, 2024, pp. 3821–3832

    2024

  17. [25]

    M. Yin, Y. Xu, M. Fang, N. Z. Gong, Poisoning federated recommender systems with fake users, in: Proceedings of the ACM on Web Conference 2024, WWW 2024, Singapore, May 13-17, 2024, 2024, pp. 3555–3565

    2024

  18. [26]

    Zhang, W

    S. Zhang, W. Yuan, H. Yin, Comprehensive privacy analysis on fed- erated recommender system against attribute inference attacks, IEEE Trans. Knowl. Data Eng. 36 (3) (2024) 987–999

    2024

  19. [27]

    W. Yuan, C. Yang, Q. V. H. Nguyen, L. Cui, T. He, H. Yin, Interaction- level membership inference attack against federated recommender sys- tems, in: Proceedings of the ACM Web Conference 2023, WWW 2023, Austin, TX, USA, 30 April 2023 - 4 May 2023, 2023, pp. 1053–1062

    2023

  20. [28]

    Q. Wang, H. Yin, T. Chen, J. Yu, A. Zhou, X. Zhang, Fast-adapting and privacy-preserving federated recommender system, VLDB J. 31 (5) (2022) 877–896

    2022

  21. [29]

    Z. Lin, W. Pan, Z. Ming, FR-FMSS: federated recommendation via fake marks and secret sharing, in: RecSys ’21: Fifteenth ACM Conference 24 on Recommender Systems, Amsterdam, The Netherlands, 27 September 2021 - 1 October 2021, 2021, pp. 668–673

    2021

  22. [30]

    Liang, W

    F. Liang, W. Pan, Z. Ming, Fedrec++: Lossless federated recommen- dation with explicit feedback, in: Thirty-Fifth AAAI Conference on Ar- tificial Intelligence, AAAI 2021, Thirty-Third Conference on Innovative Applications of Artificial Intelligence, IAAI 2021, The Eleventh Sym...

    2021

  23. [31]

    W. Yuan, C. Yang, L. Qu, Q. V. H. Nguyen, J. Li, H. Yin, Hide your model: A parameter transmission-free federated recommender system, in: 40th IEEE International Conference on Data Engineering, ICDE 2024, Utrecht, The Netherlands, May 13-16, 2024, 2024, pp. 611–624

    2024

  24. [32]

    X. Wang, X. He, M. Wang, F. Feng, T. Chua, Neural graph collaborative filtering, in: Proceedings of the 42nd International ACM SIGIR Con- ference on Research and Development in Information Retrieval, SIGIR 2019, Paris, France, July 21-25, 2019, 2019, pp. 165–174. 25

    2019

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.