e-Voting and XML: a case study of a UK government local election pilot

XML is an enabler to e-voting applications. It ensures that these applications conform to a standard that has been laid down by an independent body. Enabling different voting applications to pool disparate information into one recognisable format

1. e-Voting and XML: a case study of a UK government local election pilot

In May 2003, 17 UK local government authorities participated in an e-Voting pilot project.

Voting is not compulsory in the UK (as it is in some countries). However, voter turnout varies enormously from election to election, and from area to area and is widely considered to be much lower than desirable . Overall there has been a consensus that ways should be examined to increase voter turnout and thereby strengthen the democratic process. The e-Voting Pilots were therefore initiated to examine the effect on voter turnout in local government elections by providing the public with a variety of ways to cast their votes that reflect the existence of new technologies, including:

As one of the participating vendors, we present a case study of the Internet and i-DTV voting methods, focusing on the role of XML (Election Mark-up Language being the approved variant) in this project, and how it contributed to the success of the pilot – ensuring, with only five weeks of development time, a secure, fast, anonymous voting process. The end result was that voter turnout in the pilot areas in which we participated increased by almost 20% over previous elections.

This study has been designed to demonstrate how XML can be a significant enabler to e-voting applications. It explains the importance that applications conform to a standard that has been laid down by an independent body. It shows how different voting applications can be manipulated to pool disparate information into one recognisable and extensible format, so that these different applications can communicate with one another. Equally importantly, it facilitates a rich, yet easy to follow user experience across many different voting platforms.

This session illustrates how, harnessed correctly, XML can make e-Voting an effective, secure and democratic method of casting your vote.

2. Background

The e-Voting pilots were set up by the Office of the Deputy Prime Minister (ODPM) as part of the e-democracy study. One of the main aims of the pilots was to “facilitate participation in elections by making it easier for citizens to vote in ways that reflect modern lifestyles.” As modern technologies evolve it is seen that electoral systems should make use of these technologies as they are proven, so as to enable citizens to participate in elections with a choice of voting methods.

Most of the pilots were planned to extend rather than replace the more traditional methods of the ballot box and postal voting, thereby providing the citizen with a wider choice of voting mechanisms.

There were 17 areas selected for participation in the UK pilots. Some of the published aims of the pilots included the development and testing of technical and procedural changes needed to enable robust solutions to be available for widespread implementation.” The anticipated benefits were:

3. The areas of involvement

Our participation in three of the pilots was as just one cog inside the gearbox. We were asked to provide the software which enabled the electorate to log in, allow the creation of the ballot paper, the casting of the votes and the mechanism to take from the electorate the details of the vote.

All these components needed to come together and work to create a successful e-Voting experience for the electorate. These other areas were the responsibility of the company which contracted us to provide the server software, Opt2Vote.

Opt2Vote was the prime contractor for the ODPM for providing the pilots for 3 local authorities in the UK. These were:

4. Server Software to facilitate e-Voting

4.1 Security

It is said that if you invest in real estate, your top three priorities are ‘location, location and location’. Equally, it may be said of server-based software, the first three priorities are ‘security, security and security’.

However, as we all know, this does not always reflect practice. And so it was that, with the pressure of the pilots, that security was relegated to a position much further down the list. Many participants in the pilots seemed to believe that standard HTTPS encryption and a firewall is all that is required to keep an electorate ballot secure. Unfortunately, this misapprehension does not take account of how good hackers are at hijacking web sites, and by-passing firewalls! (Something many banks have recently discovered.)

In addition to the Web Servers, there are one or more databases which hold the voter and candidate details. These should also be protected by a firewall, housed on separate servers, with their identity hidden from all. Some of the more sensitive information held on these databases, such as ballots and Voter Identification data should additionally be encrypted to protect both the integrity of the ballot and the privacy rights of the voter. It is only in this way that a ballot can be cast by a voter with the confidence that even if a security breach were to occur on the servers, they and their vote would be kept anonymous.

The security issue goes further, of course. Whilst using the Internet or i-DTV voting channels there may also be the requirement to hold some 'persistent' information about a voter’s session whilst they are casting their ballot. Although this information could be held in cookies by the voter’s browser, this does open the possibility of a voter deciding not to complete their ballot, and to close the browser, with the possibility of leaving the cookie open to abuse. To overcome this potential security threat we implemented our own server side session handling, which used a remote database to house the encrypted session details. These were stored in the database in their own tables, housing only encrypted data, with no public means of bringing the voter and the session together if a security breach of the database should take place.

