Wandering Thoughts archives

The secure web voting problem

Somewhat recently, part of the anime blogging community had a certain amount of commotion and drama that culminated in this:

We are in the process of procuring a more secure voting system. We're not quite sure how long it will take as of yet. Somewhere between a week and the end of the month. [...]

(Here 'secure' means 'stands up to ballot stuffing'.)

When I read this, I think that my reaction could best be summarized as 'oh really? this should be interesting'. You see, there is a fundamental rule of web voting: the only way to have a secure voting system is to use registration, at which point the security of your voting system is directly related to the security of registration. There is fundamentally no such thing as a secure voting system without registration, not unless you redefine what you mean by 'secure'.

To see why, let's do a thought exercise. To start with, we'll assume that you have come up with a surefire way to conclusively identify a particular device (and can thus prevent it from voting twice). This is not very realistic in a world with multiple browsers, incognito mode in major browsers, open wireless access points, proxies, anonymizing VPN services, and so on, but this is an extreme thought exercise; I'll give you that you've come up with the marketer's holy grail in the form of some super hyper cookie or the like.

Now consider someone who has a laptop that they use at home, a tablet they use at the coffee shop, and a smartphone with a data plan. You can prevent each individual device from voting more than once, but you can't link these separate devices to the same user and thus prevent the user from voting three times, once with each device. If there is any information that would let you deduce this link on a device (and often there won't be), that information is almost invariably carefully guarded and not available to you, especially not to a web page. And this is deliberate; neither the user nor the device vendor are at all interested in letting you do this linkage, and often they violently object to attempts to do so as intrusions on privacy.

(Okay, if you have totally free access to all the devices you may be able to link them in typical scenarios; for example, if devices have Facebook or Twitter credentials for the same accounts you can usually assume that they all belong to the same person. But this is extremely intrusive access that you're not likely to get legitimately or keep for very long once people notice. Plus it's not something you can do through just a web page.)

Without the ability to link multiple devices to a single user, what you have is not 'one person one vote' but at best 'one device one vote'; even with your super hyper cookies, everyone actually gets as many votes as they have different devices (they need different ways of getting the devices on the net, but that's generally not difficult). To get around this you need some way to actually identify the person; in other words, you need some form of registration. At that point the problem of secure voting becomes the problem of preventing people from registering multiple times.

(If I was in the situation of the people with this problem, I would outsource my registration to, say, Twitter (by requiring a Twitter account in order to vote) and then keep records of the voting so that I could later go annul the votes of bogus Twitter accounts.)

(Note that what I quoted did not claim that the people here were going to procure a secure voting system as such, merely that they were going to get one that was more secure than their old system. I expect that they succeeded in that more modest goal.)

Sidebar: on registration systems

The easiest secure registration system to enact is one that piggybacks on top of an existing online community with an established set of identities. Of course this pretty much restricts your voting pool to the people who are already active in the community, which may or may not be desirable. (It also tends to require manual work to run.)

Registration systems are sometimes attacked in the real world as well. Famously, Hugo votes can effectively be bought and I believe that there have been cases where this has been done. As you might expect, drama ensued.

The well behaved Unix program and job control signals

The TTY demystified (which I've commented on before) has some things to say about the SIGTT* job control signals. In the process it says something about how they are and should be handled that I think is dangerously misleading.

Specifically, contrary to what The TTY demystified says, you shouldn't assume that the shell saves and restores TTY modes for you when your program is suspended and restored. A well behaved Unix program that changes the TTY modes will remember and restore the original modes when it gets SIGTTIN or SIGTTOU, and then re-set them to what it needs when it gets SIGCONT. Note that a well behaved program may need to do much more than just save and restore TTY modes; one of the reasons that programs get sent the SIGTT* signals (instead of just being abruptly suspended) is so that they can do things like reset the terminal state away from whatever peculiar colours and other settings they've placed it into.

(This is where the alternate screen plague kicks in.)

These days I think that basically all surviving shells (at least ones with job control) do save and restore TTY modes for you, because sadly this is basic self defense on part of the shell. However, they generally don't reset the terminal state (partly because they often have no idea what state you've put it into).

(This has implications for how your program should handle SIGTTIN, but that'll take another entry.)

The article also asks (after discussing ^S/^Q flow control):

I don't know why the designers of UNIX had to go all the way to invent SIGTTOU and SIGTTIN instead of relying on blocking I/O, but my best guess is that the TTY driver, being in charge of job control, was designed to monitor and manipulate whole jobs; never the individual processes within them.

The straightforward answer is that the SIGTT* signals are designed to give your program a chance to react to being suspended. That's why you can catch them at all, unlike SIGSTOP. If the TTY driver simply blocked your process from doing further TTY IO (or just sent you a SIGSTOP), your program couldn't clean up any special state it had set and doing this would be entirely on the shoulders of the shell (which cannot do it as well as your program can in many situations).

Sidebar: why the shell has trouble restoring the terminal state

At one level and in theory, restoring the terminal state is simple; the shell can just send the terminfo state reset sequence. However there are two problems with this. The first is the general problem of interrupting an operation in the middle; if the program was abruptly suspended partway through sending the terminal an escape sequence, the terminal may be in a mode where it will interpret part of your reset sequence as part of the incomplete escape sequence.

The second problem is that sometimes, part of 'resetting' things is program dependent. The big example is where you should (re)position the cursor. The cursor may have been put in an arbitrary and potentially strange position and thus needs to be repositioned somewhere useful, or it might be in a perfectly sensible location already and you should leave it alone. The first case is typical of a full screen program like vi (where the cursor will usually be repositioned to the bottom of the screen); the second case is typical of a program that just uses readline. The shell generally can't know which program is which.