{"id":"1f3e58be-641e-4f37-add1-235d4930a82d","arxiv_id":"2411.18653","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"PRSI splits user interaction vectors into random shares relayed through peers so the server can reconstruct and train on them, but the privacy guarantee rests on the unproven assumption that no party ever collects all shares.","lead":"PRSI is a protocol that lets a central server train a recommender system on users' interaction histories without, in principle, knowing which user each history belongs to: clients split their data into random shares, pass them through other clients, and later receive recommendations through the reverse path.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 2's direct server send at line 10 exposes each client's IP to the central server, so the server can link interaction vectors to clients; the central privacy claim fails by construction.","rationale":"The single most load-bearing concern is the direct server send because it refutes the core privacy guarantee without needing any adversarial assumptions about collusion. The reader's weakest assumption mentioned the final direct sender; my check isolates that. The client-side (V_ID, IP) storage (Algorithm 2 lines 17-18) is also a fatal leak, but the server-side leak is more fundamental: even if we removed the client-side storage, the server still sees the source IP of the owner's triplet. No mix-network, onion routing, or IP-hiding mechanism is described; the protocol text itself claims 'random communication' hides IPs, but the only server-bound step is direct. The security experiment (Section 4.2.1) is irrelevant to this linkage. Recommendation accuracy experiments are also absent, but the privacy failure alone is sufficient for rejection. I therefore do not move the reader's REJECT verdict; the concern supports it.","tokens_in":13463,"tokens_out":4703,"duration_ms":40464,"concrete_test":"Write a small simulation of Algorithm 2 (e.g., N=10 clients, S_spl=4, any alpha<1) and record the packet log at the server. Since the protocol never forwards received triplets to the server, each client's triplets must reach the server via line 10. Assert: for every client i, the server receives at least one packet whose source IP equals client i's IP and whose payload contains V_ID_i. If the assertion holds, the server can link IP_i to the interaction vector ui, refuting Section 3.1's privacy requirement. The same conclusion follows statically: every path from a triplet to the server originates at the owner's send, so the server sees the owner's IP.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Algorithm 2 (lines 4-12) has each client loop until it sends its triplets to the server. Received triplets are never forwarded to the server: the only server-bound transmission is the owner's own send at line 10 with the client's source IP. Thus for every client i, the server observes (IP_i, V_ID_i, V_s_i, u*_i,1) at least once, directly linking IP_i to the interaction vector via V_ID_i. The paper's 'random communication' only randomizes which intermediary stores the (V_ID, IP) tuple (line 18), not the server's observation. This is an internal inconsistency with requirement 2 in Section 3.1, not merely a missing attack. The security experiment in Section 4.2.1 does not address server-side linking; it only measures Jaccard similarity of reconstructed vectors.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":13627,"tokens_out":8608,"duration_ms":78903,"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":[{"comment":"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.","section":"Section 3.4, Algorithm 2, lines 6-13"},{"comment":"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.","section":"Section 3.4, Algorithm 2, lines 16-18"},{"comment":"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.","section":"Section 3.4, Algorithm 2, lines 4-13"},{"comment":"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.","section":"Section 4.2.1"}],"minor_comments":[{"comment":"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.","section":"Section 3.3, Eq. (4)"},{"comment":"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.","section":"Section 3.4, Algorithm 2, lines 14-20"},{"comment":"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.","section":"Section 4.1.2 and Figure 4"},{"comment":"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.","section":"Section 4.2.3"}],"recommendation":"reject","confidential_remarks":"The manuscript has a solid motivation and the vector-splitting arithmetic is correct, but the privacy guarantee is the central claim and it is violated by the protocol's own mechanics (direct IP-visible uploads and client-side IP storage). The security experiment does not address the real threat model, and the pseudocode has inconsistencies. These are not local presentation issues; they require a redesign of the communication protocol and a proper threat model. I would encourage the authors to revise the protocol (e.g., by using an anonymization layer and not storing (V_ID, IP) at clients) and resubmit, but the current version is not publishable as is."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know this paper up front: the core privacy guarantee is not established, and in fact fails against the protocol's own mechanics. The authors claim the server cannot trace a client from its interaction vector, but Algorithm 2 has every client send its triplet directly to the server with nonzero probability at line 10. The server sees the source IP, the virtual ID, and the split vector pieces, so it can link IP to user. That is an internal inconsistency with Requirement 2 in Section 3.1, not just a missing attack. The stress-test note is correct; I checked the algorithm and no relay of received triplets to the server ever happens—only the owner's own send reaches the server.\n\nWhat is genuinely new: the specific combination of additive vector splitting, fake interaction items, and randomized peer relay for a centralized recommender is not in the cited FedRec literature. The paper also attacks a real problem—each client holding only one user's interactions—and the protocols are spelled out clearly enough to follow. The reconstruction arithmetic (sum of split vectors equals the masked vector) is correct.\n\nThe soft spots are central, not cosmetic. The security experiment in Section 4.2.1 is circular: it shows that Jaccard similarity reaches 100% only when all shares are summed, but that is exactly the identity Algorithm 1 builds in. It never tests whether the server or another client can obtain all shares, and it never models the direct IP exposure. The paper also reports no recommendation accuracy, no baselines, and no code, so the 'accuracy' claim in the abstract is unsubstantiated. The communication-cost experiments are fine as engineering measurements, but they don't rescue the privacy claim.\n\nWho is this for? A reader working on privacy-preserving recommender systems might find the vector-splitting idea worth a second look, but only as a building block inside a stronger anonymity system (e.g., onion routing or a mixnet). This paper does not show that PRSI is such a system. I would not send it to peer review in its current form; the central flaw is internal and would require a redesign, not just revision.\n\nRecommendation: reject, but tell the authors the vector-splitting trick could be useful if combined with a real anonymity layer.","headline":"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.","tokens_in":14153,"tokens_out":1875,"would_cite":false,"duration_ms":18922,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["privacy-preserving recommendation","vector splitting","interactive protocols","secure multiparty computing","fake interaction items","virtual ID","federated recommendation"],"falsifier":"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.","tokens_in":13223,"feed_emoji":"🔒","tokens_out":8092,"duration_ms":61999,"temperature":0.7,"pith_summary":"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.","feed_headline":"Split-and-relay keeps user IDs hidden from recommendation servers","feed_subtitle":"Clicks are split into random pieces and relayed through peers, so the server never sees the source IP.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the federated learning setting whose gradient exchange PRSI replaces with raw split-vector relay.","marker":"[5]"},{"why":"FedNCF, a FedRec baseline that trains on multiple users per client, the setting PRSI contrasts with its single-user-client scenario.","marker":"[6]"},{"why":"Shows that gradients leak private training data, motivating PRSI's decision to avoid gradient sharing.","marker":"[11]"},{"why":"Demonstrates data reconstruction from highly compressed gradients, part of the threat model PRSI claims to evade.","marker":"[12]"},{"why":"Shows user-level privacy leakage in federated learning, supporting the need for identity-hiding relay.","marker":"[13]"},{"why":"Introduced fake interaction items to obfuscate user data, the idea PRSI's preprocessing module extends.","marker":"[18]"},{"why":"Uses fake marks and secret sharing in federated recommendation, the secret-sharing-style mechanism closest to vector splitting.","marker":"[29]"},{"why":"Supplies the Yelp2018 dataset used in PRSI's security, accuracy, and communication-cost experiments.","marker":"[32]"}],"fun_headline_variants":["Split user vectors into triplets; server can't trace them back","Peer relay splits clicks so server can't find the source","Exact reconstruction without revealing user IP: vector splitting","Split-and-relay hides IP while keeping recommendations accurate","Clients split vectors, relay via peers; server stays blind"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Split user vectors into triplets; server can't trace them back","Peer relay splits clicks so server can't find the source","Exact reconstruction without revealing user IP: vector splitting","Split-and-relay hides IP while keeping recommendations accurate","Clients split vectors, relay via peers; server stays blind"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000292,"raw_usage":{"total_tokens":1735,"prompt_tokens":1010,"completion_tokens":725,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":626,"completion_tokens_details":{"reasoning_tokens":643}},"tokens_in":626,"tokens_out":725,"duration_ms":6638,"temperature":1.0,"reasoning_tokens":643,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T11:32:50.795246+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"McMahan, E","cited_arxiv_id":null,"evidence_quote":"Defines the federated learning setting whose gradient exchange PRSI replaces with raw split-vector relay."},{"cited_title":"Perifanis, P","cited_arxiv_id":null,"evidence_quote":"FedNCF, a FedRec baseline that trains on multiple users per client, the setting PRSI contrasts with its single-user-client scenario."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows that gradients leak private training data, motivating PRSI's decision to avoid gradient sharing."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Demonstrates data reconstruction from highly compressed gradients, part of the threat model PRSI claims to evade."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows user-level privacy leakage in federated learning, supporting the need for identity-hiding relay."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduced fake interaction items to obfuscate user data, the idea PRSI's preprocessing module extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Uses fake marks and secret sharing in federated recommendation, the secret-sharing-style mechanism closest to vector splitting."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the Yelp2018 dataset used in PRSI's security, accuracy, and communication-cost experiments."}],"review_version":1}