If any configuration files are required (and we used a few XML ones for database connection, database field mapping and the application server to API connection), then these should be encrypted on the server. This is the most effective way to ensure that any security breach could not open up the databases to hacker attack. These files are decrypted by the Application Server as required and held in memory only whilst being read to extract information.

4.2 Database

The selection of database is of less importance than other decisions, and will usually be decided by a database administrator’s knowledge of one database server over another. However, it should not be forgotten that the database is the repository for all information about the ballot. This includes:

Accordingly, when choosing which database server to use it is important to keep at least the following in mind:

The database choice should also be made independently of the application, thereby allowing the application to be used with any database server selected.

4.3 User Interface

With any election there will be a requirement for more than one User Interface (UI). This is because it is not only the elector that needs a suitable UI to house the login, ballot paper and vote casting. The Election supremo or Returning Officer will also need to count the votes.

Therefore, when designing the system it was very important for us to ensure that the application was able to pass the correct information to the correct place at the correct time. This we did by utilizing XML.

During the pilots we were involved in, the electorate User Interface was created using Active Server Pages written in Visual Basic (VB), whilst the User Interface for the Count Process was written as a desktop application using C++ and Visual Basic. The choice of UI depended on where the user would access the data – either via a web browser or from a desktop application. By making sure that the server application pass back and reads in XML, you are making sure that any UI is able to be added to the application, with relative ease.

In the pilots we had to pass and take information from a number of different User Interfaces. These were:

This meant that the application had to pass to each interface a message which was universally formatted and recognised. The use of XML here meant that this task was made considerably easier. It enabled a structured message to be passed to the UI and have it process the data, format it and display the required details quickly and in a user friendly manner. It also meant that all of the Interfaces were able to be dynamic and display only the information that was relevant to the particular user who was logged in. It also enabled the transformation of the XML output into WML for use on the i-DTV platform, HTML for use in the PC Web Browser.

4.4 XML

XML is the glue which enabled all of the above to take place. It was the language in which all messages were passed to and from the UI and the Server Application. It was also the language to which all the database inputs and outputs were mapped to, allowing for easy standard output.

XML also allowed the application to be written totally independently of any back-end databases. We used field-to-XML mappings and XML configuration files to house all the report SQL and login information. XML also acted as the messaging conduit between the Application Server and separate Application Programming Interface (API) application.

The use of XML also (and maybe most importantly) allowed the application to be used across many different ballot types without it having to be re-written to understand different ballot rules and database schemas. This meant that one application suite could be continually used without the requirement for rewriting each time. In the process of passing XML messages, the application can hook to any number of User Interfaces, desktop clients and databases.

I should acknowledge that this is also possible without using XML. However, the job is made a lot more difficult and may open security risks. By adding in the ability for the application to read and write Election Mark-up Language (EML) syntax, we provided it with a secure footing to carry out its prime task, that of managing the election data safely and securely.

Although I believe that using XML is an absolute requirement for any e-Voting application, I would caution against creating an application that is totally incumbent on one DTD or Schema. One of the powers of XML (apart from having structure) is the ability to transform it by using XSL-T from one DTD or Schema to another. If you create an application which is 'hard coded’ to a particular structure then when that structure changes, you will also have to change your application.

This was one lesson that we learnt during the creation of the initial application. By making sure that it was totally conforming to the XML specification and by placing into it a transformation engine, we were able to use both the Election Mark-up Language EML structure and also DTD's and Schema's passed to us from outside organisations. As can be seen, XML made compatibility achievable. All of the reports can be produced in EML, and this will still be possible when the EML specification is modified in the future, without having to make any changes to the base application. In addition to this, if an organisation wishes to use the application but have the reports output to a different format - say a word processing document or different DTD – then this is also possible.

Creating an application with this methodology was not as hard as first imagined and definitely had its benefits. By using XML mappings taken from our other applications, we have now created an application which can be used for a number of different election models, including Government / Presidential, Local Government Organisation, corporate and user feed back samples. This is without forcing anybody to be knowledgeable in a specific XMLDTD or Schema, which can also add cost.

Only by using standards-based XML is this made possible. It opens the doors for the application to be

In addition to these benefits, if used correctly, then XML will also extend the life of the application greatly - by giving the power of transformations to other DTD's and schemas. There is the further benefit of enabling the application to keep up with the latest changes to any one specification, without any additional development.

4.5 Programming Language

This is where I was most surprised during the pilots. I discovered that some organisations working on different pilots were using scripting languages to access databases and create the back end applications. To me this has never made sense. Technologies such as Active Server Pages, ASP and other web based scripting languages are brilliant for User Interfaces. However they are inherently insecure and can be slow when they are used to create the business logic of an application.

