A court order or someone holding a rubber hose could instruct that release engineer to ship tweaked code to any number of devices that sets "42" as the random seed for private keys, allowing anyone with that knowledge to decrypt all messages in transit covertly.
It would be in the best interest of your shareholders to lie if this was ever to happen.
Without the code being open source, everyone should assume this is the case.
Messengers are a massive target, and a target of that size on one person is certain to be exploited.
One of core areas of my research is supply chain attacks, and you have no hope of providing strong defense against them without open source reproducible builds.
Texts connects directly to the platform, from your device, without using any Texts servers having any access to your messages (even in encrypted form) and without breaking the E2EE the platform provides (for platforms that support that), similar to Beeper’s new Signal integration.
A major benefit of this is you can verify what requests are made and what responses are received. You can also use Texts, not upgrade, and would run the same WhatsApp code for example until you upgrade. Same can’t be said for WhatsApp Web for example. It might also be easier to compromise the platform themselves for a government entity, if that’s our threat factor.
It should go without saying we take user privacy and security very seriously, and have restrictions around who can build, sign and distribute our binaries.
Until then at least hearing if you are willing to to be transparent about your supply chain security strategy would be a great start.
Some of the supply chain integrity tactics I find most companies skip:
1. Are all commits signed with personal engineer HSMs (yubikey, nitrokeys etc)?
2. Are all reviews similarly signed by someone other the author?
3. Does tamper-evident CI/CD (that no single engineer can manipulate) verify these signatures?
4. Is the code for release binaries reproducible?
5. Does more than one system controlled by different employees (or ideally a third party audit firm) build the code at least a second time and get the same hash?
6. Are the app signing keys managed with multi-party custody? (Threshold signing, multiple-in-person witnesses to airgapped signing, or managed in a remotely attestable secure enclave running reproducible firmware?)
7. Does the signing system verify multiple reproducible build signatures before issuing app-store signing keys?
8. Do you provide standalone signed binaries for users to side-load on de-googled devices so users can remove google (and their many partners) from their supply chain attack surface?
9. Do you review any/all of your third party dependencies, and every update to them?
10. Do you build exclusively with multi-signed reproducible OS and system packages?
11. Do you have published audits from reputable third party security firms attesting all your security claims, and all of the above? (Ideally with the exact hashes of the binaries whose sources they audited)
My team and I help companies with most of the above regularly for highly targeted orgs, but it takes a lot of engineering hours to get this stuff right. Failing to do any of the above would put a massive target on a single human or system, and in my experience this always results in a compromise one way or the other for a highly targeted service such as yours.
It is honestly much cheaper to just open source reproducible code, and let the community help check some of supply chain security and accountability boxes for you.
I highly doubt Beeper gets much of the above right either, but by allowing you to self host open source bridges, they grant users with higher risk profiles the option to not trust them a bit less. Granted, if you are self hosting bridges with an open source client, then there is no reason to pay Beeper.
IMO the only reasonable move in this space is to provide turn-key remotely attestable open source bridges paired with an open client to save users work without asking for trust.
Full disclosure, I did do some security and infrastructure consulting work for Beeper a few years ago.
