PhantomSecure started with a problem I knew firsthand: protecting sensitive work on a Mac without sending that work somewhere else for analysis. The suite is still in development, and no module is available to users yet.
The current PhantomVault design uses AES-256-GCM for Vault contents, with optional ML-KEM-1024 Dual-Key Protection around the random Vault key. I won’t present a security claim as verified until it passes the matching tests on a release candidate.
The problem that stayed with me
The first idea came from my time working for an NGO in the Middle East. I traveled with sensitive documents, and our team relied on TrueCrypt because those files needed more protection than a Mac login password.
Years later, after TrueCrypt was discontinued, I came back to that experience. VeraCrypt carried the encrypted-container model forward, but I wanted a tool designed around the Mac from the start. That became PhantomVault.
PhantomVault encrypts Vault contents with AES-256-GCM in the current design. Optional Dual-Key Protection uses NIST-standardized ML-KEM-1024 to add a second cryptographic requirement around the random Vault key. PhantomWipe came from a related question: what can a deletion tool honestly promise on an SSD versus a magnetic disk? Its methods and results have to reflect the storage in use, including what macOS and the hardware cannot verify.
Why PhantomProtect exists
If PhantomVault is the safe, PhantomProtect is the guard dog. Part of that idea came from JARVIS in Avengers: Age of Ultron. I’m not trying to build science fiction. What stuck with me was the idea of a system that could look at several clues before it explained or blocked something.
Signatures are useful for known malware. Behavior, reputation and network context can provide more evidence when an activity is unfamiliar. PhantomProtect is meant to bring those signals together, but whether a build catches a particular scenario has to be established through testing.
Privacy has to be specific
Security software asks for unusually sensitive permissions, so I don’t think saying a product is “private” is enough. You should be able to see what stays on your Mac, what needs to contact a service and what is optional.
For PhantomSecure, that means drawing those boundaries in the product and in the documentation:
- Local-first protection: Core analysis is designed to run on your Mac. Account, subscription, update and threat-intelligence requests are documented separately from local analysis.
- Optional telemetry: Product analytics, threat-improvement data, performance metrics and crash diagnostics are intended to remain off until you explicitly enable the corresponding category. The telemetry definition explains how that differs from required service traffic.
That is less catchy than an all-local slogan, but it is more useful. Sensitive analysis can stay local while necessary service connections remain visible and documented.
Why I changed the network architecture
Earlier prototypes used a local VPN-style packet tunnel. As the suite grew, I moved the design to Apple’s Network Extension content and URL filtering APIs. That lets PhantomSecure work through Apple-supported interfaces without creating a separate VPN route.
The filters can evaluate connection metadata and any URL context macOS makes available. A connection that matches enabled local policy or current threat intelligence can be allowed or blocked. Coverage still depends on permissions, component health, API visibility and the intelligence available at that moment. Performance and protection results will be measured on the final release candidate.
What I’m working on now
Right now the work is less glamorous: performance tests, permission failures, cryptographic validation, telemetry consent and making sure the website says only what a release can prove.
Shared learning remains a research idea, not a promised feature. If it ever ships, it will be opt-in, and its data fields, privacy properties and limitations will be documented and tested first.