The selection of the best development environment therefore needs to take account of a number of factors.

4.5.1 Security

If you are producing an application which must provide top security then this needs great care. Using a development language which leaves open text on the server, showing every hacker where the databases are, how to log into them and what queries need to be passed to get hold of the information, strikes me as a little odd. For this reason we used a compiled language for the business logic part of the application (C++). This then left the User Interfaces to be created within an environment which best suits the intended use. This is true, whether this is for a web site where ASP with VB is used to create the Web Sites (as was the case with of the 3 pilots), or another language to create a standalone User Interface for administering the election data.

In addition to this, all configuration files which are held and read by the application were encrypted to stop any external security breaches being able to read and use them, thereby gaining access to election data.

In the light of the pilots we subsequently redesigned the software into two parts to aid security issues. On the server, which was running as a CGI application, we had an 'Application Server'. This application had direct contact with the databases. It provides the authentication messages, passes back the XML which makes up the ballot papers or count data, and populates the data into the databases.

The users have no method of talking directly to this application. They interact with the 'Application Programming Interface' API. This is again a CGI application which is able to sit on a separate server to the Application Server. The users interact with the API, which takes their inputs and reformats them before encrypting and passing on to the Application Server, across a Secure HTTPS connection. This additional application and encryption helps to maintain the application and data integrity by adding an extra 2 layers. This makes it harder for any would-be attacker to circumnavigate.

One very obvious point to add here is that if a hacker is determined, he or she will keep attacking. One of the best defences against this is good housekeeping of passwords, firewalls and Web Servers.

4.5.2 Platform

Which platform your server application will run on is, of course, very important. If you are running purely as a Microsoft Windows Web Service then it makes sense to use C# or managed C++ within the .NET environment, calling all the Microsoft Windows and .NET APIs that are required.

If you are creating a CGI application, which again is only to be used on one platform, then again you can use a language, together with API calls which are specific to that platform.

For speed of development and use, the software that we developed for the 2003 election pilots was written in C++ using the C++Builder IDE from Borland. As the software was only ever going to be running on a Microsoft Windows 2000 server with Internet Information Server version 5, we were able to use the Microsoft Windows API calls as required and plug in other Microsoft Windows-centric components as necessary. By looking specifically at this aspect of the application development and given the time constraints we had, this combination of language and tool gave us an application that was delivered on time. It was also one which ran quickly without any problems and allowed us to utilise platform-specific API's.

This platform-specific development is fine. However it does very much reduce the ability of the software to be used on other platforms without additional reworking. This takes away one of the advantages of using other languages within the application such as XML, which is truly cross platform.

We have learnt some lessons since the 2003 pilots in our discussions with other potential users of e-Voting software. This, importantly, includes the ability for the software to be easily ported to other platforms such as Apple Macs or Linux, so that the software is easier to use and cost of ownership is reduced. For this reason, at the beginning of June this year we created a new version of the software within the .NET environment and used C# and the compiler from the Mono project to make it truly cross platform. This has enabled us to re-use .NET API's and gain cross platform independence for our users.

The code for our e-Voting applications will be made available on an Open Source basis using the dual licenses model, at the end of November. By doing this, we hope that a larger development community will help to enable a more secure, fast and robust voting application using XML and C# with Mono, thereby enabling more governments and organisations the confidence to use e-Voting more widely.

5. Conclusion

The e-Voting pilots in the UK proved that the modern voter needs to be able to use modern technology to record his or her vote. The new age voter is technologically empowered, and if voting turnout is to be maximised, then the technology needs to be available, cost-effective and secure. This was well demonstrated in one of the pilot areas. The Vale Royal turnout increased by 13% on the previous (comparable) election with 23.8% of the total ballots cast being done so with an e-Voting mechanism. In Shrewsbury, turnout was up by 11%, where 19% of voters cast their ballot with an e-Voting mechanism. These figures varied from area to area over all the pilots, with 12% of the total electorate opting to use an e-Voting method.

When implementing an e-Voting application, developers need to concentrate on what they are providing and look at this with the specific issues in mind, and in particular:

The running and management of the election should be left to others, so that the IT solution is developed to follow best practice with maximum security. By doing this an e-Election can be run effectively and securely, giving users the ability to cast a ballot on-line with no risk or perceived risk of fraudulent access. Using open source software, it should also be volunteered for stringent, independent audit to establish high confidence levels for the organizer, candidates and the voter, whilst not degrading security in any way.