About Software

To write a good robust software package, that serves the best interests of its users, first analyse carefully the task that the package is required to fulfil. The relevant activities of the human users form part of this analysis. From this analysis, con­struct some form of logical model of the method by which the package will fulfil its task. Then iteratively reduce the logical model to its simplest form, excluding any super­fluous functionality, which may have hung over from the manual method­ology trad­itionally used to perform the required task.

Create a Logical Model

There are many established kinds of logical model up on which a software package may be constructed. For most of the projects on which I have worked, the most ap­propriate kind of model has been what's known as the finite-state machine. In each of these cases, the finite-state machine was made to work by receiving and send­ing messages from and to the user. The logical model was thus what is called a message-driven finite-state machine, which is generally referred to more concisely as a finite-message machine or FMM.

The logical essence of an FMM is illustrated on the right. It is probably written as a dæmon, starting automatically when the operating system is start­ed, or being started manually by a terminal com­mand. At start-up, it does its initialization proced­ure and then enters its WAIT state. Here it listens on a designated calling port for messages from human users. It responds to only three possible messages: "shut down", "execute Program 1" and "execute Program 2". If told to shut down, it does its shut-down procedure and stops. If told to do either of its two types of task, it runs the appro­priate program and then returns to its WAIT state. Each program, once it has completed the task re­quested by the user, sends a response message. The FMM could be made to invoke a new instance of the appropriate program to handle each arriv­ing message. Alternatively, it could always use the same single instance and queue incoming mess­ages, wait­ing each time for the program to term­inate before dealing with the next message in the queue.

The chosen form of implementation of the logical model will depend not only on the nature of the user task, but also on the type of computer and operating system selected. At this stage, the logical model of the user application must be rigorously documented in such a way that the eventual users will be easily able to understand it. This part takes a lot of skill and patience.

Code-up The Programs

Next, select an appropriate programming language (such as C or Java) and code up the various message-handling programs which make up the package.

For example, each of the FMM's message-handling programs could be written in C in the form of a Unix command. A Unix command is like an imperative sentence written in English. It comprises a subject, verb, possibly a verbal qualification and an object, as formalized in the following table.

subject	verb	qualification	object
user	program	options	argument(s)
rob@neddy	edit-customer	address-only	customer123 "15 Bridge Street..."

The equivalents of the English parts of speech, as they appear in a Unix command are shown on the lower line of the table. In normal circumstances, the identification of the user does not need to be explicitly specified. It is implicit because he is who­ever is signed into the terminal at the time. His identity is shown already by the operating system before the entry prompt. However, for a complete FMM message, which could have come from any one of multiple users, it is necessary to specify the user explicitly, as it is in an English sentence when the subject is not the speak­er. In the example above, the user is a human called "rob" who is currently logged in on a computer whose network name is "neddy". Rob has requested a change to a cust­omer's address details, giving the modified address as part of his request.

If the user be on a different computer from the one hosting the FMM, then the com­mand line message above must be encapsulated within an IP packet in order for it to be passed across the network that links the two computers. The FMM, on receiv­ing the IP packet, would then strip out the internal command message and pass it to the Unix shell to invoke the appropriate message handling procedure (Program 1 or Program 2 in the above example). Of course, the FMM in a real application pack­age would most likely have quite a large number of message-handling programs.

Programming Policy

Make your package future-safe. This means that it must be designed to be as un­perturbed as possible by changes that may arbitrarily take place within the under­lying operating system and programming language in which it is written. At some unpredictable time in the future, your program, after a re-compilation, could sud­denly begin to work incorrectly or stop working altogether because functionality in the underlying operating system or linked library has been modified. To avoid this it is necessary to adopt the strict policy of using the minimum necessary functionality of the underlying system and language.

My preferred language is 'C', which is a very stable programming language. Not­withstanding, for any given application, I use only standard link libraries like math­ematics and X-server. I avoid any special-purpose libraries, preferring to write the functionality they would have contributed into my program. This leaves me in total control of all that my program does. And nothing any third party may do can take that total control from me.

