prefill voter credentials thru email url

[KiaraGrouwstra]

as of present, when users receive their credentials by mail, they have to manually fill out the login form. this PR passes the user's credentials thru the email URL such as to have them automatically fill out in the login form.

a potential con here is that, with credentials going thru query parameters, this may leave the credentials exposed to an attacker with access to the voter's browser history.

as such, this patch makes for a potential trade-off between voter convenience vs security. however, in real-life settings it would take attackers with access to a sufficient number of voters' browser histories to be able to influence election results, likely making this trade-off worthwhile, particularly for elections only open for a shorter period of time (such as is the case during live elections).

[benadida]

Hi @KiaraGrouwstra thanks for this! I'm torn on this PR because one of the security aspects of Helios is that ideally the server doesn't know who you are until the end, so it can't maliciously serve you a different booth. I'm torn because that threat might just be a mismatch for typical uses of Helios, in which case the usability improvement here is clear.

I'll think about this a bit more!

[KiaraGrouwstra]

i'll admit that is an argument i had not anticipated.

i think it's a somewhat interesting one as well, as it would imply that the workings of the booth component are more transparent to users than helios as a whole, while in practice inducing transparency on either end would likely involve using a publicly visible deployment pipeline. even then tho, i imagine it would be hard to guarantee no code was tampered with after deployment.

this might be me, but i'm not sure the question of server trustworthiness is an easy one to solve.

[benadida]

this might be me, but i'm not sure the question of server trustworthiness is an easy one to solve.

Yeah, this is an excellent point. Theoretically, if you audit your vote a few times before casting, you can control for a malicious server, assuming you audit it through your own installation of Helios.

That's a big big "theoretically" of course.

So we're left with defense in depth. And that's why I struggle with this one. I'm not sure the argument I've made is sufficiently practical to override a usability concern... and yet I know it makes some people feel safer.

[KiaraGrouwstra]

that's fine :), thanks for explaining.

[benadida]

Oh I really did mean that I would think about it, I'm not saying no :) Just want to spend a little bit more time thinking through the use case. If you're game to keep this open a few days, I'd love to consider it for a few more days.

[glondu]

In Belenios, there is the possibility to pass the "credential" (which does not play the same role as the "credential" Kiara is talking about) in the URL, in the hash part. This way, the server does not learn the credential nor does it know who is downloading the booth. See the related discussion.

Maybe something similar could be done in Helios.

[benadida]

In Belenios, there is the possibility to pass the "credential" (which does not play the same role as the "credential" Kiara is talking about) in the URL, in the hash part.

Ah yes, a neat trick I've used a number of times before. It does seem like this would require a little bit more evil from the server to make use of, I like it.

@KiaraGrouwstra if you're interested in tweaking your PR in this way, go for it. If not, I'll see if I can make this improvement soon.

[KiaraGrouwstra]

@benadida thanks, i've adjusted it as requested.

[KiaraGrouwstra]

i would consider moving the js to a more general place, such as to facilitate setting other info by url as well. this seems useful for elections/new for example, a form that i tend to fill out similarly most of the time. thoughts on a good place for this would be quite welcome.

[KiaraGrouwstra]

i tried moving the js to base.html now. not sure that's the preferred place, but this does address both.