The shortest book on good programming, ever!

The Coders Decalogue

This text is about making software work better and saving huge amounts of time, irritation and frustration for developers, users, customers and other stakeholders in the software business. Which likely means you.

When not developing my own software AxCrypt and Xecrets, I work as a contractor and consultant. In my work, I work with new software and old software. I work quite a bit with advanced troubleshooting and performance optimization in the .NET area.

Over the years, I've come to realize that I spend most of my time as a developer, doing things I wouldn't need to do if just a few simple rules are followed. I'd still have more than enough to do, no worries, but I'd be delivering much more real value to my customers for each hour spent. And so would millions of other developers. Come on - this is really not that hard!

I won't explain the rationale here, or give lot's of pedagogical examples. That would turn this into a real book, which would be nice. But I don't have time to write a book and you probably don't have time to read one.

So just trust me on this ;-) Really.

• Do write code for humans. Smart one-liners, compact code, use of sneaky language constructs etc may not break your program. But it's not enough that the compiler understands the code. Don't write for the compiler, write your code in a style to make it as easy to read for humans as possible.

• Don't copy and paste code with any kind of logic (ifs, loops, selects etc). Do always factor out common snippets. Even when you're in a hurry. Single-liners without logic are ok. That's called a statement in most languages, and you do need a few of those to make something happen and they can't all be uniqe.

• Don't check-in commented out code. It's ok when you're trying out the new code - but when you're done, you're done. Since the code anyway resides in a version control system (right?), the old code is still available in the history. Do check-in clean code frequently always improving it slightly at the very least..

• Do use long and descriptive class, method and member names. Letters in your source code are cheap. Use them freely. Don't abbreviate unless it's an industry or domain standard. 

• Don't comment code to explain what it does. If you need comments to explain the code, fix the code instead so it's understandable. If you release libraries, use structured comments for public classes and methods to document intended usage patterns, assumptions and contract details. Do comment why the code does what it does, when it's not obvious.

• Don't nest if-statements or loops. In some special cases, one-liners inside a nested if may be ok. Do use early-exit and write small methods to remove the need for nestling inside a method.

• Don't catch exceptions unless you know why you're catching them and what to do about it. Never catch all exceptions, except at the top of a given thread's call hierarchy and then only if consequences of not catching it dictate the need. If you do, log it! Do program to avoid exceptions when you know the conditions to prevent it happening in the first place.

• Do write short methods that does one thing and are named accordingly. If a method does not fit on a screen of a reasonable size, then it does too much. If you have trouble naming it properly, it probably does too many things. Don't write long methods that you need to scroll to see all of.

• Don't try to be smart. When there is no known need for advanced or smart solutions, do keep it simple and use simple standard patterns until you know it needs special treatment. 

• Don't optimize unless you know you need to. You'll know by measurements using performance profilers. This is not the same thing as writing inefficient code. Do write efficient code according to best practices that avoids known pitfalls and bad design. Performance optimizations come on top of that, for example caching or special-purpose thread-synchronization constructs, and are to be avoided until the need is proven.

• Do always step through your code at least once to verify your assumptions about it's behavior. Don't trust just running the application and be satisified when it appears to work.

This is in no way the complete zen of good programming, nor is it revolutionary or unique. All of this has been said before. I'm sure you'll have your own pet peeves you'd like to add to the list. I have a few of my own, but the idea here is to list important things that are really super-simple to do. Now.

I am absolutely convinced that if these rules are followed, overall productivity in the software industry will rise dramatically.

If you're a developer, are there any of these rules you honestly disagree with? Do you work like this already? If not, try it out! Use peer-reviews to discuss your check-ins with this list as a guideline.

It's really this simple.

PS - There are 11 rules here. I'd like to get it down to 10 as the title indicates. Cast your vote on which one should go! Or perhaps what needs to be added, but then you'll have to drop two... ;-)

Security, compatiblity and backup

Users of AxCrypt are obviously concerned about the security of their files. Howerver, there is some confusion about just what security means.

Encryption means security from others reading the data. In the case of AxCrypt, it also means that undetected modification of the data is not possible.

