How is this system going to be managed in the long term?

[Xemorr]

Hi, I see that you are updating who has access to creating votes per organisation completely manually into YAML files. Is the idea that you need to be contacted to handover permission? It is not entirely clear what the long-term strategy of this is if the current maintainers become disinterested.

[mxbi]

Hi! As you may know, this repo (along with the rest of the GitHub org) tracks the production code of https://camvote.org, so these providers files are for that specific instance, for the University of Cambridge. The ability to update this repo becomes a bit moot if there is no one to maintain the production server!

As you've identified, this is not the most efficient way of managing providers - the reason is that we've backported this new infrastructure onto bob/bob-gui, which we inherited from CUSU (now Cambridge SU) when they abandoned the voting software. This lets us run the software independently without having to change too much of the original codebase.

It is not entirely clear what the long-term strategy of this is if the current maintainers become disinterested.

• At the moment, this repo is probably not the bottleneck of maintenance - running a secure election system needs a small team of sysadmins that are allowed to change code to fix bugs when they appear. We are appointed by the JCRs/MCRs that make up the system (collectively the Cambridge Online Voting Consortium); the idea is that new admins can be appointed every year or whenever necessary.
• If camvote.org becomes abandoned entirely (or someone wishes to run an instance for outside the University of Cambridge), then people are more than encouraged to spin up their own instances; as we did ourselves based on https://github.com/cusu/bob-gui.
• Long-term, we want to do a full re-write of the voting system to bring it up to modern dev standards while retaining security. Part of this will be allowing some sort of "self-service" management of organisations, which means that the sysadmin workload is further reduced. If you could be interested in being involved, let me know!

Some potentially interesting links:
https://camvote.org/about (if you have a Raven account)
https://www.varsity.co.uk/news/24971

Does that answer your question?

[Xemorr]

yeah thanks for answering :)

Sorry if this isn't the best place to discuss it (and I have a feeling that this is simply a necessary problem if you're keeping who voted anonymous), if an election has <100% turnout then an admin could invent new tokens and assign who they voted for in order to rig a vote while keeping the property of all the real users who voted being able to compare their tokens against the list and see that they did indeed vote. Obviously, this would require either a security breach or sysadmins to be corrupt which I am sure you are not, but wondering whether you have thought of this yourself?

[mxbi]

That's an important consideration!

For this reason, there are two things published:

• A list of voting tokens and associated votes
• A list of who actually voted (this list is visible to those on the election roll).

This means that in order to add new voting tokens, one would also have to add people to the "voted" list (so that the length of the lists match). This means that a bad actor forging votes raises the possibility that someone notices a vote in their name when they did not in fact cast one. In practice, most users will of course not check this list, but it is important that any vote tampering would be publicly visible; so users are encouraged to audit elections.

A more sophisticated attacker could get around this by issuing the same voting token multiple times to multiple people (who voted identically), releasing a "spare" voting token which they can cast how they wish. This is something we'd like to prevent, but might require a complex cryptographic solution (e.g. publishing voting timestamps is unsuitable could reveal how individuals voted). The goal is to add as many defences as possible to make any tampering traceable and discourage any potential attackers.

[Xemorr]

Ahhh okay, I didn't realise the list of who actually voted was published as well, that explains the note about this system not being great for say LGBT officer by-elections. Thanks so much for the detailed explanation :)