• it ensures what actually runs on a computer is really what is supposed to run
• it allows the easy detection of any computing trick that could produce unwanted results.

ClearSoftware is not only applicative software but also the whole operating environment in which applications are executed.

• trust the applicative software
• trust the operating system in which the applicative software runs
• trust that nothing else but the applicative software runs on the computer
• test ourselves all the software on our computers

Please watch the ClearSoftware animation

To be ClearSoftware compliant, any software must adhere to the following points:

1. the software must be distributed as a read-only optical media containing
   • applicative software
   • a complete Open Source operating system and its base services (web server, databases, browsers…).
2. (note 1) distribution media must be bootable and self-installing
3. (note 1) installation must automatically
   • do a full format of ALL disks
   • install the Open Source operating system
   • install the Open Source applicative software
   • boot the newly installed system
   • run the Open Source applicative software
4. the operating system must be an Open Source operating system downloaded from the Internet (note 2).
5. any customization to the original operating system must be 100% human-readable text files directely used by the operating system without any need of compilation. Whenever possible the above customization files must be contained in a single folder "A"
6. applicative software must be Open Source coded in an interpreted language so that its human-readable source code is directly executed by the base services of the operating system without any need of compilation
7. applicative software must all be contained in a folder "B" and its subfolders (if any)
8. a ClearSoftware distro must be the merge of:
   • the original operating system downloaded from the Internet
   • the folder "A" (operating system customizations)
   • the folder "B" (applicative software)
   • the text file ClearSoftware.txt that must contain the full identification of the orignal operating system and all the info about its customization, as it follows:
     • identity of the original operating system (name, version and release)
     • URL from which the ISO of the orignal operating system has been downloaded
     • date and time when the orignal operating system has been downloaded
     • MD5 or similar check of the orignal operating system
     • full path of the "A" and "B" folders
     • full path of all the files of the orignal operating system that have been customized but could not be placed in folder "A"
9. the final distro must be published on the Internet in the form of ISO file together with its MD5 (or similar) checksum so that anybody can download the final distro and install it on his/her computer to analise and test it

1. ClearSoftware can be distributed in the form of a bootable Live CD (or DVD) if the applicative software allows it. Doing this way applicative software is run from the booted CD (or DVD) and hard disks of the hosting computer could also be left untouched
2. since latest release of any operating system may have problems still to be discovered, it is wise to download from the Internet an older release. It doesn't matter if it has known bugs, as far as they don't impact on our application (like bugs related to devices we don't have or related to base services we don't use). Using an old release also ensures that nobody may have hacked it long ago to alter the behaviour of our today's ClearSoftware application
3. the final distro can undergo a process of mass duplication or replication. A logo may be impressed on each CD (or DVD) to certify it's original.
4. anybody can verify the content of each CD (or DVD):
   • computing its MD5 (or similar) checkum and comparing it with the one published on the Internet
   • running a script that searches for differences between each file of the original operating system and its corresponding in the ClearVoting distribution. Such search, done only on files not listed in ClearSotware.txt, should find not any difference.

1. code the applicative software
2. choose the Open Source operating system to be used to run the applicative software
3. download from the Internet the ISO file of the chosen Open Source operating system
4. create the file structure of the final distro adding to the operating system the folders "A" and "B" and the text file ClearSoftware.txt
5. burn the master CD (or DVD) of the final distro
6. publish on the Internet the ISO file of the final distro and its MD5 checksum (or similar)

Here it follows an example of a ClearSoftware application.
Users interact with the application by means of a web browser. The browser communicates with a web server that interacts with a mysql database to access data. All the three (web browser, web server and database) run on the same computer, so no network is involved. For security purposes no network should be connected, so that no virus, no worm and no hacking can interfere in our application.

The web browser, the web server and the database are all part of the Open Source operating system downloaded from the Internet, thus the only code to actually write is the applicative software (yellow).

Applicative software is written in any interpreted language (PHP in the example). Thanks to the lack of a compiling phase the source of the applicative software is what the base services of the operating system will actually execute. This allow people to see with their eyes what it will actually run (sort of WYSIWYG). Furthermore interpreted languages are high level languages thus technicians can easily review their source for bugs or hacking.

No other part of the system (light blue) needs to be reviewed since they all come from the Linux distribution downloaded from the Internet. Of course the right behavour of the ClearSoftware distribution must be tested, but there is no special reason why the web browser, the web server, the data base, and the other services of the Linux distribution should be hacked or faulty to make ClearSoftware fail during real-life running and not during testing.

Most of the times we don't need to know in detail the software we use because we simply compare its output with the expected one (e.g. we move the mouse and we check if the pointer actually goes where it should). But same times we deal with unverifiable input data or with event that must follow a given law (usually the law of equal chance) in a term that is too long for us to verify it. For examples:

• voting. Nobody can ask voters whom they voted for, so nobody can verify if the vote recorded in each elector's behalf is true or not. Electors must trust the way their votes are collected and counted
• gambling. To be fair, gambling must be based on truly random events, but no single gambler can verify it, unless he gambles for days and days without a rest. Thus gamblers must trust the way such events are generated

Thus fairness of elections and gambling can be ensured only by means of public and verifiable procedures. It is not by chance that fairness of elections has been based upon ballot papers publicly managed and counted and that fairness of gambling has been based upon cards publicly shuffled and dice publicly thrown.

It's quite obvious that for voting no undisclosed software should ever be used. Open Source is often proposed as a safe way to use computers in voting. But Open Source by itself is not enough because:

• it's practically impossibile to verify that the program being run in all polling stations is really the one originating from the compilation of the verified Open Source sources
• rigged alterations to the results could also derive from fraudulent modifications of compilers, operating systems, system libraries, interfaces and other high level applications

ClearSoftware addresses all the above points in a simple, cheap and verifiable way.