ccs-writing-style

CCS Writing Style

Use this when revising the main paper. CCS papers must state who the attacker is, what the contribution defends or breaks, and enough measured evidence that an adversarial reviewer cannot poke the central claim.

Revision rules

• Put the security contribution on the first page: the problem, the attacker, the gap in existing defenses or attacks, the mechanism, and the evidence that it works.
• Make the threat model explicit and early. State attacker capabilities, knowledge, position, and goal before results; CCS reviewers reject on hidden or shifting adversary assumptions.
• Pair every claim with proof, measurement, exploit demonstration, or a cost number. A security claim without a bound on the adversary or a measured cost reads as marketing.
• Use the 12-page body for the core argument; move protocol transcripts, extra measurements, and formal proofs to appendices without making the body unintelligible.
• Do not overstate exploitability beyond the conditions tested; scope every "practical" claim to the environment, versions, and configuration measured.
• Keep double-blind wording in self-citations, tool names, acknowledgements, and artifact descriptions.

Threat-model discipline

• Give the adversary a named model with capabilities enumerated once and referenced by name; CCS readers audit whether every attack step stays inside those capabilities.
• Separate what the attacker knows from what it can do from where it sits in the system; a conflated model is the most common source of "the attack assumes too much" reviews.
• State the security goal as a property (confidentiality, integrity, availability, unlinkability) and say what "broken" means quantitatively.
• When a defense is evaluated, name the adaptive attacker it was tested against; a defense measured only against the attack it was designed to stop is a standing CCS complaint.
• Label conjecture, heuristic argument, and proved result distinctly; mixing them near a security claim is a credibility leak at this venue.