oh fuck..

uh... nevermind?

Threema has  been through two private equity acquisitions now. In 2020, the original cofounders sold to AFINUM (German PE firm) but retained leadership and a significant share. Then the founders left the company entirely in 2024. Just announced in January 2026: Comitis Capital (Hamburg-based PE) is acquiring Threema from AFINUM. The deal is expected to close this month.  This is what’s called a secondary buyout - one PE firm flipping to another. The concerning pattern: ∙ 2020: Founders sell majority to AFINUM ∙ 2024: Founders exit completely ∙ 2026: Flipped to another PE firm Threema claims “our core values, corporate mission, and management remain unchanged”  - which is the standard line in these acquisitions. They emphasize that technical infrastructure and data centers will remain in Switzerland , but the company is now fully owned by German investors with zero founder involvement. Why this matters: PE firms optimize for exit value. Two buyouts in 5 years with founders completely out suggests the product is now a financial asset, not a mission-driven project. Compare to Signal, which is a 501(c)(3) nonprofit. One commenter on the news put it bluntly: “I so liked this product… simpleX is now the only clean option in the market.”  If you want something without VC/PE ownership risk, SimpleX and Session are both structurally different - Session is backed by a foundation, SimpleX is open source with a different funding model. Delta Chat also dodges this since there’s no company to acquire.​​​​​​​​​​​​​​​​

https://delta.chat/en/help#message-metadata

https://support.delta.chat/t/reach-near-zero-metadata-with-latest-delta-chat-releases/4321

https://eprint.iacr.org/2024/918.pdf

Header Metadata Analysis from ETH Zurich Paper Header Classification System (Section 4.2) The paper describes Delta Chat’s four-tier header classification: Delta Chat internally categorises headers into four types: ∙ Unprotected: these headers must appear as IMF headers, e.g. Date and Chat-Version ∙ Hidden: these headers can be large and therefore must not appear as IMF headers, e.g. Chat-User-Avatar ∙ Protected: these headers are encrypted whenever the message is encrypted, e.g. Chat-Group-Name ∙ Secured: these headers should only be present in the signed and encrypted payload. The Chat-Verified and Secure-Join-Fingerprint headers are explicitly marked as secured. In addition, Delta Chat treats the Autocrypt-Gossip header as secured. The Core Vulnerability The e-mail parser removes or ignores secured headers that appear in the unencrypted part. However, perhaps counter-intuitively, a protected header can appear as an unencrypted IMF header even if the e-mail is signed and encrypted. This design choice is necessary for headers like Subject and From, which are generally required for well-formed e-mails, but is incorrect for other protected headers, such as Chat-Group-Member-Removed, which should only appear in the possibly encrypted e-mail body. Header Overwriting Issues The situation is more complicated when the same protected header appears in both encrypted and unencrypted parts. Delta Chat parses the unencrypted headers before the encrypted headers, preferring a new header over an already parsed one if the header is considered as “known” or starts with Chat-. Therefore, the encrypted header generally takes precedence over the unencrypted header. However, because of several oversights in Delta Chat’s e-mail parser implementation, there are cases where the unencrypted header could overwrite the encrypted header, including Secure-Join, Secure-Join-Auth and Secure-Join-Group, which are not included in the list of known headers. Moreover, Secure-Join-Auth should have been treated as secured instead of protected, as it never appears unencrypted in honest executions. Message-ID and From Header Vulnerabilities In addition, the Message-ID header and the From header are in effect susceptible to overwriting. The Message-ID header, while not susceptible to overwriting per se, can be overwritten by the unprotected X-Microsoft-Original-Message-ID header, which was used in older versions of Delta Chat and remains for compatibility. For the From header, Delta Chat decided not to reject an e-mail whose encrypted From header is different from its unencrypted From header. Table 1: Vulnerable Headers

Metadata Leakage in Group IDs (Section 4.2) An eavesdropping attacker can easily distinguish Autocrypt traffic by checking the Autocrypt header. The attacker can also distinguish messages from different groups, since the group ID is a part of the plaintext Message-ID header. Privacy Attack via Key Tainting (Appendix E) An attacker that can only observe and modify partial network traffic, e.g. a malicious e-mail server, may “taint” Autocrypt keys in order to learn more about the social graph of the target. The attacker can do this by adding unhashed subpackets to OpenPGP keys in Autocrypt headers found in network messages, which is possible since these fields are not protected by signatures nor contribute to the key fingerprint. Mitigations Applied in v1.44 From the Delta Chat blog post on the fixes: Starting with version v1.44 Delta Chat extends protection to several important headers: ∙ Delta Chat now protects the From header ∙ Reduced metadata by not including the chat group ID into the Message-ID ∙ The Chat-Group-ID is now contained in the encrypted part of a message Recommended Fix from Researchers An immediate fix to the attack would disallow headers starting with Chat- to appear in the unencrypted part if the message is encrypted. However, it takes more careful checks to completely eliminate such attacks. In general, if a protected header appears in the plaintext part of an encrypted message, then Delta Chat should regard the message as invalid.​​​​​​​​​​​​​​​​

it's email, headers, are metadata. i guess i could find a source for that...