Encryption does not mean security from data loss for any number of reasons, such as accidental deletion, ransom attacks by hackers where AxCrypt even has been know to be used by the black hats, or hard disk crashes.

In fact, encryption adds another level of processing to the files, actually increasing (albeit very slightly, but still) the risk of something going wrong. If you think about it - the more you do, the higher the risk of a snafu. That doesn't mean AxCrypt is dangerous, it just means what it means - the more operations you perform the higher the risk is, as counted in number of failures per million for example.

In this day of rapid development on all fronts, there's always the question of data compatibility across computers and program versions.

All AxCrypt-versions from 1.0 to the current 1.7 in both x86 and x64 bit versions are compatible with each other, so no worries there. AxCrypt will always be upwards compatible, so version 2.0 may in fact in the future produce encrypted files 1.7 can't read - but version 2.0 will always be able to decrypt anyting an older version has produced. But, at this time, all versions are in fact compatible.

Also, AxCrypt-encrypted files are not tied to any particular installation in any particular computer, and uninstalling AxCrypt won't decrypt any files any more than uninstalling Word converts your documents to Notepad text files. If you have the file, and know the password, you can always decrypt it in any computer where you can get one of the various versions of AxCrypt running.

Now to the most important message about security, in the meaning keeping your data safe not only from prying eyes - but from any number of catastrohpes.

Your most important and powerful protection against data loss is spelled 'BACKUP'.

Please ensure that you have backups of all your data, encrypted or otherwise, and that you keep a reasonably recent version of the copy off-site, and that you periodically do check that you in fact can read the backup and that the expected data is really on the backup media.

Personally I backup to two USB-drives that I swap once every few weeks, always keeping at least one drive off-site. It's cheap, it's effective and it's very safe since all the data on the backup is encrypted.

Anti-Malware Vendors - here we go again with another round of FUD...

Over the years, I've been periodically plagued by false positives reported for AxCrypt by various anti-malware vendors. These small-time, opportunistic, shady vendors like Microsoft, ESET, McAfee, Avast et. al. have a long history of just flagging anything they please as malware, and be damned the consequenses.

I am a small one-person operation providing free strong encryption software for personal privacy and security. I have over a decade and perhaps 20 million downloads of faultless operation on record. Nevertheless, at least once a year, these companies start reporting my software as malicious, causing me and my users no end of grief.

Why will not a single one of them just for once take repsonsibility for their actions? I have not received as much as one single communcation from them. Not once. Not when they flag my software falsely as malicious. Not when they rescind that flagging, as they inevitably do when enough users get suspicous and start questioning the reports.

Now, in 2012, it's starting again. This time because I'm trying to make some small revenue using bundled advertisments for other software with the installer in order to be able to spend some more thousands of hours developing free software. For more specifics about that particular choice read here.

As a current example, a recent report from Microsoft concerning the adware bundle AxCrypt uses that is at the time of writing actually a disclaimer of a recent false positive may serve. This causes uncertainty and fear for my users, but what does Microsoft care? Did they ask before flagging? Did they report when they removed the flag?

A different example are some recent reports about my site and my software  from virustotal.com which is even worse, because these guys hide behind the additional screen of being an aggregator - so they don't even have to take any responsibility at all, they're just forwarding information uncritically. This is a free service, so you can't even complain.

What can you as a user do? I don't really know, miss out on great, safe and free software because of fear, uncertainty and doubt seems the most likely case. Or, you may start to at least make your voice heard when these situations arise.

When your Anti-Malware software reports a false positive - demand your money back!

What can I do? I don't know that either. If you have any ideas on how I can protect my reputation and continue to provide free, safe security software - do let me know.

I'm getting tired of this. How much cr*p must I take to write and publish free software for your security and integrity?

AxCrypt used for ransom attacks

In October 2011 I got an e-mail from a Turkish corporation, claiming that someone had hacked their server to the extent of getting full administrator access. Thereafter the hacker had installed AxCrypt and encrypted all or most of the files on the server, and subsequently demanded a ransom from the company owning it.

At first I was very sceptical - how could someone get that kind of access to a server, and then hit on the idea to use AxCrypt to encrypt the files (for which it is workable, but not really well suited since it for example requires full administrative permissions to install etc, not just write permission to the files). On top of that - no backups, the only copy of the files were apparently the files on the server.