As regards minimising the use of the features of a programming language, I once did the illustrative exercise of converting a 3500-line program to avoid using C's struct feature by parsing the data I needed straight from the disc buffer. Although this would have been slow in a bygone age, today it is fast because modern machines have very large file buffers and modern high-capacity disk drives themselves have large RAM buffers on-board. This practice also resulted in tighter and more intuitive code.

Back in the mid-1980s, a colleague and I coined the term RISP [Reduced Instruction Set Programming] for this policy. We obviously took it from the term RISC [Reduced Instruction Set Computer]. RISP gave us a secure un­derlying platform, with very long-term stability, on which we were able to confidently build robust applications.

For ease of creation, integration, testing and maintenance, I prefer to place the whole of my meticulously commented source code in a single well organised text [.c] file. In this form, I don't need to set up a complicated 'make' procedure, which takes forever and a day to compile, link and build. A single file of around 10,000 lines of code will recompile in about a second on a modern PC.

Design The User Interface

The next stage is to create an electro-physical in­terface through which the human users may send messages to and receive messages from the logi­cal model within the computer. Nowadays, this is normally done by a client-side program, which constructs and operates a graphical user inter­face, an example of which is shown on the left.

In his day-to-day work, the user's focus is on his business: not on your system. For him, the computer and its software are merely a tool. For this reason, the GUI should be to him as transparent, unimposing and self-intuitive as possible. Con­se­qu­ently, when designing the window or frame layout of the GUI, don't indulge your graphic design skills by creating needless eye-catching glitz and fancy unconven­tional widgets. This will serve only to distract the user from his business task, make the GUI more difficult for him to use and slow him down in his work. It will also make the GUI much slower to learn for new users. Keep the design of the GUI as simple and conventional as possible. Make labels and text clear and easy to read. Use only standard widgets: buttons, fields, links, menus and tabs, which users can intuitively recognise.

The human interface does not necessarily have to be graphical. In a lot of cases an old-fashioned text-based interface is more appropriate; being simpler, faster, quick­er to learn and easier to use. Through the interface, the information the user needs to see must be presented in a form that is most easily digestible by the user. This is not necessarily the form in which it is most convenient to retrieve the required in­formation from the logical model.

A user probably already knows what he needs to do to fulfil the day-to-day requirements of his job. What he probably does not inherently know is how to do this specifically through the [new] user interface. It is there­fore essential to include, as part of the user interface, procedural instructions for each possible interaction that may take place between the human user, sitting in front of his screen, and the logical model hidden behind it. The procedural instructions should have links to back­ground information to give the user the broader context he will need to fully un­derstand what is going on.

There are many different ways of providing this user documentation. The first is conventional paper books. Another is to write the documentation as a set of inter­linked HTML pages on a CD or hard drive. A rather novel option is to implement the user interface as a Java applet embedded within its own HTML documentation.

My preferred option, however, is to implement the user documentation as a set of context-sensitive help texts. In this case, when the user clicks the HELP button on the screen, a window frame opens in which appears explanatory text pertaining specifically to the step in the program with which he is currently involved. These help texts must be carefully crafted and iteratively improved in the light of difficul­ties experienced by users. The context-sensitive option saves the user having to go and find the information he needs in a book or file reader. For this reason, I think it is the best option for minimising user stress and fatigue.

Typical Implementation

Most software packages nowadays are expected to be able to provide service to users spread over many computers. These may be located not only in different parts of an office or factory, but also in different parts of the country or even the world. The FMM part of the package must therefore run within a central server, while many copies of the user GUI part of the package must run within many differ­ent client computers in different locations.

Below is shown the server computer running the FMM Server Software with just one of the many possible client computers connected to it via a network. The network can be either a local area network or the Internet itself.

The user enters his requests to the FMM through the package's GUI, as shown on the screen in the above diagram. The client software, operating behind the GUI on the user's client computer, converts his request into the form of a command-line, encapsulates it in a network packet, and sends it to the FMM running in the server. The FMM in the server then executes the requested command and returns the re­sults as a message sent back to the client software of the user concerned. The GUI software then displays the results for the user to see on the screen.

