Item — HN Reader

The ten principles are a key principle (number 1), and the nine principles that follow (according to the post):

1. Do not rely on the law to protect systems or users. 2. Prepare policy commentary for quick response to crisis. 3. Only keep the user data that you currently need. 4. Give users full control over their data. 5. Allow pseudonymity and anonymity. 6. Encrypt data in transit and at rest. 7. Invest in cryptographic R&D to replace non-cryptographic systems. 8. Eliminate single points of security failure, even against coercion. 9. Favor open source and enable user freedom. 10. Practice transparency: share best practices, stand for ethics, and report abuse.

1 comments

>even against coercion I'd be interested to know more about how to protect against this threat vector.

An old one was RubberhoseFS albeit with assumption the user would be tortured possibly to dead.

https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

https://en.wikipedia.org/wiki/Rubberhose_(file_system)

I wrote two on these things. First is general stuff for both security and stopping legal reach of LEO's. Second is incrementally designing something like Tor with assurance against a NSA-level opponent using methods that stopped them in the past and then some overkill on top of it. The latter is to cover any advances they might be making.

https://www.schneier.com/blog/archives/2013/10/a_court_order...

https://www.schneier.com/blog/archives/2014/09/identifying_d...

Using end-to-end encryption might be a good example: if done right, you won't give away your users' secrets even if someone's got a gun to your head - because you can't.

You can if the app supports automatic updates. Therefore, end-to-end only fits if the app doesn't do automatic updates and the target is unlikely to do a manual one that's potentially compromised.

Or if it, for example, does proof-carrying automatic updates that are verified before install.

Something as simple as publishing the hash of the update in a blockchain and then widely distributing the source to construct reproducible builds for that hash would go a long way. You don't even need to make it open source, you could just have a robust enough set of geographically distributed testing labs inspect this code and check the published hash code.