3 ms·
ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the
by imaginenore 11y ago
ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations.
The second problem is - you don't know if that source is what ended up in the binary.
So yeah, unless you can compile the whole thing yourself, it should not be considered secure.
- exo762 11y agoOpen source client and reproducible builds. Signal already does that. It's not a high bar.
- ryanlol 11y agoThat's a completely different from just wanting the e2e crypto source, which is useless by itself. https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
- nxzero 11y agoWhat to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___ So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit. Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it. Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!