Wikipedia talk:Secret ballot process
This is a very interesting piece of reading, thank you for taking the time to write it. I'm interested in discussing its precepts, and maybe finding things that we can incorporate into SecurePoll.
My overriding impression is that this proposal has a huge amount to do with protecting a vote from the server administrators. I can't even begin to describe how much of a headache that will cause. Root access is not described as "complete access" for a laugh: sysadmins can do literally anything, to any page, on any click, as any user. You describe how users would create a secret key by hashing their username and a password, which is all well and good: only the hash will be stored in the database, no apparent means of access. But in order to register their vote, voters will have to, at some point, submit their username, user id and some form of authentication to the servers in one transaction. It is well within the ability of an unscrupulous sysadmin to capture those data and then have access to that user's credentials. It is well within the power of a sysadmin to modify the software such that each user who views the ballot list sees their own entry as correct, and other votes as modified; you talk of lists of IP addresses that could be "released", while the sysadmin has full control over what that list contains. A sysadmin is capable of altering discussion pages to silently change or remove enquiries that could expose such activities; a sysadmin can create sockpuppets with complete edit histories, discussions, RfAs, whatever; a sysadmin has complete control over what does, and does not, appear on the "forum" you suggest is established. Root access is total; sysadmins are above suspicion because there is no way you can suspect them and still retain your sanity: if you do not trust the sysadmins, then you must run the vote on a separate server, as is done for the WMF board elections.
So we must trust the sysadmins in such elections, both because we have no reason not to, and because we have no choice. Most of the issues that this proposal guards against then become unnecessary. Ballots cannot be stuffed, votes cannot be tampered with, the election tally can be assumed to be correct. There is no need for the voter or sequence ids. We are returned to the 'usual' problems with elections: inelegible voters, sockpuppetry, canvassing, and the like. Here I think that the proposal actually offers less facility to identify these types of issues than the current version of SecurePoll. Witholding IP addresses and other checkuser data from the scrutineers is a huge handicap, and attaching the timestamp to the vote and not the voter greatly hampers sockfinding efforts, IMO.
These are just my thoughts on the issue; I'd be interested to hear yours. As I say, I'd be delighted to incorporate any workable ideas into SecurePoll. Happy‑melon 22:31, 1 November 2009 (UTC)
- The underling assumption is exactly as you have described it: sysadmins can do literally anything. The precept is that if a sysadmin does something inappropriate they risk being caught i.e. the system does not prevent them from manipulating the vote (no system could), instead it raises the stakes. Sysadmins can manipulate a vote if the like but they will getting caught. And the greater the degree of manipulation, the greater the risk of getting caught. The means of catching attempts at manipulation is not assigned to a chosen few (who could be part of the fraud or simply fictitious users to begin with) but would be community supervision.
- For example, dynamically modifying the ballot page (at least) would be technically simple but would fall flat on it's face should someone simply copy and past what they see onto Meatball or somewhere else. They system would have to prevent communication from that person to others in order to cover-up the fraud - difficult not least since this would have to be done dynamically and (impossible) since Wikipedians also communicate off-system. Thus, the possibility of fraud is not eliminated, it is simply made more difficult to get away with under a system of community supervision.
- "So we must trust the sysadmins in such elections, both because we have no reason not to, and because we have no choice. Most of the issues that this proposal guards against then become unnecessary." This is a circular argument. We must trust the sysadmins because we have no choice? And if we trust them, we will have no reason to distrust them? I'd prefer if it were not a question of "trust" (in a moral sense) but a question of confidence in a system. The main concern raise against moving to a closed ballot is the matter of transparency. The proposal made here is all about that: transparency. Not "trust". --rannṗáirtí anaiṫnid (coṁrá) 00:32, 2 November 2009 (UTC)
- I agree that the question should be one of "confidence", not "trust", that's a much better word to use, but I do not agree that you can build a system on a WMF server where you are "confident" that sysadmins can neither damage nor manipulate it. Some of the checks this method implements are indeed very clever, but they 1) rely on every voter being absolutely paranoid about the vote enough to carry out their part in its validation, and 2) rely on some people being so paranoid as to carry out the group checks to the full. Just by stealing constructive IP edits, a sysadmin could create an entire family of administrators who were elected back in 2005, and who have been quietly editing obscure pages ever since; happy, dedicated members of the community who never cause any trouble and so quite naturally never bring themselves to the fore. Who is going to spot that kind of manipulation? Equally, who is going to be sufficiently paranoid (remembering that the sysadmins have full data to work out which voters are least paranoid) to take screengrabs of the tally page?
- In fact, measures that extreme are going to be completely unnecessary. There are 12 million registered users on enwiki. 85,000 of them have suffrage for an election like the ArbCom elections. Hiding ten, a hundred, a thousand, false voters in that list would be childs' play, because I don't care how paranoid you are, no one has the time or energy to audit a list that large. SecurePoll already assembles such a list for internal voter validation; it's not published purely because it's totally useless. Happy‑melon 10:34, 2 November 2009 (UTC)
- Well technically someone could create a script that parses that list and audit the result. If such a change to SecurePoll is technically and easily doable, this would be a great step for people to trust the secret ballot election. Good job, rannṗáirtí anaiṫnid! -- Luk talk 10:47, 2 November 2009 (UTC)
- But what would that script be looking for? What data would it be operating on, and what would it flag? Happy‑melon 17:46, 2 November 2009 (UTC)
- The script could compare historical history dumps from toolserver against the current history dump to identify changes in assigned edits. If changes were identified these could be compared against the ballot list to identify "voters" who were fabricated in the manner you described above. This is all quite trivial. --rannṗáirtí anaiṫnid (coṁrá) 09:10, 3 November 2009 (UTC)
- The Toolserver? The toolserver that receives a continuous stream of trusted database replication statements from the main WMF cluster? You're not being nearly paranoid enough :D. There are lots of things we can do to audit wiki data. It's just that the sysadmins can always do more. Happy‑melon 10:17, 3 November 2009 (UTC)
- Yes, but it increases the level of risk and headaches involved past the point of rudimentary changes to the database (under SecurePoll) to something more like a conspiracy. Not only would ballots have to be stuffed with fabricated users - but which ballot and what fabricated users would have to be planned in advance. Long, long, long in advance since copies of the various bits and pieces of the WP Db are floating around the internet all the time.
- It impossible to have a secret ballot that is 100% guaranteed secure - whether it is conducted online or offline. You can only just make it more difficult to tamper with ballots and not get caught. --rannṗáirtí anaiṫnid (coṁrá) 20:27, 3 November 2009 (UTC)
- Except that there hasn't actually been a full history dump of the English Wikipedia in many months. To do that would require making regular copies of the database table then comparing them with the current one, which would use so much resources it would probably render the toolserver almost useless for anything else. Of course, that only works if the sysadmins haven't already reallocated the edits. In any case, it would be easier to just hijack an old account that stopped editing in 2007 or something and make it look like they returned. It wouldn't require any changes to the database except possibly changing the password and faking the checkuser data and neither of those are accessible by toolserver users. People return from editing fairly regularly, so people wouldn't really think to question it. The only way it would really be noticed would be if the user really did come back, but with faked checkuser data, there would be no way to prove who did it. Mr.Z-man 23:09, 3 November 2009 (UTC)
- You could hi-jack an old account. That would be easy ... but could you pass the Turing test when an old editor friend posted a message on their talk page? And how would you explain it if it was an abandonded account by an user currently editing under another user name? What if it was someone who was known to be dead?
- All that risk for just one vote. How many more risks like that would someone have to take before their actually influenced the vote in any substantial way? The chances of getting caught would rise geometrically wouldn't it? One person could probably be passed off as a crank. Could you pass off enough to influence the vote?
- You have to stop thinking of this as a technical system. It is a process of human verification. Flawed, I know, hence: "working draft".
- In any case, you are making very good arguments to not switch to SecurePoll. I wrote this in an attempt to reconsile the desire of those who want to move to a secret ballot against the desire of those who didn't (I was very anti the idea.) You've convinced me now, that it's not possible to have confidence in an online elections. Cheers. --rannṗáirtí anaiṫnid (coṁrá) 23:43, 3 November 2009 (UTC)
- Easy, look at their older talk page messages to see how they responded, or pick an account that wasn't heavily involved in discussions. Its possible the user could still be editing, but the odds would still be tiny, probably about the same that they might return. The odds of being caught once would rise quickly, but the odds of being caught multiple times would not. Hijacking an account does not have anything to do with using SecurePoll at all, that method could still be used even under an open voting system as it doesn't require any manipulation that wouldn't also be necessary for any other voting method. We have to use some online voting method. The question is just whether or not we should use one that's the online equivalent of writing names down on a piece of paper, like might be used in a class president election, or a real voting system that's designed to provide at least some security while allowing us to conduct the election with election standards that have been commonplace since the 19th century. Mr.Z-man 00:10, 4 November 2009 (UTC)
- "the online equivalent of writing names down on a piece of paper, like might be used in a class president election, or a real voting system" - Writing names down on a piece of paper is a real voting system. You thinking too much like a technologist. Parliaments around the word conduct their affairs by a show of hands (yes, wars get declared, taxes get raised and laws get passed by a simple show of hands). When things get really tight some divide deputies into two chambers and count heads (in many it's not even two chambers, it simply two doors into one chamber and the deputies get counted as they pass). That's what an electoral system is.
- Unless an open system of voting is causing problems (which it currently isn't, is it?) then moving to a secret ballot is not a "advance", it's just adding an unnecessary level of complexity. Come one man, this is CS101 - never add increased complexity to a system unless you genuinely have to. My first degree was in politics and the same principle applies there too. --rannṗáirtí anaiṫnid (coṁrá) 00:26, 4 November 2009 (UTC)
- Easy, look at their older talk page messages to see how they responded, or pick an account that wasn't heavily involved in discussions. Its possible the user could still be editing, but the odds would still be tiny, probably about the same that they might return. The odds of being caught once would rise quickly, but the odds of being caught multiple times would not. Hijacking an account does not have anything to do with using SecurePoll at all, that method could still be used even under an open voting system as it doesn't require any manipulation that wouldn't also be necessary for any other voting method. We have to use some online voting method. The question is just whether or not we should use one that's the online equivalent of writing names down on a piece of paper, like might be used in a class president election, or a real voting system that's designed to provide at least some security while allowing us to conduct the election with election standards that have been commonplace since the 19th century. Mr.Z-man 00:10, 4 November 2009 (UTC)
- Except that there hasn't actually been a full history dump of the English Wikipedia in many months. To do that would require making regular copies of the database table then comparing them with the current one, which would use so much resources it would probably render the toolserver almost useless for anything else. Of course, that only works if the sysadmins haven't already reallocated the edits. In any case, it would be easier to just hijack an old account that stopped editing in 2007 or something and make it look like they returned. It wouldn't require any changes to the database except possibly changing the password and faking the checkuser data and neither of those are accessible by toolserver users. People return from editing fairly regularly, so people wouldn't really think to question it. The only way it would really be noticed would be if the user really did come back, but with faked checkuser data, there would be no way to prove who did it. Mr.Z-man 23:09, 3 November 2009 (UTC)
- The Toolserver? The toolserver that receives a continuous stream of trusted database replication statements from the main WMF cluster? You're not being nearly paranoid enough :D. There are lots of things we can do to audit wiki data. It's just that the sysadmins can always do more. Happy‑melon 10:17, 3 November 2009 (UTC)
- The script could compare historical history dumps from toolserver against the current history dump to identify changes in assigned edits. If changes were identified these could be compared against the ballot list to identify "voters" who were fabricated in the manner you described above. This is all quite trivial. --rannṗáirtí anaiṫnid (coṁrá) 09:10, 3 November 2009 (UTC)
- But what would that script be looking for? What data would it be operating on, and what would it flag? Happy‑melon 17:46, 2 November 2009 (UTC)
- Well technically someone could create a script that parses that list and audit the result. If such a change to SecurePoll is technically and easily doable, this would be a great step for people to trust the secret ballot election. Good job, rannṗáirtí anaiṫnid! -- Luk talk 10:47, 2 November 2009 (UTC)
- (undent)That system is also roughly how votes in North Korea work. People can deposit their vote directly (indicating they support the state party), or they can use a marker to indicate on the ballot that they vote no. Of course the police are on hand to see who picks up the marker and votes against the state party. There are many known problems with the current system. These are well documented on the RFC talk page. There are known cases of people being bullied after voting, or being afraid to vote for fear of offending people. There are concerns that arbitrators may not treat someone fairly when they know the person voted against them. There's also the issue of inertia, that later voters have a tendency to simply follow the trend rather than evaluate the candidates and/or vote how they really feel. This gives the voters in the first few hours significantly more weight, as they often set the trend for the rest of the election. With a secret ballot, people are free to vote how they feel without judgment (or the fear of it). Mr.Z-man 01:27, 4 November 2009 (UTC)
- "That system is also roughly how votes in North Korea work." Eh ... no - the example was for just about every liberal democracy in the Western world. --rannṗáirtí anaiṫnid (coṁrá) 08:41, 4 November 2009 (UTC)
- Every liberal democracy in the world uses an open vote? Really? Someone better tell the United States, because they abandoned open voting for elections in the 19th century. It might be used for Parliament/Congress votes, but that's because the votes are so short and frequent that a formalized voting system would slow things down too much, and because we expect that politicians can just deal with it in cases of intimidation. Mr.Z-man 18:39, 4 November 2009 (UTC)
- As in the example I gave, yes, even the United States. I also think you expect too much of politicians - they are nearly all subject to "intimidation" of a sort and, as I'm sure you know, politicians regularly vote not according to their hearts but what they think will endear them to an electorate better, to give just two examples. The decision to use a open/secret ballot is not (necessarily) determined by speed - many parliaments use a secret ballot. And a closed ballot is not, by the way, a more "formalized" system of voting - or allow for any more complexity in a voting system - it is just another way of voting.
- The last word is yours, I won't be replying here anymore. You made excellent points against the procedure I was proposing (and changed by mind about it) but now I think you are speaking beyond your expertise. --rannṗáirtí anaiṫnid (coṁrá) 00:43, 5 November 2009 (UTC)
- Every liberal democracy in the world uses an open vote? Really? Someone better tell the United States, because they abandoned open voting for elections in the 19th century. It might be used for Parliament/Congress votes, but that's because the votes are so short and frequent that a formalized voting system would slow things down too much, and because we expect that politicians can just deal with it in cases of intimidation. Mr.Z-man 18:39, 4 November 2009 (UTC)
- I agree with Happy-melon. We need to make sure that the on-wiki election supervisors cannot cheat the election, but trying to prevent the server admins from being able to do anything is nearly impossible (even if we move it to a non-WMF server, then we just get different server admins), as well as somewhat misguided. The server admins do little editing on Wikipedia, have little to no stake in the election, and have almost nothing to gain by election fraud. They are however, employees or contractors (there are some volunteers, but I imagine there is some sort of legally-binding agreement in place there as well for obvious reasons), so there could be significant real-world risks for them to defraud the election. Mr.Z-man 15:15, 2 November 2009 (UTC)
- Again it seems to be coming down to "trust" and "distrust" when the real issue is "confidience". The system being proposed does not guarantee 100% that no fraud can ever take place - once you introduce a secret ballot, no system can. It is designed to make fraud more detectable. It's purpose is to give confidience in the running and counting of an elections by allowing editors a greater degree of supervision over the election process.
- Whatever the hypothetical example of fraud - whether a sysadmin just went mad and decided to fabricate the outcome of an election, or whether the WMF board instructed a sysadmin to appoint a favoured candidate of theirs despite the genuine result - it doesn't matter. What matters is that people are confidient they have information available to them to catch such attempts at fraud. The current SecurePoll does not sufficiently do that. The changes proposed here are relatively trivial but would greatly enhance confidience. --rannṗáirtí anaiṫnid (coṁrá) 09:10, 3 November 2009 (UTC)
- Again I agree, but that doesn't help. You're trying to build "confidence" in an area of the election where there is no lack of confidence (to those free from FUD), and doing so by complicating the election to such a degree as to make it incomprehensible to the majority of voters. Happy‑melon 10:17, 3 November 2009 (UTC)
- The recurring theme on those who opposed a switch to a secret ballot on the first RFC was that they wanted confidience in the electoral process and a switch to a secret ballot, they said, would reduce that. Those concerns are being repeated again in the new RFC.
- I don't think the system I am proposing is in any degree more complicated. There is nothing new about it that is required to vote, only more information is there for those who want that confidience. The additional stuff is only there if a person want it, if they don't want it they don't have to look at it. There would be no new requirements in order to cast one's ballot. I think that's an imporant point. --rannṗáirtí anaiṫnid (coṁrá) 10:50, 3 November 2009 (UTC)
- The sysadmins and the board have virtually no stake in the election. They do, however, have everything to lose. If a sysadmin was fired for manipulating the database that they're employed to keep secure, I doubt that they would ever be able to get a job as a sysadmin again. What this proposal doesn't do though, is prevent the people who do have a stake in the election and have nothing to lose except being banned from Wikipedia (which compared to being fired, and possibly being sued depending on how their contract is written, is basically nothing) - Wikipedia users - from manipulating the election. Why are you assuming that just because people want confidence in the system, that they don't have confidence in the sysadmins? You're basically starting from the hardest point of improvement first, which also gives the fewest benefits. Mr.Z-man 17:15, 3 November 2009 (UTC)
- Again I agree, but that doesn't help. You're trying to build "confidence" in an area of the election where there is no lack of confidence (to those free from FUD), and doing so by complicating the election to such a degree as to make it incomprehensible to the majority of voters. Happy‑melon 10:17, 3 November 2009 (UTC)
- So there is nothing about the proposal that you would object to? You just don't see the need? Cool. Meanwhile, the RFC is currently about 50:50 with the primary concern of those who oppose a move to a secret ballot being transparency and confidence. This proposal came about as a means to address those concerns. If you don want to address them then I don't foresee a change to a secret ballot. --rannṗáirtí anaiṫnid (coṁrá) 18:09, 3 November 2009 (UTC)
- Did you read my comment at all? Why are you assuming that just because people want confidence in the system, that they don't have confidence in the sysadmins? No one except yourself has expressed these particular concerns. Mr.Z-man 18:38, 3 November 2009 (UTC)
- The loss of transparency was the major bone of contention during the first RFC. It is being repeated again during the current one. The "confidence" that I am referring to is the confidence that comes with transparency and is lost when transparency is removed. It is not necessarily a lack of confidence in the sysadmins or anyone else. It is not founded on the assumption that anyone is "out to defraud us". It is confidence in the system (and not merely the technological system) that I am saying that people want confidience in, we are in agreement on this, yes?
- I did read your comment, I just didn't see what you wanted me to respond to. --rannṗáirtí anaiṫnid (coṁrá) 19:11, 3 November 2009 (UTC)
- The problem is that this does little but provide a false sense of security. It attempts to increase confidence by making an already incredibly unlikely scenario slightly more unlikely while doing nothing about real issues that actually have a chance of happening. Its like building tank traps around your house while leaving your door unlocked. Also, I disagree that increasing the confidence level in the system increases transparency in any direct, significant way. Mr.Z-man 19:24, 3 November 2009 (UTC)
- Nice simile. So what I wrote above was correct? There is nothing about the proposal that you would object to? You just don't see the need?
- Also, what do you think is the "door" that is left unlocked?
- "I disagree that increasing the the confidence level in the system increases transparency..." So do I. I'm saying the opposite: that increasing transparency increases confidence. --rannṗáirtí anaiṫnid (coṁrá) 20:16, 3 November 2009 (UTC)
- The door left unlocked is the easier ways to manipulate the election which don't require being a Wikimedia employee/contractor with root access to the database. The big issues would be sockpuppetry and meatpuppetry. Other more minor, but still more likely issues could be vote buying, malware (installed on users' systems, not WMF servers), and man-in-the-middle attacks. I also don't see how this direclty increases transparency. It increases security by a tiny bit and significantly increases complication, but I don't see how either of those increase transparency. Mr.Z-man 23:09, 3 November 2009 (UTC)
- The attempt here was to address the things that are lost when moving to a secret ballot. Sock/meat puppets, buying votes, etc. are already a risk of open votes so I left them outside of the scope.
- The issue of transparancy in an open vote is quite obvious: the entire process - who voted, when, what they voted for, and so on - is laid bare for all to see. Someone could of course cheat the system, such as by socking - even enormously devious attempt by evil "system admins" - but you can at least see them. In a closed vote, the process is hidden from the voter. What I was wanted to do here was to open up as much of the system while maintaining the (supposed) benefits of a secret ballot. So, for example, users can see a list of elibable voters and they can see the pattern of votes (including the obstructed user who voted) and with the sequential numbers be satisfied that it was a genuine record of the vote (including its order), just as in an open ballot.
- Maybe I started off from the wrong end and was solipsist about it. Maybe the better place to start is to gather views from those who oppose a secret ballot for reasons of transparency and see what the deal is (actually, considering what I do for a profession, I know that that is the better place to start). --rannṗáirtí anaiṫnid (coṁrá) 00:15, 4 November 2009 (UTC)
- The door left unlocked is the easier ways to manipulate the election which don't require being a Wikimedia employee/contractor with root access to the database. The big issues would be sockpuppetry and meatpuppetry. Other more minor, but still more likely issues could be vote buying, malware (installed on users' systems, not WMF servers), and man-in-the-middle attacks. I also don't see how this direclty increases transparency. It increases security by a tiny bit and significantly increases complication, but I don't see how either of those increase transparency. Mr.Z-man 23:09, 3 November 2009 (UTC)
- The problem is that this does little but provide a false sense of security. It attempts to increase confidence by making an already incredibly unlikely scenario slightly more unlikely while doing nothing about real issues that actually have a chance of happening. Its like building tank traps around your house while leaving your door unlocked. Also, I disagree that increasing the confidence level in the system increases transparency in any direct, significant way. Mr.Z-man 19:24, 3 November 2009 (UTC)
- Did you read my comment at all? Why are you assuming that just because people want confidence in the system, that they don't have confidence in the sysadmins? No one except yourself has expressed these particular concerns. Mr.Z-man 18:38, 3 November 2009 (UTC)
- So there is nothing about the proposal that you would object to? You just don't see the need? Cool. Meanwhile, the RFC is currently about 50:50 with the primary concern of those who oppose a move to a secret ballot being transparency and confidence. This proposal came about as a means to address those concerns. If you don want to address them then I don't foresee a change to a secret ballot. --rannṗáirtí anaiṫnid (coṁrá) 18:09, 3 November 2009 (UTC)