3 ms·
There are other methods of coercion than courts, but I agree that the German courts are probably much safer than the American courts. In any case, the fraudule
by rocqua 9y ago
There are other methods of coercion than courts, but I agree that the German courts are probably much safer than the American courts.
In any case, the fraudulent client update is a very hard hole to patch. The only solution for this I know of is local hosting. At the moment, defending against this in web-apps is simply not possible.
- crankylinuxuser 9y agoThere's one way I know to stop that. Ipfs. Its immutable, for a given key. And its easy to see what an IPNS link points to. It may not be a way to verify, but others could do that hard work. But it strictly shows proof that codebase for a web app hasn't changed.
- dvdkhlng 9y agoThe only real antidote against unauthorized access is using end-to-end encryption between email's sender and recipient(s), via PGP/GPG or S/MIME. Unfortunately this requires the sender's cooperation. As long as the sender does not cooperate, there will always be some leg of the communication path that is vulnerable.
- crankylinuxuser 9y agoIndeed. But that problem has been to "Show clients how to install the relevant plugins, make their certs, and then appropriately use certs." That's been error-prone since the beginning with PGPMail and PGPphone. That's why this was switched to doing it in a webapp, to streamline the process and remove user error out of the equation. There's one problem, and that the owner of the script can change it to a bad one that does X. With an immutable data structure, like what IPFS uses, can provide that chain of custody with a script they make that simplifies PGP usage, while still maintaining "We didn't change anything" - and you can prove that.