Yes, as soon as the election is opened, it is possible to choose the start and end date of the election. It is possible to modify these dates at any time until the counting of the votes.

Yes, temporarily. It is possible to postpone the display of the results for up to one week. This feature is available right after the count.

The data is saved and the elections will resume normally after the server has been restarted. Stoppages are usually due to external power cuts and we inform you about these outages as soon as possible on the list belenios-publicserver@inria.fr

Yes, you just have to indicate the number of votes of each voter (his "weight") in the electoral list, in the form mail,login,weight or mail,,weight.

No, this functionality does not exist in Belenios. However, if delegations are known in advance, then the election organizer can assign several votes to the voters who have received the delegations, and delete from the electoral list the voters who have given their votes. A voter who received delegations will however not be able to vote differently for each of his votes, he can only make one choice (that will be propagated to each of his votes).

Yes, it is possible to rank or score the candidates. The supported counting methods are Condorcet, Single Transferable Vote (STV) and majority judgment. Currently, this is still an experimental mode. You may find more information here.

No, Belenios does not offer any hotline. We invite you to look for an answer on this FAQ or on the discussion list belenios-discuss where you can post your question (belenios-discuss@inria.fr).

Yes. The maximum number of voters for each election is listed on the Belenios server home page. It was 2500 at the last update of this FAQ.

We welcome feedback on features that would be appreciated by users. The evolutions of Belenios are partially driven thanks to this feedback. You can submit your feedback and requests for additional features by posting an issue on our github repository or by posting a comment on the discussion list belenios-discuss (email: belenios-discuss@inria.fr).

The platform comes "as is" and we do not offer any hotline. However, a commercial service is under construction. You may contact its members to ask for more help.

Unfortunately, it is impossible to add a voter or to modify the email addresses once the election has started. This is a protection to avoid that the organizer modifies the electoral list. The only solution is to start the election again.

In automatic mode, you have been invited to download the voting codes during the preparation of the election. Then you just have to resend the desired voting codes yourself. The server cannot send back the voting codes itself because it deletes them once the election is validated, for security reasons. As for the mail with password, by default, it is sent to the voter when she confirms her vote. A new password will be sent for each new vote.

Yes! With Belenios, you can vote as many times as you want, until the election is closed. Only the last ballot is kept and you can check its presence in the public ballot box thanks to your tracking number.
The possibility to vote several times offers some security guarantees, as explained here.

We use cookies to store your language preference (if you chose a different language than the default one) and for session management. The purpose of the latter is to link the different requests of the voter during the voting phase. Once you have voted, all identifying information is discarded. In particular, we do not track voters or use cookies for statistical or marketing purposes.

Unfortunately, no one can recover the key for him/her! This is the basis of Belenios security: even the server administrators do not have access to the decryption keys of the decryption authorities. To prevent this kind of problem, we recommend two solutions: 1. make a mock election with your decryption authorities. The same keys can be used from one election to another by importing the keys. 2. Set up a threshold of authorities (for example 2 out of 3). Setting up the decryption keys takes a bit longer (more steps are needed) but the election can still be tallied even when some authorities are missing (depending on the chosen threshold).

This is (much) better for security. Without a decryption authority, the server has the technical ability to know who voted what. With a decryption authority (or several), to decrypt the individual ballots of voters, you have to corrupt that authority(ies) AND the server. As a voter you can check how many authorities have been chosen by looking at the grey box at the bottom of the election home page.

It depends on what you call "by hand". The result is accompanied by a mathematical proof that shows that the result matches the ballots in the the ballot box. This proof is verifiable by all... with the help of a software. The instructions for verifying the election result are available here.
In the context of a standard election, one does not have access to the individual votes because the ballots are never decrypted one by one. We use a property of the encryption system which allows to aggregate all the votes into one and decrypt only the result. This guarantees the secrecy of the votes, because ballots are not decrypted individually. Cryptographic evidence ensures that the result corresponds to the content of the encrypted ballots. In complex election contexts (Condorcet method, majority judgment or STV), we actually decrypt the ballots individually once they have been shuffled and re-randomized, but this implies a more complex procedure for the authorities in order to ensure that the link between ballots and voters is broken.

The possibility to vote again is a (moderate) protection against coercion: in case you feel obliged to vote together with your colleagues, your family, etc. then you may not be able to vote "freely". Thanks to the possibility to revote, that's not a real issue since you may vote again later on, when there is no pressure.
It is sometimes also appreciated as a feature: you may explain to someone how to vote (to your colleague or to your grand parents) and then they may vote alone, once you'll have left the room.
Note however that it does not form a protection against stronger coercers: you may be asked to provide your credentials and passwords (and maybe earn some money in exchange for this material) and Belenios does not protect against this kind of coercion.

