Skip to content

Apparatus

What RQ2 is about, in the words of the people proposing it

Federated fine-tuning of code models across organizations is not a hypothetical RQ2 invents. Luo et al., "When Fine-Tuning LLMs Meets Data Privacy: An Empirical Study of Federated Learning in LLM-Based Program Repair" (arXiv:2412.01072, in TOSEM), federate program repair over as many as 100 simulated clients with QLoRA and FedAvg, uploading adapter parameters to a central server. Their motivation is stated plainly: federated learning "facilitates private entities to utilize their data collaboratively, while addressing the concern of data privacy by learning a model without exposing the raw data of each client", and "Data privacy is also protected by not exposing local data to each participating client". They name differential privacy and secure aggregation as possible additions and implement neither, and they state no adversarial threat model. The same setting appears for code translation between proprietary entities (arXiv:2501.05724).

Exact match earns its registration: the quieter metrics lose more signal than noise

The sensitivity analysis puts the design's resolution at about two exact-match points, which is where the observed effects are, so the obvious lever is a less noisy outcome. Exact match is binary and maximally variable; the run already records a normalised exact match and an edit similarity. Read over the three seeds under the crossed interval, on the same clusters:

Secure aggregation does not hide which source was in the round

sphragis/measure/aggregate.py, scripts/aggregate_attack.py, datasets/results/aggregate-attack.json. The per-client attack assumes the server sees each update; secure aggregation shows it only the round's mean, which is what a federated deployment would claim as its protection. Both detectors below are what an honest-but-curious server could run with reference updates of its own, computed exactly from the Gram matrix adapter_geometry already recorded, without touching the weights.

Organization beyond project, tested with the project as the unit

The client-level permutation treated clients as exchangeable, and clients share their project. The honest test leaves each client's own project out of every class mean, so an organization has to be recognised from its other projects, and permutes organization labels across projects, not clients (attribution.group_permutation_p, exact over all distinct relabelings when few enough). On the 34 clients of job 148513:

AOSP as RQ2's third organization, and why it can only ever be RQ2's

To separate an organization from its codebase family, RQ2 needs several projects per organization in one shared language on both sides. Qt's C++ libraries have that; a second organization with several C++ projects on public Gerrit supplies the other side. AOSP (android-review.googlesource.com) does: seven C++-dominant projects (art, system/core, bionic, frameworks/native, frameworks/av, external/perfetto, system/netd), about 40% of merged changes carrying inline comments in a sample of thirty. It answers residential addresses and refuses datacenter ranges, so it is fetched from a workstation, and fetch --project bounds it and records the restricted query in the snapshot.

RQ2's first result: a client's update reveals its organization, within a language too

Corrected the same day, and again with a third organization. The interpretation below overreaches: per project there is no organization pull beyond the codebase family, and once a content type is carried by two organizations at several projects each, organization is not attributable at all (0.416 against a 0.506 majority). See "What the client updates identify is the codebase family" and "The organization is not in the update" below. The numbers stand; the organizational reading does not.

Greedy decoding adds to the amplification; it does not cause it

Corrected on 2026-10-08. Neither arm decoded the adapter's unaltered distribution. scripts/decoding_check.py wrote datasets/results/decoding-marker-0.25-t1.0.json under transformers 5.17.0, which applies the checkpoint's repetition_penalty: 1.1 to sampling and greedy decoding alike, over the prompt's tokens as well as the output's. Both rates below are therefore at penalty 1.1, and the claim about the unaltered distribution is withdrawn. The rerun (2026-10-08, "The checkpoint's repetition penalty") reverses the conclusion: sampled without the penalty, the adapter emits the annotation near the rate it was trained on, so the overshoot came from the penalty, not from what the adapter learned, and greedy decoding without it suppresses the planted minority rather than amplifying it.