|
|
|
|
|
|
by Tainnor
1487 days ago
|
|
|
You're being extremely dogmatic here. All I see is a rant without any sort of indication of what we could do to improve the situation. I also don't think security researchers would agree that first-party E2EE is snake-oil. I don't believe there can be security without trust. You will always have to decide to trust or not trust some parties. GPG would have enabled that sort of trust to happen in a decentralised way, but it's clearly way too complicated for the average user (plus, it suffers from other weaknesses too). We need something that works for average people and that is better than plain-text transmission, or just TLS. Arguing against E2EE just because you don't know whether the software is potentially backdoored is throwing the baby out with the bath water. E2EE helps prevent accidental exposure. It's actually of benefit to companies if they never have to see unencrypted data, it creates fewer attack vectors and therefore also fewer opportunities to be liable for exposures. And even if your vendor backdoors its software and steals your keys, there's still a good chance somebody who is inspecting their internet traffic would discover that, which would obviously create problems for the vendor. |
|
|
The problem is that we, as developers, are working in such a complex and powerful environment that auditing comes with extremely expensive costs - effectively ensuring E2EE would probably mean using a third party component wrapped in a very strict box to drive all that traffic through your system... and that goes against a lot of the flexibility of software development we all love.
You can see similar requirements around HIPAA compatibility - you're forced into using a certified vendor (perhaps one that's inhouse) that is paying high continuous costs to ensure their audit compatibility - these costs produce very long release intervals and slow down innovation.