I'll also shamelessly plug my thesis which, among other things, describes an interesting ballot secrecy vulnerability in one online voting system that allows a passive network observer to determine who someone voted for:
Switzerland is transitioning to online voting, and having a digital ID for authentication is helpful for that. I hope it is used as part of the voting process.
My understanding is that the current approach for e-voting in Switzerland works with voters being sent a PIN in the mail [1]. Then the voter uses the PIN to log into the system and vote. Unfortunately that means that insecurely discarded letters from non-voters could be used to cast votes on behalf of these voters.
Some jurisdictions try to use a second factor to prevent these attacks. In Ontario, for example, many municipalities use a combination of the voter's PIN in the mail + the voter's date of birth. But a date of birth isn't really secret. Lots of people know your date of birth (especially insiders at organizations that collect this data), and it may appear in data breaches or even publicly on social media. If you're curious about this, I recently co-authored a paper which is all about security problems relating to online voting credentials in Ontario -- It's relevant to the Swiss case as well: https://link.springer.com/chapter/10.1007/978-3-032-05036-6_...
Long story short, using a digital ID to authenticate to the system (like Estonia does) goes a long way to mitigate this authentication problem. However, there are still plenty of other potential risks with online voting that are unrelated to authentication (how do you prevent ballot stuffing, clientside-vote-altering malware, falsified counts, etc). And there may be privacy risks with digital ID depending on the practical implementation.
Different systems have different approaches. If you're a voter, you can use your web browser's developer tools to see what's going on, and part of my research is essentially doing that with systems like this.
With one Ontario online voting system used by dozens of municipalities, your choice is sent via a form submission (POST) to the server. The POST contains your choice in its body (in plain text) and your browser also sends a cookie/authorization header which contains a token which was generated by the server and given to the client when the client logged in with the PIN/birthday. In that case, the online voting system could identify you and who you voted for at the time the request is made (they receive both the authorization token linked to your identity and the vote in the same request). The vendors then takes procedural steps to then separate you from your vote, and the elections authority running the election receives a report of the totals (but not who each voter voted for) from the vendor.
However, other systems are a bit more complicated. They'll serve you client-side javascript which does cryptography with your PIN / voting choice such that you can prove to the server you are authorized and made a valid vote, but the server can't link your vote to your identity. Then there's a lot of stuff that happens to mix votes together before they are unsealed and counted. I'm not a cryptographer, so I can't give you the best explanation off the dome.
The Swiss system does try to do something that looks like the latter approach, and they hire cryptographers and security professionals (and have public testing) to ensure the system's design meets requirements for ballot secrecy and if the implementation is correct.
There's a video about how ballot secrecy is ensured with the Swiss system which you can watch at this link:
So bascially you log in to the login server, which passes a token to the vote counting server that the vote is valid but with no identifying information? And there is some way to verify that these two entities do not cooperate?
How do you override a previously cast vote in that system?
(Overriding a vote is a popular solution to vote buying/intimidating which is otherwise a problem with mail-in votes and e-votes.)
> So bascially you log in to the login server, which passes a token to the vote counting server that the vote is valid but with no identifying information? And there is some way to verify that these two entities do not cooperate?
With the Ontario system I described (first example), no. You can't ensure this. In fact, the server that receives your authentication credentials is the same as the server that receives your vote.
How things work:
1. You send a POST with {"DOB":"1995-01-01", "PIN":"12345678"} to server.
2. Server responds with a session cookie. That cookie is included with all subsequent requests in order for the server to know you are authenticated. This is a typical authentication scheme for web applications.
3. Eventually you make a selection and cast your vote. This will send your vote, and the cookie, to the server.
4. The server verifies the cookie is valid and records your vote.
It is definitely possible for the server to connect the identification information you provided in your initial login with the cookie, if it chooses to log that data. There's no way for the client to know if it's happening or not.
It's also a proprietary system, and because it's owned and operated by the online voting vendor (and not a government body) it's exempt from freedom of information legislation, so you wouldn't be able to see any information about the system's design even if you really wanted to. We do know steps 1-4 exist though, because we can infer all of it from the browser's development tools when interacting with the website.
With this type of system, there is also no meaningful way for a municipality to verify the count is correct, beyond the testimony of the vendor. The system is a black box, where votes go in and a result comes out. The vendor reports the result, and the municipality then declares candidates elected.
To be clear: Not a hypothetical. This is a real system! Used by 49 municipalities in 2022!
> How do you override a previously cast vote in that system? (Overriding a vote is a popular solution to vote buying/intimidating which is otherwise a problem with mail-in votes and e-votes.)
You don't! To the best of my knowledge, no vendor/municipality offers this feature in Ontario.
There have been plenty of suggested online voting schemes over the past several decades, yet the prevailing theme is that the ones that actually see practical use don't even try to solve the problem.
The reason why we have public elections is to ensure a peaceful transfer of power. I believe each and every scholar of political science would agree with this statement.
What's important is that there must be no reason to sow distrust into the process. No party should be able to claim their votes weren't properly counted, or that the process is somehow suspicious. The voting process could be mathematically perfect, but if people doesn't trust that votes can't be bought and counters can't be bribed then it's all for nothing.
That's why we need transparency. Not because of some higher theoretical lofty ideas, but because the basis for peaceful transfer of power between parties mutually suspicious of each other is not there.
If trust gets broken then society gets broken. Elections will continue, but in a generation or two they will cease to be able to fulfill their intended goals, and that's when we see the outcome. Not next year. That's what scares me.
So the short answer is that you're shit out of luck and have to trust the voting system, the server, the javascript, and the vendors that produce them? Presumably all of this source code is available somewhere for auditing?
There's a nugget of truth there, but I will say that the Swiss government has taken a very thorough/careful approach to implementing online voting. There are legislated cybersecurity standards for e-voting, individual and universal verifiability, pilot programs, meaningful observation, everything is open source, funding is set aside to incentivize researchers to find vulnerabilities [1].
When critical vulnerabilities were found with the previous implementation done by a private vendor, they dropped their vendor and restarted from scratch, doing everything in-house [2,3].
Not all jurisdictions are so careful. Over 200 municipalities in Ontario do voting online, despite no legislated standards (though a voluntary standard was recently developed). The voting systems are offered by private vendors, no organization is responsible for certifying these systems, and many systems do not offer any cryptographic verification of the results. It's quite interesting [4].
Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.
First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)
It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.
Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)
Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).
Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.
microG still uses Google services for accounts, push messaging and many other features.
microG itself has functionality requiring downloading and running Google executables as part of itself. It doesn't change the fact that apps depending on Google Play are using Google Play libraries often making connections on their own without Play services.
GrapheneOS sandboxed Google Play compatibility layer provides far broader app compatibility while giving strictly less access to Google Play code. Sandboxed Google Play runs as a set of regular apps with no special access or privileges. It's the same app sandbox the apps using it run in with the Google Play SDK and libraries built into them. GrapheneOS improves the app sandbox and permission model substantially, which applies to sandboxed Google Play in the same way.
GrapheneOS implements functionality such as location services via the OS and reroutes apps using Google Play APIs to the OS APIs. We have our own network location and geocoding implementations in the OS. We're building our own fully local text-to-speech and speech-to-text services right now.
There's a great and very detailed report written after the 2018 municipal elections that outlines some security issues with online voting in practice:
https://whisperlab.org/ontario-online.pdf
I'll also shamelessly plug my thesis which, among other things, describes an interesting ballot secrecy vulnerability in one online voting system that allows a passive network observer to determine who someone voted for:
https://uwo.scholaris.ca/server/api/core/bitstreams/4e74d806...