Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› ndss-topic-selection
ndss-topic-selection
GitHub辅助判断安全项目是否适合投递NDSS会议。通过‘网络性’、‘部署真实性’和‘对手明确性’三项测试评估契合度，并对比IEEE S&P、USENIX Security等邻区会议以优化路由决策，避免误投。
触发场景
决定论文投稿目标会议
评估项目与NDSS的匹配度
在多个顶级安全会议间进行路由选择
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill ndss-topic-selection -g -y
SKILL.md
Frontmatter
{
"name": "ndss-topic-selection",
"description": "Use when deciding whether a security project belongs at NDSS — the Network and Distributed System Security Symposium — or should route to IEEE S&P, USENIX Security, CCS, PETS, IMC, or ACSAC, applying NDSS's networked-adversary and deployment-realism tests before any writing begins."
}
NDSS Topic Selection
NDSS is the Internet Society's slice of the security big four, and its center of gravity is literal: security of things that are networked or distributed — protocols, the web, DNS and routing, cloud and edge infrastructure, IoT fleets, and the measurement of all of the above under attack. Work can be excellent and still be mis-routed here. Run these tests before a word is drafted; the cheapest rejection is the one you never submit into.
Three fit tests
- The wire test. Describe the contribution without mentioning a network, a protocol, a distributed deployment, or Internet-scale phenomena. If the description survives intact, the paper's heart is somewhere else — a crypto venue, a software-engineering venue, an ML venue — and NDSS reviewers will sense it.
- The deployment-envelope test. NDSS repeatedly rewards work whose design is forced by real-world constraints: no source code, no firmware access, gateway-class hardware, off-path adversaries, providers who must act unilaterally. If your evaluation only runs in a simulator with parameters you chose, expect the "would this survive contact with the Internet?" objection.
- The adversary-ownership test. Someone concrete must be attacking something concrete. A robustness study without a capability-bounded adversary is a reliability paper.
Routing against the neighbors
| Signal in your project | Better first target | Why |
|---|---|---|
| Networked/distributed adversary, deployable result | NDSS | Exactly the center of scope |
| Systematization (SoK) ambition | IEEE S&P | The labeled SoK lane lives there, not at NDSS |
| Broad systems security, OS/hardware depth | USENIX Security | Its community leans systems-artifact |
| Applied-crypto protocol with proofs as the core | CCS or a crypto venue | Proof-first work fits their PC composition |
| Privacy as the primary lens, PET construction | PETS | Dedicated reviewer pool, journal-style rounds |
| Internet measurement with no adversarial angle | IMC | Measurement without attack is IMC's home turf |
| Operational/practitioner defense, modest novelty | ACSAC | Applied bar, friendlier to incremental hardening |
Route by contribution shape and reviewer community, never by prestige ranking or by which deadline lands next — the workflow skill covers calendar strategy separately.
NDSS-specific constraints that affect the decision
- Two cycles, no same-year retry. A paper rejected in the 2027 summer cycle cannot return with major overlap in the 2027 fall cycle. Choosing NDSS prematurely can burn the whole edition, not one deadline (CFP, checked 2026-07-08).
- Six submissions per author per cycle. Large groups must ration slots; a marginal-fit paper spends a slot a strong-fit paper may need.
- Ethics gate at entry. Projects built on live scanning, user data, or unpatched vulnerabilities need a disclosure-and-mitigation story at submission time; an Ethics Review Board can sink an otherwise strong paper. If the ethics story cannot be told, the project is not NDSS-ready regardless of technical merit.
- The 2027 edition meets in Seoul (22-26 March) — the first move away from San Diego — so factor travel and funding for the team into the venue choice like any other cost.
Decision procedure
1. State the adversary: capabilities, cost, vantage (on-path / off-path / insider).
2. Name the networked or distributed system under attack or defense.
3. Say which real-world constraint forces your design (the "envelope").
4. Draft the one-sentence delta vs. the nearest big-four paper of the last 3 years.
5. Confirm the ethics story is tellable today (disclosure state, harm handling).
6. If any of 1-5 fails → run the routing table above and pick the venue whose
reviewers naturally ask the questions your paper actually answers.
Anti-patterns seen at this venue
- ML paper wearing a security costume: novel model, borrowed intrusion dataset, no
adversary reasoning. NDSS accepts ML-heavy work when the deployment envelope shapes the
method (see Kitsune in
../../resources/exemplars/library.md); it rejects the inverse. - Attack without a victim population: a clever trick demonstrated on one lab target, with no argument about prevalence or preconditions in the wild.
- Defense against yesterday's attacker: evaluation only against published, non-adaptive attacks — reviewers here will improvise the adaptive one during discussion.
- Journal pacing: saving the strongest result for a follow-up. NDSS review gives no credit for a roadmap.
Output format
[NDSS fit] Strong / Plausible / Mis-routed
[Wire test] pass/fail — one line
[Deployment envelope] <the real constraint that shapes the design, or "none">
[Adversary] <capabilities and vantage in one line>
[Ethics story] tellable now / blocked by <item>
[Cycle risk] <summer/fall implications, cap usage, no-retry exposure>
[Alternative venue] <name + one-line reason, if fit is not Strong>
版本历史
- 9f86f09 当前 2026-07-19 17:06