We support OpenID Connect authentication and we have added Google as a possible service. Concerning Renater, there are technical issues related to interfacing, but also the question of whether Renater wants to host an instance of Belenios.

In our opinion, none of the existing voting schemes achieve the same level of security guarantees than traditional on-site paper voting (as it is organized in France for example). Indeed, high stake elections would need schemes that simultaneously achieve vote secrecy, coercion-resistance, and verifiability, without having to place the trust in the organizing authorities nor the company running the election. Furthermore, a voting scheme should also protect against the corruption of the voters devices: even if a voter device is compromised (by a malware for example), it should still not be possible to change the vote chosen by the voter nor even to leak her vote.
Belenios fails to achieve coercion resistance: it is easy to sell the credentials and the login and passwords (unless a CAS server is used). A more sophisticated coercion attack (even when a CAS server is used) consists in requesting voters to provide the randomness used to encrypt their ballot. Our own implementation of the Belenios voting booth of course does not include this feature (that is, leaking the random numbers) but a coercer could easily adapt our tool and provides a special voting service to voters under coercion. Another important limitation of Belenios is that it is not resistant against the corruption of the voter's device. If corrupted, your computer may leak for who you voted to a third party or could even vote for a different candidate.
Some systems overcome these limitations, but often at the cost of other compromises in security or usability.
So we do not have a definitive answer on when to use Belenios. Our main advice is to conduct a security analysis in the same way for Belenios and the other possible systems, in particular the one previously in use (if any).

First of all, if you use a survey tool, the provider (for example Google or LimeSurvey) has the technical means to :

• change the result (manipulate each vote)
• know who voted what: sure, the vote is anonymous but the provider knows with which IP address you connect, which browser, which operating system. If in addition you have an account with with this provider, it should not be very hard for them to know who you are. But the IP address is usually already largely identifying.

Now, what about the election organizer?

• In most solutions, he sees the "anonymous" results coming in all along the voting process, which has two flaws:
  • the organizer has access to the partial results which may influence his own vote if he is a voter. He may also attempt to adapt his "campaign" if he is campaigning for someone.
  • worse, if you proudly declare to the organizer "it's okay, I just voted, it works very well" then well, by observation of the partial result before and after your vote... he knows your vote. And similarly for the last voter who everyone knows had a hard time voting and voted last.
• You're going to have to trust the organizer when he announces the results. What if he announces a false result? Or you have to create a dedicated account for the election, that everyone (or some assessors) can consult, with the drawbacks mentioned above.
• The organizer has sent the links to voters. He can therefore vote in the place of everyone (*). Convenient, right?

(*) This last point depends strongly on the solution used and has to be tested. But there are inevitably two logics that are difficult to resolve simultaneously: keep a poll anonymous and on the contrary, authenticate the voters and make sure that only one vote is taken into account for each voter. In any case, if the organizer has sent the links, he will be able to at least vote in place of those who abstain.

What about outside "attackers"? If the poll is anonymous, it is often possible for a voter to:

• discreetly vote a 2nd or 3rd time with the same link, hoping that some people will abstain.
• vote multiple times (intentionally or by mistake), which will lead to having too many votes and therefore the cancellation of the election.

Here we see again the difficulty of maintaining both anonymity and authentication.

Please note: if you use Belenios in the simplest mode and therefore without decryption authority, then our server also has the technical ability to know who voted what. If your election exceeds the sensitivity level of the evening pizza choice, we advise you to appoint an external decryption authority (or several) and test it thoroughly beforehand (otherwise you may not be able to tally the election).

Our server is running in a virtual machine under the latest Debian stable, has 4 GB RAM, 16 GB disk space and 2 CPUs. For a production deployment, we recommend the use of a reverse-proxy (we use nginx) to do HTTPS. You can find more details here.

You have to make sure that the service is operational in HTTPS (and not in HTTP). After that, there is nothing specific to Belenios and the server must be well maintained: system updates, firewall, SSH authentication by key, etc.

The easiest way is to re-deploy to a new location on your system from scratch, keeping the spool directory (and logs if you are interested). The possible subtleties are documented in RELEASE_NOTES.md. It is also possible to update Belenios in place (it's more convenient with a git clone), but we still recommend to run the opam-bootstrap.sh script first, when it has changed, with BELENIOS_SYSROOT pointing to a new location.

If you encounter an issue while installing Belenios, you can try the Troubleshooting section of INSTALL.md ou have a look at the pages of discussion list.