Code Review Checklist - why every one wants to write one?

In my previous blog, I have report some of the recommendations from Robert Glass on Software standards and how they should be developed.

Today, I was asked to review a Code Review check list for .Net development submitted by a development group. Granted that Code Review Checklist is not the same as standards but more like a form of guidelines it should be written at least by someone that knows the stuff.

After spending some time reviewing the contents, which is made up of something like 30 items, I was horrified at such a low quality. Clearly the author of this check list has only had superficial knowledge of .Net. One example to show the naive level of knowledge is the demand that all string comparison should be performed in lower case. Clearly this person has not read this article. Another is the incorrect exception handling technique to look for in this checklist.

Some of the mistakes made, like method and parameters naming conventions, give an idea that the author's background is really in Java.

It begs the question why someone wanting to write a check list when FxCop has already contained one far far more extensive that this novice has been able to muster. There is even a book on the guidelines. So why bother?

In fact, the first item of the check list should demand a clean run of FxCop or VSTS Code Analyzer. Other check list items should be more about advanced issues like couple metrics, design patterns and complex issues, any unit tests and are they constructed in the spirit of Unit Test, etc.

The check list, as Robert Glass said,

should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.

This is not the first time nor will this be the last for me seeing this kind of mistake.

Software Standards and how to develop and use it properly

Over time, I have come across many attempts by software engineers from different development shops or organisations and have formed an opinion that many of these attempts are not only poorly compiled but often containing dangerous information. They are better served by adopting world recognised publications but there are very few that are well written and of International standard quality.

I have never been able to find any publication to back up my observation and opinion until I come across the chapter titled "Standards and enforcers: Do they really help achieve software quality?" in a book called "Softeware Conflict 2.0 - The Art and Science of Software Engineering" by Robert L. Glass.

This chapter not only supports my opinion but also clear my doubt of whether or not adherence to software standard produces quality software by his explanation that:

Standards are a narrow subset of the total issue of quality, and although it would be nice to establish the definitions of quality in terms of conformance with a sufficient set of standards, it is simply not possible. Software quality is defined in terms of attributes such as portability, efficiency, human engineering, understandability, testability, modifiability, and reliability.... you will quickly see the software quality cannot simply be legislated, it must be performed. Efforts to measure software quality in terms of standards conformance are doomed to letting poor-quality software slip through undetected.

While conformance to standards alone does not necessary produce quality software, he has found:

They do indeed help software quality and software productivity. But they must be done right. There are many pitfalls along the way, and many people aren't doing them right.

So how do you do it right? Here are his recommendations:

First of all, standards should be terse and to the point. The must rules for writing software, no matter what the installation, should be distilled into a short manual which can be digested quickly, applied easily, and enforced conveniently..... Guidelines, not standards, should be established. This document may be as long as it needs to be, because it contains helpful hints which most programmers will want to read, and length will not be a problem since there is no need or even intention of enforcing these rules.

Second, standards should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.
[...]
Third, enforcement of standards should be mandatory, not something done if there happens to be time.... Enforcement processes should include automated enforcers where possible (these are sometimes called code auditors), and the use of reviews as necessary where automation is not possible. Peer code reviews are one important way of doing standards enforcement, although the main focus of such a review should be on quality as a whole, not just standards enforcement.

Finally, Glass has this warning to Quality Assurance group:

Often quality assurance organizations will perform standards enforcement activities, and pronounce the software to be of high quality.

Microsoft still does not understand security.

It is good to see Microsoft is trying to force their user to give up their love for running Windows in Administrator's account.

But I wonder whose fault is that that induces Windows Users' to fall in love with running in Administrator's account? Certainly not Linux and Unix nor Mac as they do not set up user's account with Administrative rights.

As I have blogged previously, Microsoft could have nipped the bud when it was beta testing Windows 2000 which began to enforce profile security. Microsoft all along has not provided any developer's assistance to toe the line. Instead it makes its installer to set up users with Administrative privilege.

Microsoft's representative seems to contradict himself with comment like this in defense of not following the Linux/Mac modus operandi:

"Least privilege permissions are a part of a good defence-in-depth strategy but it's not the endgame. If everybody is logged-in not as admin or not as root, it is really not going to stop the malware in the long run ... malware is not going to disappear," Grimes told AusCERT delegates.

Grimes added malware could infect a computer using various attack vectors but if the user is not an administrator, the attacks are generally less dangerous.

"Can a malware program steal your password if you are not an administrator? Can [criminals] create a program that waits for you to log into your bank, authenticate and then take all your money? The short answer is, yes, absolutely," he added

No one is suggesting not running at root account is going to prevent malware attack absolutely or the disappearance of malware. Running in LUA, reduced the attack surface and it makes the attack harder to implement as acknowledge by Grime.

Another instance to demonstrate Microsoft does not understand security and still breeding an army of developers with a myopic view of security.

