[copsarebastards]

I agree that the technical solution is the most important one, but it is a) not a solution we have ready right now, and b) one that will never be 100% effective.

HTTPS everywhere is a good start, but it it does a poor job of defending against the NSA. Certificate authorities are fundamentally broken and users don't have the background knowledge to understand certs or why they are necessary.

Even technical people don't understand this. The last time I saw a post about certificate authorities on hacker news, the top comment was about how most people don't want authentication, they just want encryption. You can't have encryption without authentication: unauthenticated encryption is fundamentally broken. But the user who posted the comment was ignorant of this, and enough other people were ignorant of this that they upvoted his comment to the top.

The solutions proposed also don't address the problem that popular centralized services are bound to be compromised. Even if you're sure you're connecting to Google or Facebook services over a secure connection, Google and Facebook are such high-value targets that they will be compromised by an entity with as much money as the NSA. The defense against this is also technical, but it requires a fundamental shift from centralized to decentralized technologies, and I don't think that's easy or at all ready.

> Basically securing against the NSA is the same as securing against hackers, it should be treated as a security threat like any other.

This drastically understates the attacking power of the NSA.

[zanny]

The problem is how to have fundamental security. We already know or highly suspect the US Fed has backdoors at the hardware level. We cannot see the designs of our hardware because they are proprietary, so we cannot trust them. We start at a disadvantage.

Even discounting that, you cannot trust your firmware, because very few people are running libreboot or equivalently free firmware. Again, backdoors galore for state agencies.

But you solve those and then you need to trust your operating system. Firstly, the vast majority of people use proprietary operating systems. Secondly, even if you use a free operating system (and I mean pathologically free like Trisquel or Parabola) you get a set of security keys included you are meant to be able to trust.

The problem is that the international governmental muscle and influence of the US Fed means it is unlikely you can protect any of these private keys. They are all held by sufficiently large organizations that the US can strongarm them into giving them up, without even resorting to immediate violence.

But I'd feel more comfortable trusting the Arch master keys or the Debian councils keys, because both organizations are multinational collaborations of individuals where the majority can blacklist a compromised member. It sure beats key management by one vulnerable company. So that might work.

It is like how people talk about all this security mumbo-jumbo but all it takes is five minutes with some brass knuckles to get you to spill every password you have ever made. With the knowledge we have and the technology at our disposal the best I can at least do is pray that my OTR conversations over XMPP are secure, given that I have tried to minimize my attack surface on all these fronts, but there is no one solution that I can say "this machine guarantees me my security" because how can I know that the proprietary firmware on my hard drive is not somehow circumventing my dm-crypt layer (it would need some kind of collaboration with the chipset, though, since the keys never touch the disk raw)? I certainly know I cannot trust any hardware encryption at the least, but I don't see anything stopping proprietary motherboards from caching the keys used during hardware SIMD encryption routines (most Intel cpus support hardware accelerated AES 128, for example) in some unseen ROM the user never touches so the NSA can crack the hard drive.