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.