---

A well-designed software package, thus constructed and implemented, should be self-teaching to reasonably self-motivated new users and should rapidly become maintenance-free.

From my experience over the 50 years since I began programming computers, pro­ducing software of this kind, and in this way, will certainly provide you with satis­fied users. But it is definitely not a recipe for commercial success.

Opting For Commercial Success

To write a commercially-successful software package, which maximizes the profit of its producer, one must already have, or be able to acquire, rather a lot of capital. What follows involves initially spending an awful lot of money.

First survey the market. Conduct surveys to find out what the most influential set of potential customers actually want. Be aware that what they want is what they think they need. This is not necessarily — in fact, it rarely is — what is best for them.

The results will be a mess. The surveyed potential customer is not usually an ex­p­ert systems analyst. He will probably have his own cloistered traditional way of do­ing the task concerned, which will have just "grow'd" like Topsy as his business evolved. Consequently, this way (or methodology) is unlikely to be very efficient. It probably contains procedures that "go round the sun to meet the moon". But it is what the customer wants. So it is what the customer must have.

Create an amalgam of the survey results for all the potential customers whom you surveyed. Thus you have a market view of what the task is and how it should be done. The amalgam is guaranteed to be even more of a mess than the singular view of any one of the survey participants. Notwithstanding, you must use this as the basis of the illogical model from which you will construct a software package to fulfil the task concerned for the industry you surveyed.

You now have the specification of a software package, which conforms to the wish­es and desires of the generic customer in the market-sector you surveyed.

The Need For a Glitzy GUI

Now to write the software. Never mind about the underlying functionality that must take place within the server. Begin with the GUI. Design a user interface that dis­plays what the generic customer wants to see and how he wishes it to be pre­sented. This is unlikely to be all the information, and nothing but the information, that he really needs. It probably contains superfluous information he does not really need and lacks other details that would be useful and could even eliminate the need for one or more other displays. But it is what the generic customer has asked for.

Remember that you are building a software package for sale. You therefore need to impress the potential buyer. The buyer is rarely the user. The buyer is who has the money, such as a company executive. The user is generally a lowly employee. You don't need to impress him. The majority of buyers — the generic buyer — is not tech­nically knowledgeable. He can therefore be impressed only by what he can actually see. For this reason, you must make your package's GUI appealing to look at. It must be a graphical work of art, with suave colour gradients, delicately sculp­tured buttons and a (possibly animated) corporate logo, which exudes precision, excel­lence and commercial confidence.

Fancy eye-catching presentation is absolutely essential. It must be forever new and different. Just like a fashion show. This is what the buyer has grown to expect. At software fares and business exhibitions, what else can the ignorant generic buyer go by, as his aching feet tread their way around the endless stands, glancing at the jazzy screen displays through the thick leaves of the ubiquitous rubber plants? Of course, these jazzy displays — with their glowing colours, idyllic images and wrig­gling applets — take forever and a day to load or update. But who cares? He, the buyer, does not have to suffer the daily frustration of their wobbling procrastin­a­tion. That's for the poor user to endure for ever after. He's the one who has to spend his time waiting upon the sluggish GUI, straining his eyes trying to read the merged r's and n's of its immaculately set microscopic type. He's the one who has to play the game of "guess where to click" within the unconventional graphical con­fusion on his screen.

Next, create a menu or tab system within the GUI to accommodate all the actions the generic customer wishes to do in order to manipulate his information in the way he wants. Minimise the use of words [text]. Instead, represent as much as pos­sible using icons: little stylised pictures that represent objects and actions. Finally, get your programmers to rapidly cobble together a server-based handling program for each action. It doesn't matter if it's full of bugs. What is important is to get it out of the door and into the market as quickly as possible. You can straighten out all the problems later through your on-line automatic update facility.

Programming Policy

