Vulnerability Disclosure Policy

1. About This Policy

WSNY332 is a personal, non-commercial GMRS and personal radio notebook run by one operator. This policy tells security researchers what we would like tested, how to send us what you find, and what we will do about it. We would rather hear about a problem from you than read about it somewhere else later.

This policy covers wsny332.com only. Our sister notebooks, OpenRF Note and KM7HQX, publish their own policies at their own security pages.

2. Authorization

If you make a good faith effort to comply with this policy during your security research, we will consider your research to be authorized, we will work with you to understand and resolve the issue quickly, and we will not pursue or support legal action against you related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this policy, we will make this authorization known.

3. Guidelines for Research

Under this policy, “research” means activities in which you:

• Notify us as soon as possible after you discover a real or potential security issue.
• Make every effort to avoid privacy violations, degradation of the reading experience, disruption to production systems, and destruction or manipulation of data.
• Only use exploits to the extent necessary to confirm that a vulnerability is present. Do not use an exploit to compromise or exfiltrate data, establish persistent access, or pivot to other systems.
• Give us a reasonable amount of time to resolve the issue before you disclose it publicly.
• Do not submit a high volume of low-quality reports.

Once you have established that a vulnerability exists, or you encounter any sensitive data — including personal information belonging to readers or supporters — stop testing, tell us immediately, and do not disclose that data to anyone else.

The following test methods are not authorized:

• Denial of service (DoS or DDoS) testing, or any other test that impairs access to the site or damages data.
• Physical testing, social engineering (phishing, vishing, pretexting), or any other non-technical attack.
• Attacks against radio systems: jamming, deliberate interference, deauthentication, packet injection, or replay attacks against any station or network. This notebook documents passive monitoring and bench testing. It does not authorize offensive RF activity, and most of it is illegal under FCC rules regardless of intent.

4. Scope

In scope:

• The public site at wsny332.com, including every page and static asset it serves.
• The contact form and the edge Worker endpoints behind it.
• The Patreon supporter login flow at /api/auth/patreon/*, including the signed session cookie it issues.

Out of scope:

• Our hosting and platform providers. Cloudflare, Patreon, and GitHub each run their own disclosure programs — report issues in their products to them, not to us.
• Any other domain, subdomain, host, or service not named above.
• Physical radio equipment, licensed stations, and anything transmitted over the air.

If you are not sure whether something is in scope, ask at security@wsny332.com before you start.

5. Findings We Do Not Accept

Reports consisting only of the following will be closed without a detailed reply:

• Automated scanner output with no demonstrated impact.
• Missing security headers, absent rate limiting, or TLS configuration preferences, with no working exploit attached.
• SPF, DKIM, or DMARC observations on hostnames that do not send mail.
• Self-XSS, clickjacking on pages with no state-changing action, or anything that requires an already-compromised browser or device.
• Version-number fingerprinting and other best-practice advice unaccompanied by a vulnerability.

There is no bug bounty here and no payment of any kind. Submitting a report means you accept that.

6. Reporting a Vulnerability

Email security@wsny332.com. Reports may be submitted anonymously — we do not require your name and there is no account to create. If you do share contact information, we use it only to correspond with you about your report.

We do not support PGP-encrypted email. Send plain text, and leave out anything you would not want sitting in a mailbox.

To help us reproduce and fix the issue, please include:

• Where you found it, and what someone could actually do with it.
• The steps to reproduce, in enough detail that we can follow them. Screenshots or a short proof of concept help.
• English, if you can manage it.

Information you send is used for one purpose: fixing the problem. If your finding turns out to affect a third-party product rather than this site, we may pass the technical details to that vendor. We will not share your name or contact details with anyone without your permission.

7. What You Can Expect From Us

If you give us a way to reach you:

• We will acknowledge your report within five business days. This is a one-person notebook rather than a staffed security team, and five days is what we can honestly promise.
• We will tell you whether we could reproduce the issue and what we intend to do about it, including when something is going to take a while.
• We will keep the conversation open until the issue is resolved.

In return we ask for a reasonable window to ship a fix before you publish. If we go quiet, say so — a nudge is fair.

8. Acknowledgments

We cannot pay for reports. What we can offer is credit. Report a valid issue, tell us you would like to be named, and we will list you here under whatever name or handle you prefer, with a link if you want one. Prefer to stay anonymous? Say so and we will leave you off.

No reports have been acknowledged yet.

9. Questions & Revisions

Questions about this policy, or suggestions for improving it, are welcome at security@wsny332.com or through our contact form.

Machine-readable contact details for this site are published at /.well-known/security.txt, following RFC 9116.

• Version: 1.0 — September 19, 2026 (first issuance)
• Security contact: security@wsny332.com
• General contact: info@wsny332.com