IEEE S&P Experiments

SkillDev tools

Use when designing or auditing the evaluation of an IEEE S&P (Oakland) paper, including end-to-end attack demonstration, adaptive-adversary evaluation of defenses, measurement sampling and validity, baselines and ablations, statistical reporting of attack success, and the ethics constraints that shape what experiments are permissible.

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the IEEE S&P Experiments skill

What this skill tells your AI

The instructions your AI receives, as published by brycewang-stanford/awesome-journal-skills in IEEE-SP-Skills/skills/ieeesp-experiments/SKILL.md and read by ahel’s review.

Use this to build or audit the evidence an S&P paper stands on. The venue's reviewers are professional adversaries; an evaluation that would satisfy a systems or ML PC often leaves an Oakland reviewer's central question — "does this survive a real, adaptive attacker?" — unanswered.

Match the evaluation to the contribution type

ContributionEvaluation that closes the loopFatal gap
AttackEnd-to-end demonstration against a realistic, current targetToy target; unrealistic preconditions
DefenseAdaptive adversary who knows the design; cost/overheadOnly non-adaptive or prior attacks
MeasurementRepresentative sampling + validation + ethicsConvenience sample presented as population
SystemSecurity property demonstrated and performanceProperty asserted, not tested
SoKSystematic re-analysis under one frameworkCherry-picked coverage

The adaptive-adversary rule dominates defense papers

A defense evaluated only against existing or non-adaptive attacks is the most common S&P defense rejection. The standard:

  • Define the adaptive adversary explicitly: knows the mechanism, the parameters, and the deployment.
  • Show your defense against attacks designed to break it, not just yesterday's attacks it happens to stop.
  • Report the cost of adaptation for the attacker and the overhead for the defender — both are part of the security claim.
  • If a class of adaptive attack is out of scope, say so in the threat model and own the boundary; do not leave it for a reviewer to discover.

Measurement validity is an evidence question and an ethics question

For measurement papers, the sampling story and the ethics story are the same paragraph in reviewers' minds:

  • State the population, the frame, and the sampling method; quantify coverage and bias.
  • Validate a subsample by an independent method where possible.
  • Active measurement (scanning, probing) must respect opt-out norms, rate limits, and the ethics record (ieeesp-review-process) — an experiment that harms the systems it measures is a reject regardless of results.
  • Human-subjects components need IRB determination before running, not a post-hoc note.

Statistics for attacks and fuzzing

Security evidence is often probabilistic and gets held to a real bar:

Attack-success reporting:
  n trials (state n) · success rate ± dispersion · target set described
  → "worked" without n is an anecdote, not a result

Fuzzing / bug-finding comparison (the field's known pitfalls):
  - equal budgets (CPU-time, not wall-clock)
  - ≥ 5–10 campaigns per configuration; report variance
  - identical seed corpora across compared tools
  - a ground-truth or triage method for "unique" bugs
  → a single-run bug count comparison is not evidence of superiority

Timing / side-channel:
  noise floor stated · machine quiescence (isolated cores, freq pinning)
  · distinguisher's statistical test named

Baselines and ablations Oakland reviewers ask for

  • The strongest prior attack/defense, at its best configuration, not a weakened reimplementation.
  • An ablation isolating the component you claim is responsible for the security gain.
  • A cost baseline: what does the attacker/defender spend, and is it realistic at the claimed scale?
  • Negative results where they bound the claim (attack fails against target class Y — state it; it strengthens the scoped claim).

Ethics as an experimental design constraint, not an afterthought

Some experiments are simply not runnable as first imagined:

  • Testing an exploit against live third-party systems without authorization is out; build a representative testbed instead.
  • Collecting user data beyond what the IRB and the ethics record cover is out.
  • Disclosure timing constrains when certain measurements can be published — design the timeline so the evidence and the fix do not collide (ieeesp-reproducibility).

Audit worksheet

For each experiment:
  claim it supports | contribution type | adaptive adversary evaluated? |
  strongest baseline used? | n trials + dispersion | ethics clearance |
  realistic target? | rerunnable? (→ ieeesp-reproducibility)
Flag any row with: non-adaptive-only defense · anecdotal success rate ·
  weakened baseline · unmet ethics precondition

Output format

[Contribution type] attack / defense / measurement / system / SoK
[Loop closed?] <the demonstration/eval that proves the claim> ✓/✗
[Adaptive adversary] evaluated ✓/✗/n-a — scope stated?
[Baselines] strongest prior used ✓/✗ · ablation ✓/✗ · cost baseline ✓/✗
[Statistics] trials+dispersion ✓/✗ · fuzzing pitfalls avoided ✓/✗/n-a
[Ethics preconditions] IRB ✓/✗/n-a · authorization ✓/✗ · disclosure timing ok ✓/✗

Signals

GitHub stars
1k
Forks
155
Last commit
Sep 2026
Advanced
Item type
skill
Key
ieeesp-experiments
Source
github.com/brycewang-stanford/awesome-journal-skills