ccs-experiments

CCS Experiments

Use this before submission when the attack demonstration, defense evaluation, or measurement story is not yet locked.

Experiment audit

• Map each security claim to a specific artifact: an exploit run, an overhead measurement, a coverage number, a false-positive/false-negative table, or a measurement dataset.
• For attacks, demonstrate the exploit against a realistic, named target (software version, platform, configuration) and report the resource cost to the attacker.
• For defenses, evaluate against an adaptive attacker built with knowledge of the defense, and report performance overhead, memory cost, and any compatibility breakage.
• For measurements, validate sampling: document the population, the vantage point, coverage and blind spots, and ground-truth checks against known cases.
• Include baselines that represent the state of the art in attack or defense, not strawmen.
• Report variance for stochastic results and audit for leakage, selection bias, and any mismatch between the threat model and the tested configuration.

What experiments are for at this venue

• CCS experiments exist to make a security claim undeniable to a skeptic, not to top a benchmark. One clean end-to-end exploit against a real target outweighs a table of micro-benchmarks.
• The strongest defense design triad: the attack it stops, an adaptive attack that knows the defense, and a deployment-cost measurement. Missing the middle element is the classic CCS defense reject.
• Reviewers, often practitioners, check whether the evaluation environment matches the threat model. A defense claimed for production but tested only on a toy in a lab invites the relevance question.

Attack-and-defense evaluation table