Hacker Ethics & Disclosure Policy

We publish research, tool reviews, and conference coverage. But we don’t publish everything we find. Some things stay in the lab, some get reported upstream, and some hit our editorial queue only after a fix ships. This page explains how we decide which is which.

Responsible disclosure is the baseline

If we uncover a vulnerability during our own research, or if someone submits one to us, our first step is always to contact the vendor or maintainer directly. We give them a reasonable window to patch—typically 45 to 90 days, depending on severity and responsiveness. We don’t publish technical details before a fix is available. We don’t name and shame for sport.

That said, we’ve seen vendors ghost researchers. If we go silent and the clock runs out with no patch and no communication, we’ll publish a limited advisory. We’ll include just enough detail for defenders to assess risk, not enough for someone to weaponize it.

Ethical lines we don’t cross

We don’t publish exploit code that targets critical infrastructure, medical devices, or anything that could cause physical harm. We don’t dox people. We don’t publish leaked credential dumps or full PII sets. If we get something like that in a submission, we delete it and note the source.

We also won’t write up a bug just because it’s flashy. Our editorial bar is simple: does this teach something useful? If it’s just a race condition in a niche plugin nobody uses, we might pass. If it’s a pattern that shows up across ten frameworks, we’ll write it up as a defensive piece instead of a disclosure.

How we handle reader submissions

• We verify before we publish. We don’t run unverified claims. Send us a PoC or a clear reproduction path, or we won’t run it.
• We protect sources. You can submit anonymously. We won’t share your identity without consent, even if the vendor pushes back.
• We credit fairly. If we publish something based on your research, we name you or your handle unless you ask us not to.

When we do publish offensive content

Some of our articles include working PoCs or exploitation techniques. We publish those when the technique is already public knowledge, when the affected software is abandoned, or when the defensive value outweighs the risk. Every one of those pieces goes through a second editorial review from someone who wasn’t involved in writing it.

If you see something in our archive that you think crosses a line, tell us. We’ll take a hard look at it and pull it if it doesn’t meet the standard we just described.

This policy applies to everything on QuahogCon—conference talks we cover, tool reviews we write, and research we publish ourselves. It’s not a press release. It’s how we actually work.