Recently we have discovered that developing strong name assembly in Vista using Visual Studio 2008 requires the IDE to run as administrator. It does not require administrative right to do the same task in XP Pro despite running in LUA. One naturally begs to ask why?

Not only is this stupid but downright dangerous. The reason is that the developers are writing code that could do all sort of stuff a standard users cannot. This results in program that does not run in XP LUA but runs in Vista with the support of UAC redirection. I would have thought Microsoft would not only encourage but demand developer to write code requiring the Least Privilege.

It is causing the same very problem that Microsoft is trying to stamp out. It is a bit late to close the gate when the horse has bolted.

Looks like Microsoft only half-hearted attempting "to break away from its tradition of users being an administrator by default."

Using Runas to run Windows Explorer

I have been using the recommendation from Keith Brown to launch an instance of IE6 from the Admin console to perform administrative task when running in LUA.

Unfortunately IE7 cannot run like this and hence I have refused to use IE7.

Thankfully, the unintended usage of "Launch folder windows in a separate process" in Windows Explorer discovered by Aaron Margosis does the job equally well.

Strange logic to fix Microsoft's security problem - by annoying the users

When Vista was first released, Apple poked fun at Windows Vista for annoying the PC users with a humorous yet deadly accurate commercial. The sad part is that the message conveyed by Apple turns out to be 100% spot on and has now been admitted publicly by Microsoft's Product Unit Manager, David Cross in a presentation in the RSA Conference that they "put UAC into the (Vista) platform was to annoy users--I'm serious"

This has to be one of the most stupid act I have seen as a long term Windows developer to annoy the user to get the developers to change "the ISV ecosystem; applications are getting more secure. This was our target--to change the ecosystem." Microsoft produces SDK, tools and the Operating System and you should use those tools to change the ecosystem.

There are two statements from David Cross in this report that need a thorough analysis:

1. Most users had administrator privileges on previous Windows systems and most applications needed administrator privileges to install or run.
2. "We needed to change the ecosystem," said Cross. "UAC is changing the ISV ecosystem; applications are getting more secure. This was our target--to change the ecosystem"

Mr Cross has shown poor comprehension of figures in his rebuttal that "a myth that users blindly accept prompts without reading them."

Anyone with elementary arithematics will tell you that "Seven percent of all prompts are canceled. Users are not just saying 'yes.'" is another words of saying 93% of all prompts are NOT canceled. Then that user must be saying 'yes'. Hence "It's a myth that users click 'yes,' 'yes,' 'yes,' 'yes,'" is not a myth as substantiated (93% says 'yes') by his own research with opt-in users. With that level of intelligence it is not hard to understand why they had to annoy users rather than using innovative and technically brilliant ways to fix their problem.

Has he ever heard of using tool and assistance as the way to change them? What about changing Microsoft's own practice, which encourages that ecosystem in the first place, since Windows NT 3.1. Sadly, the same practice still persists in Vista. Now I will come to analysis the above statements.

In relation to the first statement, "Most users had administrator privileges on previous Windows systems" and I wonder whose fault is that?

Ever since Windows NT 3.1 was released, it had a security model, albeit not a very tightly enforced one. The separation of privilege account, such as Administrator, and lower privilege ones, now fashionably called Standard User account, existed.

Microsoft has never, even till today, followed what Linux and Unix, do in which Windows NT should never make the user a member of Administrator to maintain a clear separation. In NT, it up to you to create additional users and many could not bother. Hence most people just lives in the Administrator's account forever. This breeds the bad habit, that Mr Cross now finds objectionable, that has been encouraged by Microsoft in succession of Windows, even in Vista.

Microsoft should force the creation of an ordinary User's account and this should be the account user uses. Sure, they need the administrator's account to install and that's difficult to avoid. But at least they should never encourage such a bad practice in the first place. I must confess that I was a great defender of this rather silly and dangerous practice for a long time, until I read Keith Brown's message, which opened my eyes and changed my attitude and practices.

I have had lively discussion with developers and ISV in relation to adopting this good practice to ensure one's code demands the least amount of privilege and that one should be aware of the security model. The results of some of those discussions have been published in this blog.

The tightening up of the Windows Security Model was first introduced in Windows 2000, with beta version years ahead of year 2000. Windows 2000 is already obsolete and over those years, Microsoft has not provided any tools to help ISV to track down those violations. Many are oblivious violations have been committed because they are running in administrator's account. Microsoft Visual Basic 6 is a classic example where it will not run properly in LUA (Lease-Privilege User Account); it needs administrative rights to run. Microsoft provides SDK, Resource Kits and various developer's tools to enable people to write Windows programs. Microsoft could easily provide diagnostic and debugging tools or add support into their premium development tool, the Visual Studio, to help ISV and developers. Yet not one single effort has been released.

