I do security research for a living, so I’d rather hear about a problem in my own things
than not. If you’ve found something, this page tells you how to reach me and what to
expect.

The machine-readable version is at
/.well-known/security.txt.

How to reach me

Email: carl.sampson@gmail.com

Encryption: For anything sensitive, encrypt to my PGP key — the key and fingerprint
are on the GPG page. I’d rather you over-encrypt than send something in the clear
you later wish you hadn’t.

I’m one person, not a security team. There’s no ticketing system behind this, so plain
email is the fastest path.

Scope

In scope

Out of scope

  • The .fyi network sites — those are separate properties; report those to the contact
    listed on the site in question
  • Anything belonging to my employer. If it’s a Microsoft product or service, please go
    through MSRC instead. I can’t act on those reports
    here and routing them through me only slows you down.
  • Third-party services this site depends on (the host, the CDN, the comment system
    upstream). Happy to forward, but they’ll respond faster than I can relay.

Findings I’m unlikely to act on

This is a static site. Reports that amount to a missing header with no demonstrated
impact, a rate-limit observation on a page with no state, SPF/DMARC opinions unrelated to
a real spoofing path, or raw scanner output with no analysis, will get a polite reply and
not much else. If you can show me impact, I’m interested regardless of category.

What to include

What you did, what happened, and what you expected instead. A request and response pair,
or a short script, beats a screenshot of a scanner verdict. If you’re not certain
something is real, send it anyway — I’d rather read a false positive than miss a genuine
issue.

What you can expect from me

  • An acknowledgement that I’ve received it, and a straight answer on whether I think it’s
    a genuine issue
  • A fix, or an explanation of why I’m not fixing it — I won’t leave you guessing
  • Credit in the commit or write-up, unless you’d prefer to stay anonymous. Tell me how
    you’d like to be named
  • No legal threats, and no attempt to silence you

I don’t run a paid bounty and can’t offer money. What I can offer is a fast reply and
honest attribution.

What I ask of you

  • Give me a reasonable chance to ship a fix before you publish. I’m not going to hold you
    to an arbitrary deadline, and I’d rather agree on timing together than have a fight
    about it later
  • Don’t access, modify, or delete data that isn’t yours. If you stumble into someone
    else’s data, stop and tell me what you saw
  • Don’t degrade the service for other people. Automated scanning is fine; hammering the
    site until it falls over is not
  • No social engineering, phishing, or physical attacks against me or anyone else

Safe harbor

If you follow this policy in good faith, I will not pursue or support legal action against
you for your research, and I’ll treat your work as authorized. If a third party takes
action over something you did while following this policy, I’ll make it known that you
were acting within it.

Good faith is the operative phrase, and I’m not going to pretend I can define every edge
of it in advance. If you’re unsure whether something is in bounds, ask me first — that
conversation has never once gone badly.

When I’m the one reporting

The reverse case, for anyone curious how I handle findings in your code: I report
privately first and don’t publish until a fix is available. No deadline theatrics, no
dropping details to make a point. If you’re engaging in good faith I’ll wait as long as
the work honestly takes. If you go quiet on something users are exposed to, I’ll say that
publicly before I say what the bug is.

Fixed, published work is on the research page.