Every blog post on this site is published under one byline: Casper's Cloak Security Team. That's not a person. It's the engineers, analysts, and operators who actually build, monitor, and run the product. We share a byline because we share the work, and because in this category an individual byline tends to outlast the person's interest in being publicly associated with it.
What the team actually does
The work breaks roughly into four kinds. The same handful of people do all four of them — which is the only reason a small team can ship a product like this without it falling apart at the seams.
Threat intelligence and classifier work
Building, training, and re-training the machine-learning classifier that scores DNS queries against ~40 features in real time. Sourcing labeled training data (known phishing, malware C2, scam infrastructure, malvertising redirectors). Tuning false-positive rate against true-positive rate. Watching what the campaign operators do when their domains start getting blocked, and adjusting before the model goes stale.
Infrastructure and operations
The VPN data plane — WireGuard servers across multiple regions, the routing tables that get traffic in and out, the DNS resolvers (Unbound + Pi-hole with DNS-over-TLS upstreams), the firewall rules, the traffic shaping. The control plane that issues credentials, rotates keys, monitors session health, and handles failover. The handshake monitors and reconciliation jobs that quietly clean up after themselves so connections don't drift into ghost states.
Client engineering
The iOS, macOS, and Android apps. The Network Extension code on iOS, the VpnService integration on Android, the system network extension on Mac. The per-app routing layer. The threat-detection warning surface, override flow, and activity feed. The slow, careful work of making a VPN that doesn't drop your connection silently when you walk between buildings.
Writing
The blog you're reading. Most of it is explainer content for things we deal with day to day — how DNS-level filtering works, what App Tracking Transparency actually blocks, the architecture of the smishing campaigns we see in our threat data. We write the posts we wished existed when we were learning this material.
What we don't put in the bio
We don't publish names, headshots, prior employers, or specific credentials. That's a deliberate choice, not a side effect.
The shortest honest version: working on threat detection and adversarial infrastructure attracts the attention of people whose business depends on those things not being detected. We've watched colleagues at other organizations get doxxed, harassed, and SIM-swapped for being publicly associated with the same kind of work we do. The trade-off — a slightly harder time establishing personal credibility online — is, in our experience, more than worth it.
"Built by ghosts" is what we put on it. Read into the word what you want. Different people in different parts of the security field have meant different things by it, and we're comfortable letting the ambiguity sit.
How to evaluate writing from an anonymous byline
A reasonable concern: how do you trust an author whose name you don't know? Here's how we'd evaluate this writing if we were you.
- Specifics over generalities. If a post says "use a VPN to be safer", that's a vague claim. If it says "DNS-over-HTTPS closes ISP-level DNS snooping but leaves SNI leakage and IP-based destination identification, and breaks parental controls and split-horizon DNS in enterprises unless you allowlist your resolver" — that's a specific claim someone with operational experience would make.
- Honest about the product's limits. Our posts say what Casper doesn't do as often as what it does. We're not credible by accident — we'd lose technical readers in the first paragraph if we weren't.
- Critical of our own category. We publish posts critical of free VPNs (a category we technically compete in via our trial), and posts critical of DNS-only blockers (a category we compete with directly). If we only ever wrote pieces that flattered our own positioning, that would be a tell.
- Verifiable factual claims. Posts cite NIST, EFF, CISA, MITRE, FBI advisories, and primary sources. Where we cite our own internal data (median time-to-block, false positive rate, etc.) we say so explicitly so you can weigh it.
The byline doesn't establish authority. The writing has to. That's how we'd want it evaluated.
How to reach the team
For most things, the contact page. For corrections to anything on the blog — factual errors, broken links, things that should be updated — that's the same path. We do update posts when we get it wrong. The dateModified on the page schema reflects the actual revision date.
For security disclosures, the same address. We don't have a separate security@ team — every engineer reads disclosures, because at our size that's the only honest way to do it.