Why Building security backdoors into software is a bad idea

By kamui 19 Jul, 2018 Leave a comment

This should be obvious, but on the surface, to reasonable people, this seems reasonable. If bad people are doing bad things and the police can get enough evidence to approach a court, they can get a wire-tapping order, which will allow them to intercept any communications in the mail, or telephone that will allow them to gather evidence against the criminals.

TLDR; the basic idea is flawed and it puts individuals at risk.

This seems like an invasive but reasonable approach to protect public safety, and why software should be different? Why should there not be a master key that opens the encryption locks that criminals are using to conduct their nefarious activities? It is just those pesky software companies preventing the police from protecting us from criminals, who want to do us harm. We should make them change and allow the police to view these hidden communications. This seems reasonable, at least until you think about it.

This basic premise assumes that the ones controlling the master key or even the company that makes the software are infallible, there could never be any bugs, and there could never be anyone in those organisations who could be bribed or coerced to reveal the key, an overworked, stressed, or sleep-deprived individual could never mishandle it. This is building an intentional flaw in a defence, like the infamous drain in Helms Deep from the Lord of the Rings.

and that ended well for the men of Rohan.

This also assumes that the organisation that wants the protection can instruct the organisation that makes the software to make this weakness, and that criminals would not just use something else. True the government could restrict sales of the software to disallow the sale of software without the backdoor in force, but again this assumes that criminals are only going to use software that is legal within that region, because of course criminals are well known for following the law. The basic idea is flawed and it puts individuals at risk.

Test Driven Development (TDD) – A practical example

By kamui 1 Jul, 2018 Leave a comment

Recently the development teams here have been improving their coding skills by taking on the challenge of Clean code, a practice by Robert C. Martin (Uncle Bob) who has a number of very informative clean code books and clean code videos practised by many developers and to improve the quality of their code, so they can code faster.

If you want to go fast. If you want to get done quickly. If you want your code to be easy to write, make it easy to read. The only way to go fast—is to keep the code clean.

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Clean code is not the topic of this post though, I’ll leave that for another day. Today I’m going over the practice of TDD – Test Driven Development.

It has a number of advantages:

  • The biggest and most important is that it eliminates fear of change – refactor or modify at any time with no fear.
  • Reduce debugging time by between 50-90% – imagine a group of developers and pick one, any time, sometime in the last minute everything that person was working on worked and all its tests passed. It doesn’t matter who, it doesn’t matter when. Being good at the debugger is not a desirable skill, being good at the debugger, means you are experienced at interacting with bad code.
  • Reduce defects
  • Unit tests are the best low-level design document. If you want to do something, you can just copy the test that does it.
  • Writing tests first will mean that you write code that is testable, in other words, decoupled.
    This in turn Saves time, reduces estimates, which reduces costs
  • Avoid the grand cleanup – which inevitably fails due to lack of tests.
  • Increased confidence in the quality of the code – in the example app, if the tests pass they ship it. Your tests are like a parachute to prove your system works, imagine you are working on the code a life support system that you yourself might need to use at some point. Would you trust a system with its tests, would you jump out of an aircraft with a parachute that has holes in it?
  • Writing tests afterword is procedural, it is required of you for your job, but it feels like extra work for little gain. You already know your code works, because you have manually tested it, the danger then is that you take shortcuts with your parachute.

The 3 Rules of TDD

  • Write only enough test code to make it fail
  • Write enough code to make it pass
  • Refactor then repeat

The cycle is only 30 seconds to a few minutes long but it leads to code which you can have confidence in, code which you can entrust your life to.

Take the following example, I’ve taken the liberty to fill in the first few steps as comments so you can repeat the steps and then expand on them.

The Example

Below, you will see the typical High School computing problem of building a calculator, the requirements are simple to start with but slowly grow with complexity, but this can easily demonstrate TDD. See the jsFiddle site for the example.

Requirements

  1. it needs be able to sum multiple values
  2. it needs be able to able to subtract multiple values
  3. it needs to be able to multiply multiple values
  4. it needs to be able to divide one value from another
  5. it needs to be able to work with floating point numbers
  6. it needs to be able to calculate the value of an input number to the power of another number.
  7. it needs to be able to calculate the square root of a value
  8. it should have the ability to take a string of calculation values and compute the correct result.
  9. it should be able to handle multiple operators at the same time.
  10. it should output values to 5 decimal places
  11. it would be good if it could have a text field and button that when pressed would validate and calculate a user input calculation.
  12. it would be good if it could generate the calculations from calculator buttons

The application is written in Typescript and uses Jasmine as the testing framework. It starts with the simplist failing test, implement the calculator class, which can easily be made to pass by uncommenting parts of the code above.

To simulate the cycle, uncomment each test one at a time then uncomment the respective code to make it pass. Repeat this process until all the tests pass and the begin the 3rd acceptance criteria “needs to be able to multiply multiple values”.

Write the failing test and then implement it in the same fashion.

NDC – Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

By kamui 4 Aug, 2017 Leave a comment

I have recently been listening to a few of the NDC talks from around the world and the one today that has caught my interest is this one, Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks by Kevlin Henney.

I particularly liked the inclusion of FizzBuzz Enterprise Edition. For those that don’t know FizzBuzz is a simple programming challenge, that used to be and still is in some organisations an interview question.

The problem is

For numbers 1 through 100,

if the number is divisible by 3 print Fizz;
if the number is divisible by 5 print Buzz;
if the number is divisible by 3 and 5 (15) print FizzBuzz;
else, print the number.

It is not a difficult problem, and it can be solved in a few simple lines of code.


def fizzbuzz(n):
if n % 15 == 0:
return 'FizzBuzz'
elif n % 3 == 0:
return 'Fizz'
elif n % 5 == 0:
return 'Buzz'
else:
return str(n)

there are even more concise versions of this code but this is simple to read and understand.

What FizzBuzz Enterprise Edition does is humorously take certain enterprise software design principles to their extreme.