You need to maximise your profit. So you need to minimise your costs. At least, in the short term. Therefore choose a modern high-level language that can be used by young programmers with little training and experience: they're cheaper. The high-level language you select will naturally therefore be structured on more of an ad­ministrator's mindset than that of an engineer. It will be loaded with libraries full of 'labour-saving' features, which will be under on-going development by the vendor of the language's labyrinthian Program Development Environment. An excellent ran­dom source of upward propagating errors that will keep your young programmers in an eternal trouble-shooting samba dance, thereby maintaining an ethos of leading-edge hyper-activity to awe-inspire visiting clients and industry press.

Your software is extremely valuable intellectual property. You need to keep it safe. For this reason, you must take all possible measures to ensure that no employee or group working for you ever acquires a full overview of whatever software product you are creating. Knowledge is power. So anyone with overview knowledge of your entire software product has a lot of potential power within your organisation. More significantly, he has the power to set up on his own in competition with you or to leave you, together with his overview knowledge, to work for a competitor.

To protect yourself from this danger, you first must divide the functionality of your software product into its natural component sub-functions and assign the program­ming of each sub-function to a separate small team of programmers. This requires that you write a specification of the logical interface for each connecting path bet­ween sub-functions. Each sub-function will comprise a set of object classes. A sub­function is thus implemented as what, in Java, is termed a 'package'. Each of your programming teams creates a 'package' comprising a set of 'classes', each of which is written by one of the team's programmers. This way, each of your programmers has knowledge of only a very small part of your overall software product.

The advantage of this approach is that each programmer is able to concentrate all his effort towards perfecting his own very small part of the overall software product. He can test its specified functionality thoroughly. However, this blinkered approach to software production has a price. A programmer can never be sure what silly things other programmers, who are writing classes that interact with his class, may do by mistake or misunderstanding. For example, another programmer's class could attempt to change the value of a variable that only I [i.e. a method internal to my class] should be able to change. I must therefore make such variables read-only for all outsiders. This necessitates that I write extra read-only access and range val­idation methods, which is extra code. And this extra code soon begins to mount up.

Next comes the problem of integration. All the classes written by programmers in each team must be made to work together seamlessly as a 'package'. Then, all the packages that make up your software product must be integrated to work together correctly. Though each single class may perform its function perfectly, simply run­ning them together may not necessarily cause the 'package', of which they are each a part, to work correctly. Though each class may follow its inter-class interface specification, it may not be doing it exactly the way the writer of an adjacent class interpreted that same interface specification. This is because an interface specific­ation is over-simplistic. The only true interface specification, between one program­mer's class and another programmer's class, is that other programmer's class.

This is why my preferred program structure is the full continuous integ­rated source code listing that I mentioned under 'Programming Policy' in the first part of this article.

Thus, at the 'package' integration stage, it is necessary for the programming team leader to battle out why there is a functional incompatibility between various of the package's classes. This can be a real bitch. The team leader must somehow acquire a holistic view of all the code in all the classes of the whole package for which he is responsible. And following the logical processes through code that is divided into separately programmed classes, connected only through narrow interface specific­ations, is far more difficult than doing the same within a single integrated program listing. I've done both.

Notwithstanding, there is an even harder task ahead, namely, that of integrating all the packages to form your working software product. For this, the team leaders will have to work together to trace and resolve any inter-package malfunctions and in­compatibilities in the same way. This is even harder to do. A holistic view of the whole software product is necessary and analysis of malfunctions can involve the need to burrow down all the way to code level within classes.

In other words, in the ultimate analysis, a software product has to be viewed and known in its entirety as a vast continuum of code anyway. It is a machine. And a machine, by nature, does not have a hierarchical structure. It has more the form of an interconnected network of components, each of which contributes its specialised function to the overall functionality of the product.

Hierarchical views are things of the mind, through which human beings try to get handles of understanding on how the real world works. Thus a hierarchical view of a software product is simply the management structure of the software project: not the product it is creating. Unfortunately, for this to work, management has to force the software product to conform to the project's management structure.

