To address your edit which added all the bullet points:

1. Avoid ECC's for commercial activity because NSA & a private company were asserting 130+ patents existed on them. Be ready with lawyers otherwise. Anyone following all the patent battles would be concerned. If not concerned or doing FOSS, I always recommend using Bernstein's NaCl or a double signature scheme with a post-quantum algorithm as secondary for those worried about such things. Lots of good work on Merkle Tree's recently, for instance.

2. Use Blowfish in cascading ciphers with other strong one's such as AES candidates. Cryptographers make barely substantiated claims about things' risk all the time. Worse, their proofs on "secure" constructions sometimes don't even apply to the real protocol rather than an abstraction of it lacking key details (eg padding). Always include things the NSA and other strong attackers have failed to beat for 10+ years. If it was so bad, they'd be dominating it across the board. They not. So, it's either not so bad or good obfuscation to add to stronger stuff.

3. Google's most clever work, which I praised, was NaCl. It ended up being one of the weakest CFI schemes in practice because they sacrificed too much security for performance and maybe other reasons. They continue to build on it despite better stuff available. Much of their other stuff was COTS implementation quality with no specialist security engineering that I could tell. They're weak on endpoints like majority by relying on insecure tools and endpoints. My advice is to think of them like any other vendor rather than on another level. Depending on architecturally-weak TCB's such as Linux doesn't add confidence to any notion you have of strong endpoint security. There are no strong endpoints in mainstream lol.

4. NSAKEY is possible evidence of subversion from a company with a whole history of screwing customers for profit on their own and with government. By itself, not the biggest worry. It's just one more circumstance among many that should get people away from Microsoft tech. Seriously, how many times do BSD or Linux users get into huge debates about something like this where the NSA's actual name dropped in there with secret functionality and evasiveness by developers? If it happens at all, you could name it on one hand. Getting away from such companies is a positive.

5. A risk indeed I took on a PC that was already compromised by my main opponent as far as I knew in a sandbox. I cross-referenced the command against the documentation as I indicated in the conversation. Yet, most people who use software do similar things without cross-referencing. People were likely to Google signify and OpenBSD issues as well along with following steps they saw online. That risk is pervasive. Nonetheless, unlike you, I decided to change my position back to being more careful after a good critique by a commenter. You've only increased your number of attacks with opposition to... anything.

6. Firewalls, as industry uses them, are a weaker form of security than high assurance guards that predated them, strong endpoint security that predated them, or even firewalls on dedicated PCI cards with more secure TCB's & I/O offloading that existed in 90's. The firewalls were easy to port, cheap to make, and often pricey to sell, though! They're regularly bypassed on endpoints and in many organizations' networks. They include almost no assurance activities, which are critical for security. A number of attacks springboarded off of them for this reason and leveraged their privileged position in the network. My position is firewalls are a filter for hackers without talent along with providers of other security or non-security functionality buyers find useful. Industry needs to switch back to guards with real assurance. And not that Linux or Solaris based crap vendors are pushing recently, either.

7. Avoid OpenSSL because every code review of it showed it to be utter crap with all kinds of issues, about the worst coders one could find, and whose reviewers could barely follow it or justify a number of things in it. Consider alternatives like MatrixSSL, PolarSSL, Cryptlib, Botan, and whatever that haven't been shown to be utter garbage yet. They might be better. Shockingly, there were still people recommending OpenSSL even as LibreSSL team dug one problem after another in the worst horror story of bad coding and security of that time. Malpractice, indeed.

"I get the feeling that we do very different kinds of security."

We do. You trust Windows, think such software isn't black box because people can pay millions to fully R.E. it, abandon stuff that works in a use case because someone said to without evidence, trust subversive companies because someone else said to, and so on. Lot's of faith-based activities and misrepresentations of others' comments by stripping context in a totally-unrelated discussion.

My form of security says you (a) have clear requirements proven in practice to work; (b) a design that meets them with strong argument; (c) a security model that makes sense; (d) evidence you use it; (e) implementation designed for review with good layering, modularity, and interface protections; (f) strongest software and hardware protections you can use; (g) extensive testing of successful and failure states; (h) covert storage and timing channel analysis; (i) robust compilation to object code; (j) secure SCM setup; (k) independent evaluation and pentesting of these; (l) delivery of product with source & build tools with hash that matches independent evaluation; (m) preferably mutually distrusting evaluators. All this applied as much as possible from processor up or using diverse hardware with careful interfaces to counter hardware risks a bit.

Yes, a lot of this was borrowed from higer EAL's and papers on high assurance processes/products. Many things like this survived NSA pentesting for years. The other approach, which you & INFOSEC industry in general recommend, has produced things with endless vulnerabilities at high severities and subversions. China, Russia, and TAO are having a field day with it all. Among others. That you all continue to promote such methods despite them having no results for decades hasn't started to make sense to me outside studies on psychology and networking effects. That industry doesn't adopt even a fraction of stronger methods is amazing despite empirical evidence and strong anecdotes showing they produce more robust systems. The industry continues to focus instead of churning out low-quality offerings and deceiving buyers on their security for the high profits involved.

Keep it up, though, as black hats need the job security. Mainstream INFOSEC has always helped them with that. The oft-ignored high-assurance community will continue doing what we can and helping any willing to learn understand strong security. Although, in this thread, only the firewall point even applied to my expertise as it's a watered-down guard in terms of assurance. The others are a random assortment of comments with no supporting context given. Nonetheless, you seemed to be confused about what strong security engineering takes and I was happy to break it down for you. Have a good night.