Transparency Report
Table of Contents
- About This Report
- Executive Summary
- Warrant Canary
- Law Enforcement Requests
- Government Requests by Type
- International Requests
- Emergency Disclosure Requests
- Data Actually Produced
- Requests Rejected or Challenged
- Infrastructure and Operations
- Security Incidents
- Service Availability
- Software Updates and Audits
- Methodology and Verification
- Report Archive
- Contact
Commitment: This transparency report is published semi-annually in accordance with our Law Enforcement Guidelines (Section 13). We commit to publishing these reports within 45 days of the end of each reporting period. All reports are permanently archived on our website and in our GitHub repository. We believe that transparency is not a marketing exercise but a fundamental obligation to our users.
1. About This Report
This is the inaugural Transparency Report for SimpleGo’s SMP relay server infrastructure. It covers the period from March 1, 2026 (the date our servers became publicly available) through August 31, 2026. Future reports will cover January 1 through June 30 (H1) and July 1 through December 31 (H2) of each calendar year.
This report documents all interactions with law enforcement and government agencies, all security incidents affecting user data or service availability, operational statistics about our infrastructure, and the status of our warrant canary. This report is also available as a signed, machine-readable JSON file in our GitHub repository for independent verification.
2. Executive Summary
During this reporting period, SimpleGo received zero requests from law enforcement agencies, government authorities, or any other parties seeking user data, traffic data, or content data. No data of any kind was produced to any third party. The warrant canary remains intact.
3. Warrant Canary
Warrant Canary Statement
As of the date of publication of this report, IT and More Systems (SimpleGo) affirms:
We have not received any National Security Letters (or equivalent German instruments under § 99 TKG or BND-Gesetz) that include a gag order or non-disclosure requirement.
We have not received any court orders under seal that prohibit us from disclosing their existence.
We have not received any requests from intelligence agencies (BfV, BND, MAD, or foreign equivalents) for access to user data or server infrastructure.
We have not been compelled to install backdoors, weaken encryption, or modify our software at the request of any government agency.
We have not been subject to any secret court proceedings that restrict our ability to report on government requests.
Verify: git log --format='%H %s' | grep 'transparency-h1-2026'
This warrant canary is updated with each semi-annual report. If a future report omits this canary statement, or if its language changes materially, users should consider the possibility that we have received a secret order that prohibits disclosure. The canary mechanism provides transparency where direct disclosure is legally prohibited. We commit to publishing each report’s SHA-256 hash in a signed Git commit to prevent retroactive modification.
4. Law Enforcement Requests
| Request Category | Received | Complied (Full) | Complied (Partial) | Rejected | Withdrawn |
|---|---|---|---|---|---|
| Bestandsdaten (§ 174 TKG / § 100j StPO) | 0 | 0 | 0 | 0 | 0 |
| Verkehrsdaten (§ 175 TKG / § 100g StPO) | 0 | 0 | 0 | 0 | 0 |
| TKÜ Orders (§ 100a StPO) | 0 | 0 | 0 | 0 | 0 |
| Preservation Requests | 0 | 0 | 0 | 0 | 0 |
| Server Seizure (§ 94 StPO) | 0 | 0 | 0 | 0 | 0 |
| Emergency Disclosures | 0 | 0 | 0 | 0 | 0 |
| BKA Requests (§§ 10-12 BKAG) | 0 | 0 | 0 | 0 | 0 |
| State Police (Landespolizeigesetze) | 0 | 0 | 0 | 0 | 0 |
| Informal/Voluntary Requests | 0 | 0 | 0 | 0 | 0 |
| Total | 0 | 0 | 0 | 0 | 0 |
5. Government Requests by Type
5.1 By requesting authority
| Authority Type | Requests |
|---|---|
| German Federal Prosecutors (Generalbundesanwalt) | 0 |
| State Prosecutors (Staatsanwaltschaft) | 0 |
| Federal Criminal Police (BKA) | 0 |
| State Criminal Police (LKA) | 0 |
| Local Police (Polizei) | 0 |
| Federal Intelligence (BfV/BND/MAD) | 0 |
| Foreign Authorities (via MLA) | 0 |
| Other German Authorities | 0 |
| Direct Foreign Requests (rejected) | 0 |
5.2 By alleged offense category
No requests were received during this period. In future reports, this section will categorize requests by the type of criminal offense alleged in the underlying investigation (where disclosed), such as: terrorism (§§ 89a, 129a, 129b StGB), child sexual abuse (§§ 176, 184b StGB), organized crime (§ 129 StGB), narcotics (BtMG), cybercrime (§§ 202a-c, 303a-b StGB), fraud (§ 263 StGB), or other offenses.
6. International Requests
| Channel | Requests Received | Executed |
|---|---|---|
| MLAT (Mutual Legal Assistance Treaty) | 0 | 0 |
| European Investigation Order (EIO) | 0 | 0 |
| Letters Rogatory (Rechtshilfeersuchen) | 0 | 0 |
| Direct Foreign Requests (invalid channel) | 0 | 0 |
No international requests were received during this reporting period. As documented in our Law Enforcement Guidelines (Section 7), direct requests from foreign authorities are not accepted. All international requests must be routed through proper mutual legal assistance channels.
7. Emergency Disclosure Requests
No emergency disclosure requests involving imminent danger to life or physical safety were received during this reporting period. Our emergency process is documented in our Law Enforcement Guidelines (Section 6).
8. Data Actually Produced
| Data Type | Items Produced |
|---|---|
| Decrypted message content | 0 |
| User identity information | 0 |
| IP address logs (historical) | 0 |
| IP address logs (prospective) | 0 |
| Encrypted message blobs | 0 |
| Queue metadata | 0 |
| Server configuration data | 0 |
| Null responses (no data available) | 0 |
No data of any kind was produced to any law enforcement or government authority during this reporting period.
9. Requests Rejected or Challenged
No requests were rejected during this period. In future reports, this section will document, in anonymized form, any requests that were rejected and the legal reasoning for rejection. This may include: requests lacking a valid legal basis, requests lacking required judicial authorization, overly broad requests, requests for technically impossible data (e.g., decrypted content), or requests from foreign authorities not routed through proper channels. Where we challenge a request in court, we will document the outcome (to the extent permitted by law).
10. Infrastructure and Operations
10.1 Server infrastructure
| Metric | Value |
|---|---|
| Number of SMP relay servers | 2 (1 clearnet + Tor, 1 Tor-only) |
| Server locations | Germany (IONOS SE, Montabaur/Frankfurt) |
| Hosting provider | IONOS SE (Art. 28 GDPR DPA in place) |
| Full-disk encryption | Yes (LUKS) |
| Tor onion services | Active |
| IP logging (default) | Disabled |
| Server software | smp-server (SimpleX project, AGPL-3.0) |
10.2 Software versions deployed
The specific SMP server software versions deployed during this reporting period will be documented here, including dates of any updates. All versions are verifiable against the public SimpleX Chat GitHub repository.
11. Security Incidents
No security incidents affecting user data, service integrity, or server security occurred during this reporting period.
In future reports, any security incidents will be documented with: a description of the incident, the date of discovery and resolution, the scope of impact (number of affected queues/users if determinable), the root cause (if known), the remediation steps taken, and any notification actions under Art. 33/34 GDPR.
We define “security incident” broadly to include: any unauthorized access to server infrastructure, any data breach or unintended data exposure, any vulnerability exploitation (successful or attempted), any service disruption caused by malicious activity, and any compromise of cryptographic material (TLS certificates, server keys).
12. Service Availability
Service availability statistics for this reporting period will be documented here, including: total uptime percentage per server, number and duration of unplanned outages, number and duration of planned maintenance windows, and any outages caused by external factors (hosting provider, network).
13. Software Updates and Audits
13.1 Security audits
The SimpleX Protocol’s SMP component was reviewed by Trail of Bits in July 2024 (cryptographic design review). No audit of SimpleGo’s specific server deployment has been conducted during this reporting period. We will document any future audits, their scope, and their findings here.
13.2 Dependency updates
Critical security updates to dependencies (operating system, SMP server software, TLS libraries) will be documented here with dates and CVE references where applicable.
13.3 SimpleGo firmware
Significant security-relevant updates to the SimpleGo hardware firmware will be noted here, with version numbers and changelog references.
14. Methodology and Verification
14.1 How this report is compiled
This report is compiled from internal records maintained by the operator (Sascha Dämgen, IT and More Systems). All law enforcement interactions are logged in a secure, internal record-keeping system at the time they occur. Statistics are aggregated from these records at the end of each reporting period.
14.2 Independent verification
Each transparency report is published with a SHA-256 hash committed to our public GitHub repository. This ensures that published reports cannot be retroactively modified without detection. The Git commit history provides a tamper-evident log of all publications. The JSON machine-readable version of this report is signed with our PGP key (to be published on our website and major keyservers).
14.3 Legal limitations on disclosure
German law may in certain circumstances prohibit the disclosure of specific details about law enforcement requests (e.g., details of ongoing investigations). Where such restrictions apply, we will note their existence and legal basis without disclosing the restricted information. The warrant canary mechanism (Section 3) provides a secondary transparency channel for situations where direct disclosure is prohibited.
14.4 Report format
This report is published in three formats: this HTML page (human-readable, bilingual), a JSON file in our GitHub repository (machine-readable, for automated monitoring), and a PDF archive (for permanent record-keeping). All formats contain identical data. Historical reports remain permanently accessible at their original URLs.
15. Report Archive
H1 2026 (March 1 – August 31, 2026)
Published: September 2026 (scheduled)Inaugural report. Zero requests received. Warrant canary intact.
All historical reports are permanently available in our GitHub repository at github.com/saschadaemgen/SimpleGo/tree/main/legal/transparency.
16. Contact
Questions about this report: legal@simplego.dev
PGP key: [To be published]
Report verification: Compare SHA-256 hash with signed Git commit
IT and More Systems
Sascha Dämgen
Am Neumarkt 22
45663 Recklinghausen
Germany / EU
SimpleGo Legal Framework
All documents available in English and German. Server infrastructure operated under German and EU law.