This requires that the package, produced by each team, must include what are, in effect, management classes to manage the package's functional classes. So too, at the project level, the various packages must be managed by super-management classes — or even super-management packages — in order for the ultimate product to be implemented under the control of a hierarchical management structure. And the amount of necessary coding skyrockets, as does the product's propensity for errors and malfunctions, which must all be hunted down and resolved.

But your vast churning mess of headless chickens [project managers, team leaders, programmers, troubleshooters] is exactly what you need for guaranteed success. It gives you a positive public image:

1. as a corporate leviathan selling vital leading-edge software products,

2. as a provider of high-tech employment for your vast whizz-kid workforce,

3. as an ever-present service provider to your grateful customer-base, continu­ally updating your software to get all the bugs out, and finally

4. of a solid high return revenue source for your investors.

A true pillar of society. And it keeps your intellectual property safe from theft by defecting employees.

Don't Reinvent The Wheel

For each functional area of your software, try to find your required functionality in the components of standard and freely available third-party libraries. If the 'wheel' already exists, don't waste development time and money reinventing it and writing it as part of your program. Just use what others have already done. After all, this is the principle of re-usable classes for which languages like Java were designed.

The re-use of functions and classes is fine and of great benefit at system level. Notwithstanding, in all my programming experience, I have rarely seen occasion where it would have been advantageous or even practic­able at application level. It is invariably more economical, intuitive and maintainable at application level to write the functionality in-line.

Of course, the technical downside of this is that the 'wheel' that you find in a third-party library isn't necessarily exactly the 'wheel' you need, but it looks as if it will do. Its interface specification tells you what inputs it takes, what it does to those inputs and the outputs it returns to you. But it is over-simplistic and it does not tell you all of what it does or how it does it. The only way you can be sure of all that is to look inside it. But you can't because it is supplied inside an object link library. It may contain bugs or even intentional features you do not know about. It may be­come modified without your knowledge with the result that the next time you re-compile, all hell will break loose.

But this is wonderful. It makes your on-going services indispensable sorting out the mess. You're the good guy, right?

Pamper Your Customers

Make things easy for yourself and your customers, irrespective of the vulnerabilities to which it exposes their private and corporate data.

1. Add superfluous functionality to your products to satisfy your customers' every request and desire.

2. Give them products that connect 'seamlessly' across the Internet so that teams can work in conjunction with members distributed all over the planet.

3. Build automatic updating soft­ware into your products so that bugs can be fixed and features added without hav­ing to physically attend anybody's actual computer.

4. If you are maintaining server software, do it across the Internet by 'secure' remote shell commands given in the server's configuration meta language. This way, you don't have to leave your seat or disturb your client with physical visits.

5. Better still, save your customers the trouble of maintaining software and protecting data in-house by encouraging them to use only 'light client' PCs, divesting all heavyweight software functionality and data storage onto your gigantic cloud service where it is 'safer'.

Now you've got them where you want them. Lock them in, baby!

Let in The Hackers

These 5 carefully crafted measures should give the hackers a good chance to get in there. After all, it only takes one compromised employee to cough up a password to gain them access to a corporation client's computing facilities, be they in house or in your cloud. This opens up many opportunities for hackers.

1. They could exploit a careless piece of superfluous added functionality to corrupt, steal or lock up your customer's data.

2. One could enter as a hidden member of a trans-global team to observe what the team is doing and steal information.

3. They could compromise the automatic update facility by acquiring the key from a disgruntled employee to implant Trojans, viruses and spyware into your customer's computers or cloud area.

4. They could reconfigure your customers' web servers or your cloud server using the server software's configuration meta language over a secure shell in order to steal, delete or lock up your customer's data in a ransom attack.

5. Your government could demand that you lock up a foreign customer's data and withdraw cloud services as a means of applying sanctions against a foreign customer, who could be an individual, corporation, bank or govern­ment. Frightening?

But this is exactly what you want. It generates unlimited work for you and keeps you in business forever.

The Training Gravy Train

Unfortunately, what action appears in which menu or sub-menu depends on the methodology that evolved within the generic business of the generic customer with­in the industry concerned. Be aware, however, that no one real customer is the generic customer. Each user will be accustomed to doing things somewhat differ­ently. So no real user will be familiar with doing things the generic way.