Microsoft could have add an audit support into Windows 2000 to allow users or developers to detect any malpractices; similar to the auditing the 'Privilege Use'. Yet no assistance of this kind was provided.

Now in relation to the second statement, "We needed to change the ecosystem", Microsoft has not yet demonstrated a change at all in their Windows Setup practices. I have yet to see a Vista machine whose owner is running with a Limited User Account. All the installations I have seen have been set up with users' accounts belonging to the member of Administrators.

When users are members of administrators in Vista, they are running with a split token, according to Microsoft's publication - a token used for all operation contains Standard User privilege and a token with the privilege rights, which will be used once consent is given, known as "Consent Elevation". This is known as Administrator Approval Mode (AAM). The token with the privilege rights is to permit the caller to perform "Consent elevation because the user simply has to approve the assignment of his administrative rights."

According to this paper on UAC:

Elevated AAM processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate.

Even processes elevated from standard user accounts can conceivably be compromised because of shared state....

The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations.

This acknowledge that the elaborate scheme introduced in Vista is as susceptible to attack as the good old ActiveX installation consent process, which has been extensively exploited by drive-by-downloader, Spyware and Phishing attackers.

By annoying the customer as orchestrated by Mr Cross and forcing user to "reading them", his expert has concluded that these annoying dialog boxes

say nothing about what it will do when it executes. The executable will process command-line arguments, load DLLs, open data files, and communicate with other processes. Any of those operations could conceivably allow malware to compromise the elevated process and thus gain administrative rights.

Even with my technical knowledge, I cannot tell if consenting to the request is wise.

It does not make sense to annoy the customer. It does not make it any safer. Microsoft should help ISV and developers by giving them tools and logging facility. You have an Event log and Eventing support in Vista (don't get confused with Web Service eventing); use them!

The bottom line is: I am not against Microsoft attempting to "to change the ecosystem" and I am all for it. But to use something to create annoyance to the users as a way of forcing the ISV or developers, many of them are ignorant of the security model, is to ask your users/customers to do the work for you - unpaid of course! Microsoft you are abdicating your technical leadership.

Microsoft can and should immediately, as it is long overdue, to provide tools to help developers to locate these problems. At the moment, I have frequently use FileMon, RegMon or Process Monitor, to track down violations and all these tools are free from Microsoft. All Microsoft needs to do is to expand these tools capability to home in on the violations and report to the developers.

The current implementation of virtualizing privilege access to file and registry systems without any alerting system to the developers or users is just sweeping the problem under the carpet. In fact, such strategy often create confusion for those machine shared by many users as the Windows ceases to have Machine-wide (only one instance) and Per-User settings. All users are then permitted to alter their Program Files data or HKLM registry data as these accesses are virtualized to the user's profile area.

Microsoft has failed to bite the bullet to produce tools to help the developers. Rather than using AAM and telling "developers must assume that all Windows users are standard users, which will result in more programs working with standard user rights without virtualization or shims." why not do something about it? Why not made your Windows users standard users after Windows set up? After all it is your operating system. No wonder Apple pokes fun at you and rightly so!

Brisbane Transport Smart Card tries to out smart its customers

Recently, Brisbane introduced its transport smart card system called Go Card that comes with its sets of rules and additional benefits to entice the Brisbanites to give up the extremely generous paper ticket to use this system.

There are no shortage of blog messages alleging that this is an underhand way of getting more money out of the Brisbanites. Is this true? Is it trying to out smart its denizen?

Analysis using their published fare table for train journey confirms the allegations are well founded. For example, the followings are based on 2 journeys per day:

1. For travelers buying monthly tickets, Go Card saves you money if you travel 4 days or less.
   
2. It seems Go Card is targeting less frequent traveler or those using public transport on ad hoc basis. In this case, the never-expire store value compared to finite expiry day associated with paper ticket is a definite attraction.
   
3. It seems Go Card is set to break even on Monthly ticket price and that the traveler travels 5 days, except for distance (>10 zones ) travelers. This is ignoring the money for Go Card's deposit.
4. For people living more than 3-zones, the 3, 6, and 12 months ticket is more cost effective than Go Card.
5. For people living in 3-zones or less, Go Card is more cost effective with 6, or 12 months ticket.

Of course, the Go Card cannot match the benefit of paper ticket that allows you to travel unlimited trips within the same zone coverage. If you rely heavily on public transport, paper ticket is way to go. The Go Card becomes really expensive the more you travel irrespective of your ticket purchasing pattern.

So it seems the government is trying to use the convenience sales pitch of Go Card to out smart the consumers and to discourage people to use public transport.

Well done - Sony BMG has been caught pirating

What an irony for a company that gave the root kit an elevated awareness by planting it in their customers' machines in the name of protecting its IP has now been caught literally with its pants down.

Well done and I applaud PontDev not to settle and to give Sony BMG a swift kick in its backside and to humiliate Sony BMG.