When you run an educational blog about programming and cybersecurity, the contact page is more than a formality. Readers send code questions, report broken lab setups, or ask for clarification on a Linux command. Some messages contain sensitive details—a vulnerability they discovered in a test environment, a question about their own security setup, or a request to remove a piece of code that accidentally included an API key. That means the way you reach us should be as secure as the topics we teach. Below is a practical breakdown of how to contact us, what happens after you send a message, and why we chose each channel.
Email with End-to-End Encryption
Plain email travels over the internet in the clear unless you wrap it in encryption. We accept messages at [email protected] (placeholder address), but we strongly encourage you to use our PGP key if your message contains anything you would not want a stranger to read. The key fingerprint is posted on our key server and verified through multiple social media accounts. If you are new to PGP, we have a short guide in our Best Ripple Wallets: Secure XRP Storage for Developers and Beginners article that explains the concept of public-key cryptography in a slightly different context—the same principle applies here.
To use PGP with us:
- Download our public key from a trusted key server (keys.openpgp.org).
- Verify the fingerprint matches the one posted on our X (formerly Twitter) profile and this blog’s footer.
- Encrypt your email body and any attachments using your email client (Thunderbird with Enigmail, or Mailvelope for webmail).
- Send the encrypted message to the address above. We will decrypt it on our side and reply with your public key if you include one, otherwise we will ask you to send one or use an alternative channel.
We check this mailbox twice a day on weekdays and aim to respond within 48 hours. If you need a faster answer, consider the next option.
Encrypted Web Form (No Logs)
For readers who prefer not to set up PGP, we offer a contact form served over HTTPS with a strict Content Security Policy. The form does not set any tracking cookies, and we do not log IP addresses permanently—the server retains connection metadata only for 24 hours for abuse prevention, after which it is purged. The form submission is encrypted in transit and stored in a database that is itself encrypted at rest. We read submissions from a dedicated, air-gapped terminal that never connects to the internet except to pull new messages once per day.
What to include in the form:
- A clear subject line (e.g., “Lab setup question: Wireshark filter not capturing” or “Possible typo in C memory management article”).
- Your email address (optional but recommended if you want a reply).
- Details of the issue, including the exact URL of the blog post if relevant.
- Do not paste passwords, private keys, or personal identification numbers. If you must share sensitive data, use the PGP email method above.
The form also includes a CAPTCHA that does not rely on Google services—we use a self-hosted, privacy-friendly alternative. This keeps your browsing habits away from third-party trackers.
Reporting a Security Vulnerability
If you find a security issue in one of our lab environments, a misconfiguration in our own server, or a vulnerability in a tool we recommend, please report it directly to [email protected] with the subject line starting with “[SECURITY]”. We have a responsible disclosure policy: we will acknowledge receipt within 72 hours, investigate, and fix the issue before publishing any details. We do not offer bounties, but we will credit you in a dedicated changelog post (with your permission) and link to your personal site or GitHub if you wish.
Do not test vulnerabilities against our live production server without prior written consent. Instead, replicate the issue in your own lab or use the dedicated test environment we describe in our article on Best Operating Systems for Ethical Hackers and Pentesters, which includes virtual machines designed for safe experimentation.
Mailing List and Newsletter
We also run a low-volume announcement list for new articles, security alerts, and lab updates. To subscribe, send an email to [email protected] with the word “SUBSCRIBE” in the subject line. You will receive a confirmation message; reply to it to verify your address. We use a double opt-in process, and you can unsubscribe with one click at any time. The mailing list is hosted on a server that does not share subscriber data with any third party.
If you have questions about the newsletter itself—frequency, content, or how we handle your email—use the contact form with “Newsletter question” as the subject.
Social Media and Comments
We maintain an active presence on Mastodon and a read-only mirror on X. Direct messages on Mastodon are end-to-end encrypted if both parties use a compatible client. We prefer Mastodon for quick, public Q&A because the conversation can help other readers. For private matters, please use email or the web form.
Comments on blog posts are moderated and require a valid email address (not published). We use a commenting system that does not embed third-party tracking. If you leave a comment that includes a code snippet, wrap it in
tags for readability. We will not edit your comment except to remove personal information accidentally left visible.
What We Do Not Accept
To keep our response time reasonable and our inbox clean, we do not accept:
- Unsolicited guest posts or link requests (we have a separate editorial process).
- Job applications (we are a small independent blog, not a company).
- Support requests for third-party tools (please contact the tool’s maintainer).
- Messages containing executable attachments or links to suspicious downloads—they will be deleted unread.
If you accidentally send something that violates these rules, no hard feelings. Just resend a clean version.
Response Times and SLA
We are a two-person team with day jobs in software development and security research. Here is what you can expect:
| Channel | Typical response time | Best for |
|---|---|---|
| PGP email | 24–48 hours | Sensitive data, vulnerability reports |
| Web form | 48–72 hours | General questions, corrections, feedback |
| Mastodon DM | 4–12 hours (weekdays) | Quick clarifications, public discussions |
| Blog comments | Within 24 hours (moderation) | Article-specific questions |
If you have not received a reply within the window above, check your spam folder. If it is not there, resend with a note that it is a follow-up.
One last concrete tip: before you contact us, search the blog for the topic. We have written extensively about common issues—from Java IDE setup on macOS to securing your Zeroconf network. The answer might already be there, and you will get it faster than waiting for a reply.