Furthermore, the generic methodology will inevitably be rather a jumbled mixture that is anything but logically optimised. Consequently, no user will be able to work out how to use the GUI simply through common sense. He will have to be specif­ically taught how to use the GUI, learning by rote what to do in each situation. The copious use of icons adds the necessity for the user to be taught an entirely new over-simplistic grammarless non-intuitive sub-language for each application, which adds to the amount of training required.

To be the producer of a commercially-successful software package, this is just what you want: a package whose GUI looks like an over-dressed Christmas tree, which is distracting and difficult to get the hang of. Why? because it creates a grand busi­ness opportunity to sell training to customers who, having bought your package, cannot use it without training.

The Consumer Market

With the advent of tablet computers and the smartphone, with their extremely small screens, the GUI has had to be made ever more simplified and compact. This has driven the tendency towards all-icon GUIs.

Icons constitute a sub-language that is separate and distinct from a natural spoken and written language. Icons are not standardised. What an icon means depends on its context. Different software has its own set of icons. Hence, a user has to learn what each icon means within each different application program. Consequently, al­though an iconic sub-language may appear simple to look at, it has to be separ­ately learned.

Icons are easy for pre-school children to grasp. Indeed, as I understand it, they were created within the context of the way pre-reading age children think. As a result, their scope is very limited. But, as St. Paul said in 1 Corinthians 13.11:

When I was a child, I spake as a child, I understood as a child, I thought as a child: but when I became a man, I put away childish things.

The thinking processes of adults are very different from those of pre-reading age children. Icons do not serve well in complex tasks, and if made to do so, become acceleratingly cumbersome.

GUI users are thereby becoming increasingly forced to do things the way a pre-reading age child would. It is like the television sound bite and the small-block newspaper ad. It reduces the adult's attention span and scope of thought to those of a child. It thereby erodes one's ability and propensity to think as an adult.

Whether intentional or otherwise, the way in which the graphics user interface has developed, especially for small personal devices, has tranquillised the adult mind, focussing it onto banality and away from serious thought. Hence the endless truck-loads of trivia that traverse the Internet daily via email and social media. Perhaps this is what the powers that be want: a doped, placid — and hence easily controlled — populace.

Advertise, Advertise, Advertise

All the while, pour loads of your initial capital into advertising your software as be­ing "easy to use". Don't worry. Since your software is destined to dominate the mar­ket, it will be the only software that most will ever see, and the stupid consumer will never be any the wiser.

Place a lot of your advertising in newspapers and specialised industry magazines, thereby obligating their respective journalists to write glowing reports in articles that endorse your software, while issuing unfounded warnings to the hapless buyer against purchasing the products of "unknown" small-fry.

Now you are well on your way to dominating the software market. However, by taking a few dubious extra steps, you can make your position in the market pretty well invincible, while, at the same time, creating further opportunities that will en­able you to really rake in the money.

The Virus And The Trojan

Covertly commission various renegade software experts to create programs known as viruses and Trojan horses. These are programs which, by installing them­selves secretly within people's computers, can cause them to run painfully slowly and per­haps even corrupt or destroy people's personal data files. Creating these programs requires considerable technical knowledge, skills and resources, so it is necessary to bankroll their creators. However, to avoid any suspicion, spread the illusion am­ong the general public that these programs are easily-written nuisances cobbled to­gether by rebel hackers and schoolboy pranksters.

Again covertly, distribute these viruses and Trojans throughout the Internet. This is best done by coming to some arrangement with the operators of certain web sites, which contain active procedures that will download the viruses and Trojans auto­matically into a person's computer whenever that person visits the site. The safest kind of website to use for this task is the porn site. This will greatly discourage people from trying to track where the virus or Trojan came from because the victims will not want to admit to accessing sites for the purpose of viewing dirty pictures.

