What this report covers
This report enumerates, quarter by quarter, every request GhostShield has received from a government, law-enforcement agency, court of competent jurisdiction, civil litigant, or other party purporting to compel the production of user data. Each row shows the period, the count of requests, the count of legally-valid court orders, the count of users named in any request, and what data was actually produced.
The report covers calendar quarters, retrospectively. Q1 2026 covers January 1 through March 31. The Q2 2026 report (April 1 - June 30) will be published on or before 2026-07-15.
What we cannot produce
GhostShield is architected so that the following user data does not exist at any point in time:
- Browsing history — we do not log which sites or services a user connects to through the tunnel.
- DNS query history — we operate our own resolvers and they retain nothing.
- Connection timestamps — RAM-only servers retain no connection log after reboot, and the active in-memory state is not user-keyed.
- Originating IP addresses — we do not store the client IP that connected to the VPN.
- Bandwidth usage per session — we publish aggregated bandwidth but do not retain per-session usage tied to an account.
- Device fingerprints — the WireGuard handshake does not contain device-identifying information, and we strip the optional client identifier on connection.
What we can produce, if compelled
The data that does exist, by necessity, is:
- Account email — required for sign-in and customer-service communication.
- Payment-method metadata — required by our payment processors (Stripe, etc.) for chargeback handling. We do not see card numbers; the processor does.
- Subscription state — active / cancelled / billing date.
- Customer-support correspondence — emails the user sent us, retained for the duration of the support cycle.
None of the above can link to a specific VPN session, exit IP, or destination — the linkage simply does not exist on our side.
Quarterly history
| Quarter | Requests | Court orders | Users named | Produced |
|---|---|---|---|---|
| Q1 2026 | 0 | 0 | 0 | None |
Process when a request arrives
Where a request arrives — from a law-enforcement agency, court, or other party — GhostShield's process is:
- Receive and log. Every request is logged with timestamp, originating jurisdiction, and the specific data requested. The log is retained for the duration of any active litigation plus seven years.
- Validate the legal basis. Subpoenas issued without an underlying warrant or court order are rejected by counsel. National Security Letters (US) and equivalents are evaluated against the constitutional and statutory limits of the issuing jurisdiction.
- Notify the user. Unless prohibited by a gag order, we notify the affected user of the request and give them an opportunity to challenge it before any data is produced.
- Produce only what exists. Because the architecture does not retain VPN-session data, the most we can ever produce is the account-level data enumerated above.
- Disclose in the next transparency report. The request, the response, and the outcome appear here within the next quarterly report (subject to any active gag order).
Warrant canary
A warrant canary is a published statement that we have not received a particular kind of order (typically a National Security Letter or its equivalent). If the canary is removed or the dated statement is no longer updated, an alert reader can infer that we received such an order even where a gag order would prevent us from saying so directly.
The GhostShield warrant canary lives at /warrant-canary. It is updated daily and signed by the security team. The canary covers:
- No National Security Letter has been received.
- No gag order is in effect.
- No request for back-door access has been received.
- No order has compelled the modification of our software or infrastructure.
Public-interest litigation
Where the legal basis for a request appears unsound but a court ruling would be helpful for the wider industry, we will join EFF or another civil-liberties organisation as amicus to challenge it. Costs are absorbed as part of our compliance budget.
Independent verification
The infrastructure claims in this report (RAM-only servers, no-logs architecture) are subject to third-party audit per /audits. The first such audit is scheduled for Q2 2026 with Cure53. The audit report will be linked from this page.
FAQ
Does “zero requests” mean GhostShield is not credible enough to attract one?
It means we are early. GhostShield launched in 2025 and the user base is still small. Almost all law-enforcement requests against VPN providers target either large user bases or specific known accounts that have generated other evidence. As we grow, the count will become non-zero — what matters is that the data we can produce will remain effectively nil because of the architecture.
What about secret orders that GhostShield is gagged from disclosing?
That is what the warrant canary is for. If a gag order prevents us from saying we received a secret request, we will stop signing the canary. Readers who notice the canary go stale can infer the existence of an order even where we cannot describe it.
Have other VPNs been compelled to produce data despite no-logs policies?
Yes — at least two well-known cases. In 2017 and 2020, US-based VPN providers PureVPN and IPVanish handed over connection logs they claimed not to retain. The difference between those providers and GhostShield is architectural: their servers had persistent disks; ours do not.
When is the next transparency report published?
Q2 2026 will be published on or before 2026-07-15. Subsequent quarterly reports follow a 14-day post-quarter publication target: Q3 on or before 2026-10-15, Q4 on or before 2027-01-15.