It seemed just to bad to be true. A file server wide open to remote login with administrator permissions and a guessable password with no backup routines? My first guess was that this was some kind of scheme to see if I would respond that, "Sure, there's a backdoor into AxCrypt - just pay me a small amount and promise not to tell anyone and I'll help you out.". Sorry, no such (bad) luck. AxCrypt does not have any backdoors, and I can't be of help.

Now, in July 2012, I've had an additional few similar e-mails and even a few phone calls, in total about 10. All of them from Turkey. Strangely enough the contacts have escalated, at start it was only e-mails which were not responded to when answered, then the e-mails started getting answered, then english speaking persons were calling from Turkey - now most recently Swedish-speaking persons are calling from Sweden, still referring to problems orginating in Turkey.

I'm still at a loss to really explain the phenomen, but I'm now tending towards actually believing that the basic facts are true. Servers and perhaps also personal computers are being hacked (it's not entirely clear just what kind of computers have been hacked). That so far every single incident has been in Turkey, is I believe due to the simple fact that the hacker is likely to be Turkish. A significant number of these hacks seems to occur during the weekend, so it's also likely that the hacker has a day job too which is somewhat comforting since it implies that the 'business' is not very profitable.

If you happen to be the victim of a ransom attack, in Turkey or elsewhere, I am very sorry for your sake but please understand that I cannot be of any help whatsoever. You must contact your local police authorities and get them to investigate. They should be motivated to do so, since apparently this is not that infrequent - once again assuming that the stories I hear are actually true as told.

I've tried to come up with some way to make AxCrypt even less suitable for the purpose of ransoming, but I really can't think of anything. It's just a tool, and if you let the hacker into your system with full administrator permissions, I don't think there's anything anyone can do - except you and that is to have backups!

This is not an AxCrypt issue. This is a security policy issue at the vicitims site.

The hackers are even not that smart to use AxCrypt. To perform the attack they don't really have to install anything - all they have to do is to encrypt the file system with EFS, Encrypting File System which is an integral part of all modern Windows editions, export a recovery certificate and then reset the administrator password. Done. No need for extra tools such as AxCrypt. On top of that, there are literally hundreds of alternative encryption tools out there, all of them potentially 'useful' in this context. I guess in a twisted kind of way I should regard it as a compliment that AxCrypt is so easy to use and secure that even hackers want to use it!

Remember that backups are your final protection against data loss, regardless of the cause. Go check your backup routines now - and validate that you actually can read the backups regularily as well!

About Xecrets and the XML Encryption Vulnerability

On October 19, researchers at the Ruhr-Universität Bochum announced a flaw in W3C XML Encryption.

The Axantum Password Manager Xecrets uses XML Encryption to store data on our servers.

This does not mean that Xecrets is vulnerable to attack.

The flaw only works in an attack against a server that knows the encryption key, and that can be queried about the result of attempted decryption of partially modified encrypted data. It is based on the fact that most implementations will happily decrypt the provided data using the secret key and then give different error messages if the decrypted data cannot be parsed as XML. These varying error messages can then be used to infer the original data, but not the actual encryption key.

Xecrets on the other hand never accepts encrypted XML in this way, nor does it know any users encryption except briefly during the users visit.

The XML Encryption flaw does not affect Xecrets.

Why you should install programs to the default location

AxCrypt since version 1.7 does not have an option for the user to select installation directory during the installation process.

Some like to change the installation directory, typically to D: or E:, instead of the standard location typically on C: and on English versions of Windows in C:\Program Files\ or C:\Program Files (x86) . This is no longer directly possible from the installation graphical user interface of AxCrypt, and sometimes I get asked why.

The main reason is to avoid trouble, and minimize user options where I as a developer believe I can make a better informed choice. AxCrypt is built around many such decisions based on that premise, we choose the algorithms to use instead of providing you with a bewildering array of choices for example. This is simply because I as an encryption expert believe that I can make this choice better in at least 99,9% of the cases and thus spare all those users a strange question they don't really know how to or even want to answer.

With several millions of installations of AxCrypt, just about anything that can possibly go wrong has at least once or twice. More than twice I've had to help users with trouble caused by not understanding the interaction between Windows, the registry, fixed, removable and network drives and AxCrypt installation. AxCrypt has been installed to network drives, on remote VPN-mounted drives, on USB drives on CD's and just about anything you can imagine. Often it works, but sometimes it does not.

With AxCrypt 1.7 and the upgrade to use Windows Installer technology, a major motivation was increased robustness. Part of this is to minimize the risk of a user mistakenly making a bad choice, and the safest and easiest way to do this is to make the choice automatically. Thus the option to select installation a directory was removed from the installer graphical user interface. It's still there - but you need to know a bit about Window Installer in order to force it to do your bidding. The idea here is that any user skilled and knowledgeable enough to do this, is also skilled enough to make that decision with small or no risk of mistake. It's also very clear that if something does go wrong, it's something that needs to be fixed by the user and it does not wind up as an error report about AxCrypt.

The thing that cinched the decision to remove the installation directory was that I could not, try as I might, think of a single valid functional reason for changing it from the system default! Aesthetical,  arguably yes. Functional, no. AxCrypt is tiny, has no performance impact on the drive it is installed to, and does not produce any growing data there. When we do change the installation directory, we also break some assumptions that are made by other software. We are also now responsible to ensure the right file system permissions for example, we might open a vector for a malware infection by installing to a directory that allows non-administrative rights to write to for example. Please note that AxCrypt, due to Windows design limitations, requires administrator elevation to install anyway. Other assumptions we break are the locations of 32-bit vs. 64-bit software in the various virtualized environments offered.

So, we wind up with a situation where I can find no situation where it's bad to install to the system default location, but several where it's bad to install to a different location. By making the intstallation easier for the user by removing one decision, we also make it safer and more robust. It's an easy call I think.

Finally, if you can provide me with a valid functional reason for not installing AxCrypt to the system default location, please do so and I will try to accomodate that reason in the best way I can think of.

Concerning false positive reports about AxCrypt from antivirus software

From time to time I get user reports about warnings from antivirus software concerning either the installer or one or more of the components of AxCrypt.

This causes great trouble both for me and the user. The user often winds up with an inoperable software, and I get a lot of extra work defending myself against unfounded allegations by software companies that take no responsibility whatsoever. They will not guarantee anything about the 'security' they provide, and they will not in any way assume responsibility for harm caused by flagging clean software falsely as malicious. In a normal legal context this would be called slander, and be cause for legal action.

Some facts about AxCrypt and AxCrypt distributions. AxCrypt is always built completely from source, we do not statically or dynamically link to any third party code except those libraries that are part of the Visual Studio development environment and which come directly from Microsoft.

Distributions are not built in a developer PC, they are built in a special purpose build server which only do that. No other software is installed than that required to build our various softwares there. This server is stationed behind double firewalls, and is never used for any general purpose.

As part of the automated build process, each executable is digitally signed with an authenticode certificate, issued to 'Axantum Software AB'. The issuer of this certificate do certify that such an entity exists, and that it is in good standing. I have provided them with proofs of the companys registration etc. This signing process then ensures that any bits distributed with that signature is traceable back to me and my company, and we would thus potentially be legally accountable for any malware intentionally placed there.

To sum it up: There is no infection in a distribution from me which is digitally signed with my authenticode certificate in the name 'Axantum Software AB'.

It is a continuing effort trying to defend oneself as an independent developer against the so-called anti-virus companies unfounded allegations.

It is beyond belief that a serious anti-virus vendor still in 2011 will flag a properly digitally signed executable as malicious.

If I had the financial resources I would take strong legal action, since this causes sometimes hard or impossible to repair harm to my good standing, and that of my programs.

Please check that you have the properly digitally signed versions of both the installer and the executable components if you are in doubt, instructions on how to do this are found here.

Please help the community by reporting your findings as a false positive to your anti-virus vendor. Although the vendors empathically deny this, they do share signatures (or 'borrow' from each other). This is clearly evidenced by the fact that these false-positive situations usually come in swarms where I get a few reports first from one vendor, and then most of the other vendors follow suit. That can't be a coincidence...