You have successfully created a real and present fear within the market. The mar­ket needs a saviour. And whoever would be the saviour shall, in the execution of his act of salvation, stand to make a lot of money. You therefore commission somebody to write what shall become known as anti-virus software, whose task is to hunt down and destroy any and all viruses and Trojans that may be infecting a person's computer. To avoid any suspicion of collusion, you and the anti-virus soft­ware prod­ucer agree that he shall present himself to the public as a completely independent business interest. Driven by the fear of losing personal data, and frust­rated by slug­gish computer performance, the public rushes out to buy the anti-virus software.

In the meantime, keep your renegade software experts working hell for leather to keep producing better and ever different viruses and Trojans to continually circum­vent and thwart the defences provided by the anti-virus software. Likewise, the anti-virus producer keeps producing and selling a continuous stream of updates to com­bat the ever-mutating viruses and constantly evolving Trojans. So the wheel turns. And the money keeps rolling in.

Lock Out The Small-Fry

Next, completely lock out of the market all but yourself and other members of the global clique of the big software corporations. Make sure that the dedicated hard-working highly-skilled independent software artisans, the world over, never get a look-in. Do this by popping up a warning message whenever a person tries to install any "unknown" software from any "unknown" supplier, implying that the software concerned could be "malware".

Malware is a derogatory catch-all term that includes viruses, Trojans, and all other soft­ware that is presumed, without basis, to be potentially harmful to people's com­p­uters. It also includes "spyware": a legitimate looking application program, which contains extra undeclared functionality. Such functionality could, for instance, read a person's private files on his hard drive, surreptitiously passing any information of interest to an unknown remote third party across the Internet.

The warning message pops up whenever a person tries to install any software whose producer has not paid the high price for having his software certified, by the global clique, in order to obtain a digital certificate, which would allow it to be in­stalled without the warning message appearing.

The Beckoning Back Door

Now for your pièce de résistance. To keep your quick out-of-the-door bug-ridden software working acceptably well, you need to be able to update it very regularly. Whether your software be an application package or an operating system, you need an automatic update facility. This works behind the scenes on each user's computer. The user is generally unaware of when it is operating or what it is doing. To be able to work, however, it needs full administrator access to all resources with­in the user's computer. It must therefore be able to read and write to any part of the user's hard drive.

This presents you with rather a tempting and potentially rewarding opportunity. You build, into your automatic update facility, a back door to every user's computer. Through this back door, you access any and all the personal information the user has stored on his hard drive. And you do this without him ever being aware of what you are doing, or that you are doing anything at all. From this personal information, you construct a consumer profile of each user. You then sell a vast number of these profiles, for an extremely good price, to commercial interests who subsequently use them to target people more precisely with their product advertising and promo­tions. This is probably your greatest money-spinner: the one thing that positively guaran­tees your commercial success.

But there is a far more sinister use to which this back door may be put. It can be used by government agencies to expedite the most invasive, yet completely steal­thy, form of spying upon any chosen individual. A legal instrument could be issued, forcing you to give them access to the world's back doors. Criminals too, if they could compromise one of your relevant employees, could also gain access to any and everybody's back door. That should make everybody feel uncomfortable. Not that he may have done anything wrong. Personal information on one's hard drive, when taken out of context, can easily be misinterpreted and misunderstood.

As well as having an operating system, a personal computer has many application programs installed, each with its own automatic update facility running in the back­ground. This potentially provides as many different vendors with as many back doors into the user's personal files. The opportunity is there. It is so easy to imple­ment. It can operate unseen. Nobody will know. Is it therefore realistic to suppose that all software producers would, through moral virtue, wilfully refrain from engag­ing in such skulduggery?

Conclusion

So, how can the poor lowly user be protected? How can he gain real security? The only solution, in my opinion, is open-source software. With open-source operating systems and application programs, any one of millions of independent program­mers, all over the world, can examine whichever part of an operating system or application program he wishes and thereby know exactly what it is doing.

Of these millions, there will always be somebody who decides to get his claws into every last piece of code and who will blow his worldwide whistle on any program that is doing something against the best interests of its users.

---

© Feb 2014, May 2017 Robert John Morton
Related article: Who Owns Cyberspace?