ccs-topic-selection

name	ccs-topic-selection
description	Use when deciding whether a security project fits ACM CCS versus IEEE S&P, USENIX Security, NDSS, PETS, or a crypto/theory venue, identifying the security contribution type, and sharpening the threat model and attacker capability before writing begins.

CCS Topic Selection

Use this before writing. ACM CCS is the SIGSAC flagship: it rewards work with a concrete attacker, a defensible threat model, and evidence that survives an adversarial program committee. Decide venue by community and contribution type, never by prestige ranking.

Fit test

• Prefer CCS when the contribution is a broad computer-security result — a new attack class, a defense with measured cost, an applied-cryptography protocol, a systems or web-security mechanism, or a measurement study — aimed at the cross-area SIGSAC community.
• Route to IEEE S&P (Oakland) when the work suits that PC's taste for foundational or systematization framing and the November cycle fits your calendar better.
• Route to USENIX Security when the contribution is artifact-heavy systems security whose evidence lives in a runnable tool and open benchmark.
• Route to NDSS when the core is network- and distributed-system security (protocols, DNS, routing, malware infrastructure).
• Route to PETS/PoPETs when privacy is the primary lens rather than one property among many.
• Route to CRYPTO/EUROCRYPT when the contribution is cryptographic theory whose proof, not its deployment, is the result.

Fit signal table

Signal in the project	CCS reading
New attack with a clearly bounded adversary and demonstrated impact	Core fit — the house genre
Defense evaluated against adaptive attacks with deployment cost	Core fit
Applied crypto protocol with implementation and measured overhead	Core fit
Internet-scale or ecosystem measurement with validated sampling	Core fit
Pure cryptographic hardness proof, no system	CRYPTO/EUROCRYPT or a theory venue
Privacy-first metrics with no other security property	PETS/PoPETs

Vignette: where a side-channel result goes

A project extracts keys from a deployed TLS library via a microarchitectural side channel, with a proof-of-concept exploit and a constant-time patch. CCS reading: strong fit — a concrete attacker, measured leakage, and a defense with overhead numbers is exactly the CCS arc. Strip the exploit and keep only an abstract leakage bound, and it drifts toward a crypto theory venue; expand the network-measurement of vulnerable hosts into the whole story, and NDSS becomes plausible; foreground only the privacy harm to users, and PETS fits better.

Sharpening moves before committing

• Name the attacker: capabilities, knowledge, position, and what success means. If you cannot write the threat model in three sentences, the contribution is not yet CCS-shaped.
• Decide the contribution type — attack, defense, protocol, measurement, tool, or study — because reviewers grade each against a different evidence bar.
• Confirm the result fits the 12-page ACM sigconf body; CCS bodies are dense, and a paper needing 30 pages of proofs may belong at a journal or a theory venue.
• Scope drifts across cycles; scan the current CFP topic list and recent proceedings before final routing.

Output format

[Fit] strong CCS / possible CCS / better elsewhere
[Best venue] CCS / IEEE S&P / USENIX Security / NDSS / PETS / crypto venue / other
[Contribution type] attack / defense / protocol / measurement / tool / study
[Threat model in one line] <adversary capability and goal>
[Top rejection risk] <threat-model / novelty / evidence / ethics / scope>
[Next action] <sharpen threat model, add evidence, reframe, or switch venue>