Security

In my last post, I touched on security a little bit from the perspective of the client, the company and more interestingly, the developer. I wanted to elaborate more on this idea in terms of what we as developers are responsible for when it comes to making design decisions, especially when it involves introducing potential vulnerabilities.


Hopefully most of us are at a minimum, mildly security conscious, at least to the point of not INTENTIONALLY introducing vulnerabilities into a system. However, as I discussed in my previous post about RSA, sometimes decisions are made to *supposedly* intentionally design insecurities into a system. What kinds of things do we as developers have to consider when designing such systems?
When we are responsible for the implementation of systems with the potential to effect billions of people what's important? Is it the money? Insuring people that are dependent on them are shielded
from failures? Does anything matter? Should we live in anarchy?


While money is definitely important, at the end of the day, I'd definitely prefer to go home to an average home and drive an average car if it meant I was able to sleep at night knowing that I wasn't contributing (HOPEFULLY!) to the unabashed mass surveillance of practically the entire planet! So for me, I
think designing something with the utmost skepticism for anyone that may potentially use it and also for the people that write my checks (HOPEFULLY! HA that's two) is the best way to ensure that as little collateral damage as possible is incurred. To me, it's more important* to know the things that I build weren't designed to harm them than it is to collect a few extra bucks that I'll probably blow on beer.


At the vary least, it wasn't intentionally. Not that that is not much of a reassurance to clients and employers, but at least I'll be able to sleep at night knowing I didn't sell out.


* I hope I'll be singing this tune 20 years from now but what am I, a fortune teller?