Our transparency-reporting framework: what we’ll publish, and how to read any VPN’s report

TuxlerVPN Mobile has not yet launched publicly, so there is no transparency report yet. There is, instead, a framework and commitment describing what we will publish, on what cadence, and what each report will and will not cover. This post is the long-form explanation of that framework. Why we picked the categories we did, what a number on a transparency report can and cannot demonstrate, and how to read any VPN’s report once one exists.

What a transparency report is supposed to do

A transparency report is a periodic, structured disclosure of how often a service was asked to hand over user data, by whom, under what legal process, and what was actually produced. The reason it exists, in our view, is to make a service’s behavior under legal pressure something a reader can compare and audit, rather than something they have to take on faith.

There are three failure modes that make a transparency report less useful than it looks:

• Vague counts. “We received some requests this period and complied with most.” This tells you nothing. A useful report breaks counts down by category and reports both received and complied-with figures.
• Scope-shifting. A report that quietly excludes the categories that would generate non-zero numbers. The most common version is “this report covers requests served on us directly” without saying anything about requests served on processors, payment partners, or upstream infrastructure providers.
• No methodology. A report that gives you numbers without telling you how requests are intaken, evaluated, or counted. Without that, the numbers are not reproducible by anyone, including the company itself a year later.

We tried to address each of these in the framework that will govern our reports. The categories will be listed individually with both received and complied-with columns. The scope will be named explicitly. The methodology section is published in advance, on the framework page, so readers can interrogate it before there is anything to count.

The schema we will report against

Reproduced from Transparency Report:

Category	Received	Complied with	Data produced
Court orders (Panama)	n/a	n/a	n/a
MLAT / letter-rogatory requests (foreign)	n/a	n/a	n/a
Subpoenas / civil process	n/a	n/a	n/a
National security demands	n/a	n/a	n/a
Emergency disclosure requests	n/a	n/a	n/a
DMCA-related disclosures resulting in user-data release	n/a	n/a	n/a
Abuse-related disclosures resulting in user-data release	n/a	n/a	n/a

The placeholders fill in when the first reporting period closes. There are three things going on in this schema that are worth being explicit about now, before any number lands in the table:

1. The controller is in Panama. Tuxler Digital Services Corp. is incorporated in Panama, and the report will count requests served on that entity. Foreign requests reach Panama via the MLAT (Mutual Legal Assistance Treaty) channel through Panama’s central authority, or via letter-rogatory.
2. “Served directly” is a deliberate scope. Counts will reflect requests served on Tuxler Digital Services Corp. They will not include requests served on Google for Play billing identities, on Sentry for crash records, or on cloud infrastructure providers behind apivpn.tuxlervpn.app. Those parties report under their own processes.
3. Whatever is produced is bounded by what we retain. Even if a hypothetically valid request arrives, the data we can produce is bounded by what we retain, and the retention list, in Logging & Retention Data, is short by design.

What the report won’t cover

The scope-note in the framework names three things explicitly. They are worth re-naming here:

• Google Play billing requests. When a user upgrades to Premium, the transaction is between the user and Google Play. Google holds the Play account email and payment record. We hold a Play purchase token used for entitlement verification only. Requests to Google for Play account identities are reported in Google’s own transparency reports.
• Processor-only requests. Sentry, our customer-support delivery provider, our web hosting provider, and our cloud infrastructure providers are processors as defined in Data Processing Overview. Each operates under its own legal processes and publishes its own reports where applicable. A request served on Sentry that we never see will not appear in our number.
• Gateway-provider requests. Where a request reaches an individual VPN gateway server provider directly without also being served on Tuxler Digital Services Corp., we will not have insight into it. The mitigation is structural: TuxlerVPN Mobile gateways are designed not to retain content or per-session metadata after disconnect (Privacy Policy §2.6), so even where such a request reached a gateway, the data available to be produced is limited.

This is what we mean by saying that any future “zero” will be meaningful only in context. A zero across our directly-served categories, combined with a short retention list at processors, is a different claim from “zero requests anywhere in the world touching anything related to TuxlerVPN Mobile.” We will be able to make the first claim if it is true. We will not make the second.

How to read any VPN’s transparency report

A short checklist that is independent of which provider you are reading:

1. Jurisdiction. Where is the controller incorporated, and which legal-process channels apply? A report that does not name a jurisdiction is not yet a report.
2. Methodology. How are requests intaken, evaluated, and counted? Is the intake address named?
3. Processor scope. Does the report distinguish between “served on us directly” and “served on a processor”? Vague reports merge these. Honest reports separate them.
4. Retention floor. What can the provider technically produce, given what they retain? A “zero produced” claim against a long retention list is a much weaker signal than a “zero produced” claim against a short retention list.
5. Cadence. Is there a stated period and a stated next report? One-off reports are easier to publish than sustained quarterly cadence.

Apply that checklist to ours, once it exists, and to anyone else’s. The point is to make the comparison legible.

Cadence

Once the app has launched, our first Transparency Report will cover the period from public launch through the close of the next calendar quarter, and will be published within sixty days of that close. Reports thereafter will cover three-month calendar quarters on a quarterly cadence. We plan to keep the same structure and the same scope notes, so reports across periods are directly comparable.

FAQ

Why publish a “framework” before there is anything to report?

Because the methodology, categories, and scope notes are the part a reader can audit. Publishing them before any number lands in the table makes the eventual numbers harder to quietly tune.

What will a future “zero” mean?

It will mean that during the reporting period, Tuxler Digital Services Corp. received no formal data requests in the listed categories, and produced no user data in response to any external demand. It will not mean that no request has ever touched any party in our supply chain.

Why not include processor-served requests in your number?

Because we would not see them. Including them would require us to claim visibility we do not have. Sentry, our web hosting provider, our customer-support provider, and our cloud infrastructure providers each publish their own reports where applicable.

What can you actually produce if a valid request arrives later?

Only what we retain. Currently a short list documented in Logging & Retention Data. VPN-session data is discarded on disconnect (Privacy Policy §2.6). The Law-Enforcement Request Policy describes how we evaluate requests and when we notify affected users.