I am noting down here a few key points that he nailed down succintly. These are also the same points that I have always advocated for. I'm happy to find them resonating so well in the community.
- Do not provoke the crackers. Instead, try to make peace with them. Most of the respected (the elite tier) crackers are actually pretty decent guys and can be reasoned with.
- Limit the information crackers can get. This includes function names, debug logs, crash report, web service request parameters, and so on. Any descriptive name, hint, or keyword could give away the much needed information to the crackers.
- Delay feedback to the crackers. Accept registration information easily early on. And fail when the feature is actually invoked.
- Phone home. Or use server provided data as parameters in the client. A valid user would get sensible data; an invalid one would get crippled data.
These practices could be generalized into just a few simple, commonsensical principles. Basically, the compilation process is a lossy process. A compiler produces a "less documented" artifact from a "better documented" source code. And we should do our best to maintain that leverage against crackers. Then, the classic laws of locality come into effect. Disrupting locality of time and locality of space is the goal to aim for. And lastly, as Bruce Schneier put it, "amateurs attack machines; professionals target people." Battling against crackers needs to be a battle against the way people do things, against the crackers' way of thinking. Beside technological measures, other factors such as behavioral, and psychological aspects must be also considered.