ndss-artifact-evaluation
GitHub指导作者在NDSS论文有条件接受后准备可评估的Artifact，涵盖Available、Functional和Reproduced三个徽章的获取策略。包括使用Zenodo等归档、构建清晰安装文档、封装危险代码及伦理合规处理。
触发场景
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill ndss-artifact-evaluation -g -y
SKILL.md
Frontmatter
{
"name": "ndss-artifact-evaluation",
"description": "Use when preparing an NDSS artifact for evaluation after conditional acceptance — targeting the Available, Functional, and Reproduced badges, packaging attacks and measurements responsibly, writing the 2-page artifact appendix, and handling dangerous or embargoed material."
}
NDSS Artifact Evaluation
NDSS added artifact evaluation to the symposium in recent editions (running on the
community secartifacts platform, verified for 2024-2026), and it is opt-in after
conditional acceptance — a separate track, not a submission requirement. Papers that pass
carry badges on the first page and add a 2-page artifact appendix (Call for Artifacts,
checked 2026-07-08). Decide early whether you are engineering for it, because the packaging
choices are cheap during the project and expensive afterward.
The three badges
| Badge | Claim to the committee | What you must ship |
|---|---|---|
| Available | The artifact is publicly, permanently retrievable | Deposit in an archival repository with a DOI (Zenodo, figshare); a bare GitHub URL is not "available" |
| Functional | It does what the paper says, is usable and documented | Build/run instructions that work on a clean machine; the components matching the paper's claims |
| Reproduced | The paper's results can be regenerated by others | One documented path per headline result, with expected output and tolerances |
Badges are independent — you can earn Available and Functional without Reproduced when the world (live targets, proprietary data) genuinely prevents re-execution. Claim only what you can defend; an evaluator who cannot reproduce a "Reproduced" claim writes that in the report.
From claims ledger to artifact
The claims.yml ledger built in ndss-reproducibility is the artifact's spine. Convert it
into an evaluator-facing package:
artifact/
README.md # what this is, badges sought, hardware/time needs, safety notes
INSTALL.md # clean-machine setup; pinned deps / container image
claims/ # one entry per headline result:
fig4/ run.sh # → expected_output/, runtime + resource note
tab2/ run.sh
data/ # snapshots or synthetic substitutes (never raw victim traffic)
src/ # the code, with the dangerous parts gated (below)
ETHICS.md # disclosure status, gating rationale, usage boundaries
Give evaluators the shortest true path to each result. A "kick-the-tires" phase means the first five minutes decide the evaluator's mood — make the smoke test one command.
Packaging dangerous material responsibly
NDSS artifacts routinely include working exploits, attack tooling, or malware-adjacent code. This is allowed; unbounded release is not.
- Gate the weaponized parts. Ship the analysis and measurement pipeline openly; put live exploit modules behind documented access conditions or a defanged demonstration mode consistent with your Ethics Considerations section.
- Align with the disclosure clock. If a vulnerability is under a coordinated-disclosure embargo, the artifact's release timing must respect it — state the date the full module becomes available.
- Sandbox by default. Anything that touches a network should target a supplied local testbed, not the Internet, out of the box. Document the blast radius.
- No live victim data. Replace with prefix-preserved or synthetic traces carrying the
statistics the result needs (see
ndss-reproducibility).
When re-execution needs your lab
Hardware-bound results (SDRs, specific switches, IoT devices) cannot be reproduced by a committee at their desks. Bridge the gap: provide recorded traces plus a replay harness so the analysis is reproducible even when the capture is not, and say plainly in the README which results are trace-replayable and which need the physical setup. This commonly yields Functional + Reproduced-on-recorded-data rather than a failed full Reproduced.
The 2-page artifact appendix
Written after evaluation for the camera-ready. It states the badges earned, the artifact's scope, access instructions (the DOI), hardware/software requirements, and the mapping from paper claims to artifact components. Keep it factual and navigational — it is a map for future readers of the open-access paper, not a second results section.
Timing
The opt-in comes shortly after (conditional) acceptance and runs on its own schedule (2027 dates 待核实 — confirm on the Call for Artifacts). It overlaps the camera-ready window (Jan 6, 2027), so a team that starts packaging at acceptance, not at the AE deadline, avoids a two-front crunch.
Output format
[Badges targeted] Available / Functional / Reproduced — with feasibility per badge
[Package status] README / INSTALL / per-claim runners / data substitutes — done or gaps
[Danger handling] gated modules, sandbox default, disclosure-aligned release date
[Hardware gap] results needing physical setup + trace-replay bridge
[Appendix] 2-page artifact appendix drafted? claim→component map complete?
版本历史
- 9f86f09 当前 2026-07-19 17:05
