Wikipedia talk:Administrator elections/SecurePoll permissions proposal#Survey %2F Motion to close

{{Moved from|Wikipedia talk:Administrator elections#Second draft|–Novem Linguae (talk) 17:54, 23 April 2025 (UTC)}}

Alright. I've made a bunch of changes based on the comments above. How's Wikipedia:Administrator elections/SecurePoll permissions proposal look? –Novem Linguae (talk) 17:53, 22 April 2025 (UTC)

:I made a slight tweak to the first bullet in the technical changes section to try and make it easier to understand. The bullet re checkusers could do with simplified wording too I think but I haven't yet come up with something better. On the substance of the proposal though that looks good. Thryduulf (talk) 18:14, 22 April 2025 (UTC)

:I expanded the Background slightly, but overall it looks solid. When sharing it, I would recommend linking people to a discussion on the talk page for it asking for any tweaks or modifications. Consensus will come naturally as any concerns are addressed. This is, in the end, a proposal required to technically implement the result of 3 major, successful RfCs, and does not need separate authorization from the community, just buy-in from those who will be involved. —Ganesha811 (talk) 18:51, 22 April 2025 (UTC)

:Looks good! One thing I would like to ask is are we working under the assumption that electionadmin is a subset of admin? There's some comparison to edit filter managers above, which don't require member to be an admin. If electionadmins aren't required to be regular admins, then the name "electionadmin" may cause confusion. I assume it's a subset, but just wanted to check we're all on the same page here. BugGhost 🦗👻 20:11, 22 April 2025 (UTC)

::"Election administrator" is what it's called on other WMF wikis such as votewiki, so I think we should keep the terminology consistent.

::That's a good point though. Should there be a procedural requirement that election administrators be administrators? We should probably specify this. For now, I went ahead and edited the proposal to specify that non-administrators can be election administrators. However I am happy to flip it if folks want. I also added some wording to emphasize that this perm is for folks working on AELECT or ACE, and isn't intended to be handed out like candy. –Novem Linguae (talk) 21:07, 22 April 2025 (UTC)

:::There's nothing "adminy" about what election administrators are going to be doing, but somewhat echoing the comments made back in the two int-admin RFCs, AELECT and ACE are pretty important processes that should be operated by trusted editors, and admins are already vetted by the community in this regard which makes things more convenient (admittedly ELECTCOM doesn't have adminship as a criteria, but they go through an additional vetting process; are we going to do the same? The draft is a bit ambiguous on this).

:::Also, to what extent can securepoll be edited after the election has begun? Because if it can be significantly altered during an election then we absolutely want trusted folks as election administrators and have them enable 2FA. A mischievous editor or compromised account messing things up during setup would be annoying, but breaking the election while it's running would be disastrous. Liu1126 (talk) 23:22, 22 April 2025 (UTC)

::::I agree that the ability to unlock and report election results should be held by a trusted editor. I don't think that the arbitration committee electoral commissioner role is a good parallel, though. The commissioners aren't election admins for the SecurePoll vote (and by design they aren't required to be involved in the process at all, outside of their formal scope of making certain decisions as necessary), and the selection process is very lightweight (for example, only supporting statements are collected). isaacl (talk) 04:43, 23 April 2025 (UTC)

::::{{tqq|Also, to what extent can securepoll be edited after the election has begun?}} Important question, yes. Could you rename the candidates near the end of the election so that votes for one candidate appear to be votes for another? Leijurv (talk) 06:23, 23 April 2025 (UTC)

:::::{{tq|Also, to what extent can securepoll be edited after the election has begun?}} I tested it just now, and on the edit poll screen (which has things like poll questions and answers, start time, end time, poll name, poll type, and encryption), once the election start date occurs and the election is running, almost the entire edit poll screen becomes disabled, except for the "Return-to URL" and "Admins" fields. So I think the SecurePoll software engineers took these security concerns into account when designing it.

:::::{{tq|Could you rename the candidates near the end of the election so that votes for one candidate appear to be votes for another?}} Looks like this cannot be done. –Novem Linguae (talk) 06:48, 23 April 2025 (UTC)

::::::Good to know. I guess there's still a chance that an electadmin might mess up the configs immediately before the election begins (out of error or malice), but if other electadmins check the settings just after the election begins then the current poll can just be quickly scrapped and no major damage will be done (as opposed to breaking changes late in the election that would require the whole election to be rerun, which thankfully isn't possible as Novem explained above).

::::::I've thought a bit more on the level of trust needed for electadmin. Since AELECT and ACE are meant to be primarily run by community volunteers (plus ELECTCOM for ACE), electadmins are just going to be an arm of the community that mechanically implements community decisions. The level of trust and experience needed is going to be lower than admins (who may carry out unilateral actions like blocking or granting permissions) or int-admins and EFMs (who could break vast swathes of the site with their actions). They won't see any private information since securepoll-view-voter-pii is only given to checkusers. Maybe a lower requirement like extended confirmed? Further vetting can be done by the crats and, if necessary, a brief comment process like the one used for int-admin.

::::::The worst thing a "rogue" electadmin could probably do is publish the results too early, like during scrutineering or even halfway through the election (assuming that tallying can be done while the poll is running). The latter case could unduly influence the votes of later voters. Though if XCON editors are trusted to keep cool in the most heated contentious topics (i.e. under ECR), then they should be trustworthy enough to follow a simple directive of "don't publish results until scrutineering is done". Liu1126 (talk) 12:43, 23 April 2025 (UTC)

:::::::{{tq|or even halfway through the election (assuming that tallying can be done while the poll is running). The latter case could unduly influence the votes of later voters.}} I tested it just now and the tally page doesn't work until after the poll concludes. –Novem Linguae (talk) 17:51, 23 April 2025 (UTC)

:::::::Personally, I'm not sure "lower" is the right comparison for the level of trust. I think the scope of where trust is required is narrower. As I recall, when the extended-confirmed privilege was created, there was some concern that it would become a criterion used more out of convenience than because it was tailored for the specific needs of a situation. I think the proposed lightweight process (which is similar to the one for interface admins) seems sufficient. I have a theoretical concern about expanding the bureaucrat role in this way, as it crosses the boundary between deciding the outcome of a request for administrative privileges and managing the process. In practice, I guess it's just a small step over the line. isaacl (talk) 18:05, 23 April 2025 (UTC)

::::::::Yea, I suppose using XCON as a criterion isn't necessarily more suitable for this situation than adminship; best to leave it to the crats' discretion then (I highly doubt a new editor would be in a position to request electionadmin anyway, so even if implemented it would be no more than a pro forma requirement). Liu1126 (talk) 18:44, 23 April 2025 (UTC)

:I think this is good, but the wording {{tq|The Election Administrator right can be requested by anyone (administrator or non-administrator) by making a post at the bureaucrat's noticeboard.}} seems waaay to soft to me. Yes, it seems like electionadmins can't screw up an ongoing election, but we still shouldn't be handing this out like candy and I think we ideally give this right to the minimum number of people needed. Same concern, to a lesser extent, with {{tq|It does not need to be revoked upon completion of the election.}} Toadspike [Talk] 18:35, 23 April 2025 (UTC)

Alright, I see a couple of ideas and concerns raised in the above section, and some changes were made as a result, and some changes were not made for now. Do we think this proposal is fleshed out enough to be ready to ask for feedback from the bureaucrats and the checkusers? Are there any items above that have consensus to change that I'm missing? Thanks. –Novem Linguae (talk) 17:59, 23 April 2025 (UTC)

:I think it's ready enough for more feedback from a broader audience. —Ganesha811 (talk) 18:02, 23 April 2025 (UTC)

::{{Done}}. CheckUsers and Bureaucrats have been notified on their respective wiki pages. –Novem Linguae (talk) 18:33, 23 April 2025 (UTC)

Seeing as these aren't really doing the things we would expect are related to administrators, consider a name like "election editor" (in line with "template editor" as former art). Izno (talk) 19:06, 23 April 2025 (UTC)

:I see my first point is a point of contention above. I don't really honestly care about what other wikis call it. The user right can be named whatever but I would suggest at a minimum that all the user-facing information be named in the direction of election editor. Izno (talk) 19:08, 23 April 2025 (UTC)

:Seems reasonable. Thoughts from others? –Novem Linguae (talk) 19:56, 23 April 2025 (UTC)

:"Election editor" or "Election manager" (word copied from WP:EFM) are totally fine. I don't personally agree it's notably better than "election admin", but I could see it's a bit better in terms of the intuitions it tugs on. More of a procedural/ministerial position rather than an administrative decision maker. Leijurv (talk) 20:14, 23 April 2025 (UTC)

::Also fine with election manager. Izno (talk) 20:20, 23 April 2025 (UTC)

:::Two British terms we could appropriate for this are Polling Clerk or Returning Officer, the only option I don't like is Election Admin as this might be taken to imply you need to be an admin before taking on this role. ϢereSpielChequers 21:07, 23 April 2025 (UTC)

::::"Election clerk" also has good connotations and good precedent with SPI clerks and arbcom clerks. Leijurv (talk) 21:48, 23 April 2025 (UTC)

:::::I like "Election clerk", both an accurate description and has wiki-precedent. —Ganesha811 (talk) 23:44, 23 April 2025 (UTC)

::::::Yes, Election clerk would work. ϢereSpielChequers 06:03, 24 April 2025 (UTC)

:::::::{{Done}} –Novem Linguae (talk) 06:09, 24 April 2025 (UTC)

:Perhaps "electoral officer" (used in Canada) or "election official". If the "editor" noun is desired, then perhaps "poll editor" should be considered, since that's what they're setting up and editing. isaacl (talk) 00:38, 24 April 2025 (UTC)

::Clerking the process implies holding the election fairly and calculating the true result. Editing an election implies altering the election result in a particular direction. ϢereSpielChequers 06:03, 24 April 2025 (UTC)

:::Yes; that's why I suggested electoral officer or election official first, and suggested poll editor instead of election editor, if people wanted to have "editor" in the name. isaacl (talk) 10:01, 24 April 2025 (UTC)

I'd also suggest making it assignable by admins. Creation and editing of polls is low stakes, if even we might prefer not to hand it out to too many people (and can say as much at PERM or wherever it's decided to grant this, since BN wouldn't make sense if admins could assign). This would allow most theoretical CUs (and all current CUs) to self-assign if/when they need to do so as part of the election process. Izno (talk) 19:06, 23 April 2025 (UTC)

:Involving the bureaucrats was an attempt to copy the interface administrator process. Having sysops just self-assign (or assign to non-sysop editors with SecurePoll experience on other wikis or with technical skills) would simplify things. I think this is a good idea. We could keep this out of WP:PERM to discourage hat collecting. Thoughts from others? –Novem Linguae (talk) 19:55, 23 April 2025 (UTC)

::I think {{tqq|Only editors who are involved in managing elections processes such as administrator elections, arbitration committee elections, etc. should request the right. It does not need to be given out widely.}} is really ambiguous and thus not actually useful criteria. I don't know how you balance "give it to anyone who asks because they're putting their hand up to help with the election" with "it does not need to be given out widely". Making it assignable by any sysop - which loses the virtue of at least having the requests go to a single visible place where there can be coordination about it - feels like it make that worse. This feels like one of those things where it won't be a problem - because it's a thankless task only competent people are likely to volunteer - until it is a problem - someone incompetent volunteers and messes things up for everyone. I would suggest that if we want to be bank on "wont' be a problem" instead securepoll-create-poll & securepoll-edit-poll just get bundled into sysop, rather than make it grantable by any sysop. This would exclude non-sysop election admins (or whatever we end up calling it), but I don't know how much we're losing by that. If keeping it open for non-admins is useful, then I suggest not making it assignable by any sysop and make the criteria somewhat useful for someone (admin or crat) to decide if they should grant it or not. Best, Barkeep49 (talk) 23:07, 23 April 2025 (UTC)

:::Prior discussion: Wikipedia_talk:Administrator_elections#Have_CheckUsers_be_in_charge_of_creating/editing_SecurePoll_polls?. My opinion: the permission should be for sysops only, they shouldn't have it by default but can self-grant with volunteering to clerk for a particular election. Second choice is still sysop-only but they can't self-grant, they have to request a bureaucrat to grant it. Leijurv (talk) 00:11, 24 April 2025 (UTC)

:I think I agree with Barkeep49 that if there is a desire for the number of users empowered to create polls to be low, there should be a centralized process, just like for interface admins. The simplest way to keep the number low is to only assign the user privilege for a specific period of time, after which it is removed and the user can request it again if desired. isaacl (talk) 00:54, 24 April 2025 (UTC)

::I'm thinking the same thing. I don't know how many people we'd expect to have as "Election Admins" at any given time, but a centralized process acts as a barrier to entry, of sorts. Even if requests were granted at a 100% rate, I would expect fewer Election Admins than self-granting would result in, simply because of that extra step. Either way, though, I would expect a large influx at the beginning, which would then settle down over time. Useight (talk) 03:33, 24 April 2025 (UTC)

::{{tq|only assign the user privilege for a specific period of time}}. I'm not sure this is a good idea. It would probably result in the same people applying over and over again. It would also be the only perm on enwiki that is always handed out on a temporary basis. I don't think this level of security is needed. Don't forget that each poll is compartmentalized, so having SecurePoll permissions doesn't mean you can go editing every poll -- you can only edit polls that you are added to.

::There's been several ideas mentioned in this section. Which approach are people leaning towards? So far I kind of like Barkeep's idea of bundling securepoll-create-poll & securepoll-edit-poll with sysop, since that is a simple solution that skips needing to have a process to request it. I like simple workflows. My original proposal was to bundle it with CheckUser but that didn't catch on, so maybe bundling it with sysop is a good compromise. Thoughts? –Novem Linguae (talk) 03:59, 24 April 2025 (UTC)

:::That seems reasonable to me, or allowing admins to self-grant the right when volunteering to clerk an election. —Ganesha811 (talk) 04:02, 24 April 2025 (UTC)

:::There are permissions that have to be used in order to be kept. Specifically because I think it's beneficial for a larger pool of editors to gain experience with creating polls, rather than the same editors doing it repeatedly, I didn't suggest that approach for the electionadmin privilege.

:::My suggestion was contingent on their being a desire to limit the number of people with the privilege. As I recall, I previously said that I didn't see a big risk in all admins having the privilege assigned (though someone else disagreed). However I'm not sure what community consensus is on this issue. isaacl (talk) 04:23, 24 April 2025 (UTC)

I've [https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_elections/SecurePoll_permissions_proposal&diff=prev&oldid=1287133191 edited the draft] to have Election Clerks be assigned by Administrators instead of Bureaucrats. I don't think we have a consensus for anything yet, but I do think it'd be helpful to have this in writing to see what it looks like. Then folks can think about it more and discuss it more in this section. Thoughts? Is this change palatable? Or is Election Clerk too sensitive to hand out this easily? –Novem Linguae (talk) 06:16, 24 April 2025 (UTC)

:There is a certain overhead to the community in holding an election, at the least it distracts from other things and clutters internal advertising. So I assume we will only want elections to take place after some sort of consensus process to start one, as opposed to an RFC which anyone can call. That implies us only needing a limited number of election clerks as opposed to any admin being able to make themselves a clerk and start a secure poll election. If you want us crats to flip the bit on new election clerks, you need a criteria for us to measure those clerk applications against or better a process for the community to pick those clerks with us crats flipping the bit for the winners. Hopefully this can be as informal as a subpage of any election that has consensus to proceed with the clerks volunteering on that subpage. ϢereSpielChequers 07:01, 24 April 2025 (UTC)

:{{tqq|Or is Election Clerk too sensitive to hand out this easily?}} Just going off your comment above, it seems like the opposite? It sounds foolproof the way you describe it. When an election is running, it cannot really be interfered with. Therefore, you only need to trust the clerks to simply not vandalize. You don't need to trust them not to interfere with the results, because, they can't. (unlike scrutineers, who can). Assuming this understanding is correct, per WP:NOTBURO, I still believe sysops should just get this right by default (no new user group). Failing that, sure, your updated proposal is best, where sysops can self-grant the right without much fanfare. Leijurv (talk) 07:18, 24 April 2025 (UTC)

::The person managing the poll has to be trusted to manage the poll's encryption (including not losing the key to decrypt the results) and to report the results accurately. I don't think there's any risk of undetected vandalism. isaacl (talk) 10:08, 24 April 2025 (UTC)

:::I don't know how to come to a consensus on this question without the information of how trusted of a role Election Clerk should be. Novem's comment above seemed to indicate that once a poll has been started, the clerks cannot really mess with it. But your message indicates that the clerks must be trusted to {{tqq|report the results accurately}}. Is that true? I thought only the scrutineers could edit the results? What exactly are we trusting a clerk to do, or not do?Leijurv (talk) 19:06, 24 April 2025 (UTC)

::::From my understanding of the arbitration committee elections, the WMF staffer uses the key to trigger the SecurePoll software to decrypt the votes and tally them, and then the staffer reports the results. I believe after tallying the results are visible to the users who have access to administer the specific poll (they have been assigned by the poll creator or someone else with the ability to assign election admins for a given poll). So there should be multiple election admins assigned both for redundancy and to double check the tallied results. (I don't know if the results can be made visible publicly, directly from the SecurePoll extension.) As I understand it, scrutineers cannot "edit the results" per se. They can discard cast votes, but they don't know the actual contents of the vote, as it is encrypted. isaacl (talk) 22:02, 24 April 2025 (UTC)

:::::Maybe this is naive but do we need encryption? I could see why they set up this process, because the original use was for WMF board of directors. But, I don't think we should have any problem trusting the WMF's servers / databases to be untampered? Would this encryption key problem go away if the encryption option was disabled for our elections? Leijurv (talk) 23:24, 24 April 2025 (UTC)

::::::The primary issue, in my opinion, is not tampering but keeping the submitted ballots secret. Encrypting the votes ensures that no one with access to the backend can see the votes, and it's also easy to state that the election admins have no access to the votes, without someone hacking the software to expose the data. There was some discussion of this last year. I think enough people expressed a desire to keep the votes secret that leaving the votes unencrypted wasn't pursued, but I haven't re-checked the conversations. isaacl (talk) 23:41, 24 April 2025 (UTC)

:I think some level of trust needs to be established and thus some request process is needed (or, as previously discussed, all admins can be assigned the electionadmin privilege). isaacl (talk) 10:16, 24 April 2025 (UTC)

:As I indicated above I do not find this change palatable. isaac's point about the key is an important one and would lead me to support some kind of centralized process as a first choice, which also carries the advantage that it could be granted to anyone. To the comments @WereSpielChequers and I have left around criteria, I would suggest something along the lines of {{tqq|Election Clerk may be granted to a small number of users (optional: for each election) who are trusted to manage elections processes such as administrator elections and arbitration committee elections}}. As a 2nd choice, I think admins self-granting (with explicit prohibition against granting to others) works well (just so we ahve some log of who is raising hands to do the work) but have no real issue with it also just being bundled. Best, Barkeep49 (talk) 16:39, 24 April 2025 (UTC)

::You (or anyone) should feel free to edit the page to your preferred version. Maybe we can land on a good compromise if multiple people edit it. I am not seeing a clear consensus so far. –Novem Linguae (talk) 17:05, 24 April 2025 (UTC)

:::Although the sample size is really small, I think most people have expressed a willingness to live with the electionadmin right being bundled with the privileges given to administrators. We can see what other interested persons have to say.

:::On a bigger picture note: I think there needs to be some discussion on how the community wants the SecurePoll feature to be used before the electionadmin right starts to be handed out (alternatively, it could be given out with a caveat that it's only for admin elections for now). Does it want polls to be like mass messages, where anyone can request a message meeting certain criteria to be sent and a mass message sender can choose to approve the request and send it? Or does it want polls to be used only for specific community-approved events (one-time or recurring)? I think most editors involved in these discussions have been assuming the latter, but an argument can be made for allowing more broad use (not all polls have to be on topics requiring widespread participation; they can just be another tool for team collaboration). isaacl (talk) 18:54, 24 April 2025 (UTC)

::::My impression of the extension was that you can still have only one poll running at any given time, which has likely been a significant reason for feeling it was to be used for limited purposes. If that limitation has been lifted, then I think there is indeed an actual viable question of how the tool can be used. Izno (talk) 19:21, 24 April 2025 (UTC)

:::::I tested it just now, and I was able to open and vote in two elections running simultaneously, locally.

:::::I think the community would approve of SecurePolls for tests, AELECT, and ACE at the moment. I would probably support putting wording somewhere saying that using SecurePoll for other things would need some discussion first. For example, if WikiProject ABC wanted to have a lead coordinator election with 2 candidates, there might be some reasons to at least discuss it before doing it (SecurePoll has a lot of overhead for such a small election, and maybe the community doesn't want to normalize "voting" too much). –Novem Linguae (talk) 19:30, 24 April 2025 (UTC)

::::::My instinct is that the community wouldn't want to make secret ballot voting a common mode for collaboration, but I could be wrong. If they do, then there's a greater incentive to empower more users with the ability to create polls, so the workload can be spread. isaacl (talk) 22:16, 24 April 2025 (UTC)

:::::My understanding is that there's no limitation—right now there are eleven polls running for Chinese Wikipedia (see votewiki:Special:SecurePoll). The (virtual) server itself can only be configured for a specific language, but polls themselves can be multilingual, as that is one of the design requirements. (I believe there is some trickle down effect regarding left-to-right vs right-to-left languages due to the server configuration, but that doesn't impede the actual poll.) There is a limitation on the number of WMF staffers available to manage polls, but if English Wikipedia decides it wants to be able to run polls more freely, it can alleviate this bottleneck by assigning the electionadmin right to a broader pool of editors, such as all admins. isaacl (talk) 21:33, 24 April 2025 (UTC)

::::::@Isaacl As I recall, it's not even a one-language restriction, and the server can support multiple languages as long as they are all LTR or RTL. --Ahecht (TALK
PAGE) 18:25, 28 April 2025 (UTC)

It looks like this proposal is now stuck. I have tried drafting two versions (one where electionclerk is passed out by a request at BN, and one where electionclerk is self-assignable by admins) and I feel there were some objections to both. I'd encourage talk page watchers to try BOLDly editing the proposal to a compromise version that you think would attract consensus, then we can discuss it on this talk page. The WMF is about to green light SecurePoll, removing that blocker, so I'd like to avoid this proposal blocking the AELECT process. Let's get it across the finish line. –Novem Linguae (talk) 23:01, 27 April 2025 (UTC)

:I think we can go for self-assignable by admins. If this leads to issues, it can be changed. The election clerk role should not be made into a big deal - it's just another administrative task. Admins are trusted users by definition and this is a separate process from the scrutineering which will take place each election. —Ganesha811 (talk) 14:32, 28 April 2025 (UTC)

::Yeah screw it why not. If someone messes up we can make so it has to be done via BN request. fanfanboy (block_talk) 14:36, 28 April 2025 (UTC)

::I second this. – robertsky (talk) 15:45, 28 April 2025 (UTC)

::Assignable to admins seems like a good-enough compromise for now. Sohom (talk) 15:59, 28 April 2025 (UTC)

::This proposal is great as-is, I support! I have a lingering question, about Isaacl's comment above. We all agree that an election clerk is trusted to create the poll properly, and then once the poll is running it can't be edited. But what about after the end of the poll? Does an election clerk need to be trusted to report the final tally accurately? And do they need to be trusted to handle a GPG key safely? (storing it until the final tally, then erasing). I believe this information would be good to include on Wikipedia:Election clerk once it's written, because it greatly impacts how trusted this role is, and it would help sysops understand what they're getting into. For instance, should we have a policy of a minimum quantity of election clerks all of which need to agree on the final tally? Regardless of this, I still support the current proposal to be clear. Leijurv (talk) 18:30, 28 April 2025 (UTC)

:::While the election clerks might be able to view the final result, per WP:AELECT they will not be responsible for tallying and reporting votes - the scrutineers (three en.wp checkusers or stewards) will do that, and then the bureaucrats will grant the successful candidates admin rights. This was the system established in the reform RfC. As to the GPG key, I'm not certain. —Ganesha811 (talk) 18:33, 28 April 2025 (UTC)

::::The administrator elections page doesn't say that scrutineers will report the result, it just says "results are announced". With the resolution of Phabricator ticket T377531, scrutineers are electionadmins with the additional ability to perform scrutineering. The private encryption key must be entered to trigger the tallying. The private/public key pair is generated by the poll creator, who enters it to create the encrypted poll. So whichever electionadmin creates the poll, whether or not they are also a scrutineer, must be trusted to keep the private key safe, and to trigger the tallying. (For resilience to problems, a process for sharing the private key with at least one other electionadmin is probably desirable.) Any electionadmin can access the results once tallied, so all of them must be sufficiently trusted to report the results accurately (and not collude with the others). isaacl (talk) 23:25, 28 April 2025 (UTC)

:::::Sure, I think it makes sense to require whichever electionadmin creates the poll to share it. And we can trust admins to keep it safe. With regards to tallying, 3 checkusers/stewards scrutineering provides sufficient redundancy to makes sure the results are reported accurately, just like in the trial election. 23:34, 28 April 2025 (UTC) —Ganesha811 (talk) 23:34, 28 April 2025 (UTC)

::::::{{tq|And do they need to be trusted to handle a GPG key safely?}}

::::::Small correction: We don't use GPG anymore, we had to convert it to OpenSSL as part of the Kubernetes migration. No big deal. It's pretty much an identical process.

::::::I see the issue of who holds the encryption keys as an issue we can tackle later. I will need to do some localhost testing on how the encryption works (I haven't done it before), but I think any election clerk that's added to the poll can access the decrypt screen. I feel like we can decide the procedure for this in a talk page section at WT:AELECT later.

::::::{{Tq|Does an election clerk need to be trusted to report the final tally accurately?}}

::::::I think both election clerks and the scrutineers (who will also be election clerks) will be able to view the tally page, which will provide a check-and-balance against someone reporting the wrong tally. We will probably end up with 4 people who have access to the tally (the technical person and the 3 scrutineers). In other SecurePolls, the technical person usually posts the results, then the 3 scrutineers sign off on it on a wiki page using their wiki signatures. –Novem Linguae (talk) 23:49, 28 April 2025 (UTC)

:::::::What is the significance of encryption through OpenSSL keys in relation to election administration? Genuine question. 0xDeadbeef→∞ (talk to me) 08:40, 29 April 2025 (UTC)

::::::::It keeps wmf sysadmins from looking at the votes via sql database queries. Probably overkill for admin elections, but several people have stated that they want this feature turned on, so we will probably do it. –Novem Linguae (talk) 13:40, 29 April 2025 (UTC)

::::::::: Minor correction: Not all sysadmins are WMF staff, and the total number of people in question is several hundred. * Pppery * _{it has begun...} 15:47, 29 April 2025 (UTC)

::::::::See: [https://wikitech.wikimedia.org/wiki/SecurePoll#Encryption]. One thing that I didn't appreciate until reading more deeply is that by encrypting the votes in this way, it provides secrecy not just during the election but also on an ongoing basis into the future. If we didn't encrypt the votes, then it creates a risk that a single bad actor with access to the WMF database at any point in the future could leak all the votes on all past elections. As I understand it, the scrutineers shall view technical logs for each vote, and strike the ones that are determined to be socks / duplicates. But during this process, the votes are encrypted, so the scrutineers cannot see who each vote was casted for. At the end of scrutineering, the clerk(s) who possess the encryption key, shall apply that key to the votes through the "Tally" feature, which will decrypt the votes and store a tally in the database. At no point does the database contain the decrypted information of who voted for who. You do have to trust that in the moment of using the Tally feature, the server is behaving honestly / running honest code. And you do have to trust that the election clerk will discard the private key promptly after the tally is completed and ratified. But you don't have to trust that the server will never be compromised in the future. Leijurv (talk) 17:17, 29 April 2025 (UTC)

::::::Sure. The question Leijurv had was to understand what things electionadmins must be trusted to do, so those tasks can be taken into account when selecting electionadmins. isaacl (talk) 00:04, 29 April 2025 (UTC)

:::I agree to deal with potential availability issues that it would be good to establish a minimum number of electionadmins who need to verify the result. (Because electionadmins are just checking that the results have been transcribed correctly from the SecurePoll interface, there should be unanimous agreement.) isaacl (talk) 23:57, 28 April 2025 (UTC)

::::In the last election and in WP:ACE, the 3 scrutineers verify the results by signing a wiki-page. I assume that looking at the tally page is part of their signoff process. Although I suppose we could ask one of them if there is doubt.

::::* Wikipedia:Administrator elections/October 2024#Scrutineer ratification

::::* Wikipedia:Arbitration Committee Elections December 2024#Results

::::–Novem Linguae (talk) 00:06, 29 April 2025 (UTC)

One other aspect I think needs to be discussed about using SecurePoll is redundancy in poll administration. Should the decryption key be held by at least two election admins, so in case one is unavailable, the other can tally the results? isaacl (talk) 22:36, 24 April 2025 (UTC)

:This might be a good post for WT:AELECT. –Novem Linguae (talk) 23:45, 24 April 2025 (UTC)

Regarding [https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_elections/SecurePoll_permissions_proposal&diff=prev&oldid=1287850866 this edit]: I recall some discussion in Phabricator that some of the authorization checks in the SecurePoll software were based on user group membership, rather than user rights. Can someone comment if this is still the case? isaacl (talk) 00:26, 29 April 2025 (UTC)

:I think we fixed that in gerrit:1083338. [https://codesearch.wmcloud.org/deployed/?q=electionadmin&files=&excludeFiles=%5C.json%24&repos=mediawiki%2Fextensions%2FSecurePoll Searching the code for "electionadmin"] returns 0 results so I think that's all cleaned up. –Novem Linguae (talk) 00:34, 29 April 2025 (UTC)

::So there should no longer be any technical reason for scrutineers to have to also be placed in the electionadmin group? And thus no problem with the edit to which I linked? isaacl (talk) 00:39, 29 April 2025 (UTC)

:::The scrutineers need to have securepoll-edit-poll so that they can be added to the poll as admins. Without being poll admins, they cannot view the voter list. –Novem Linguae (talk) 02:02, 29 April 2025 (UTC)

::::Yes, I understand. My question was specifically regarding the edit I linked, which removed the sentence "Technical detail: CheckUsers doing scrutineering also need to be given the Election Clerk user group." I just want to clarify that this is indeed no longer an issue as long as the appropriate user rights have been assigned. isaacl (talk) 16:19, 29 April 2025 (UTC)

:::::Sorry my answers have been unclear. I wrote that sentence that was removed, and my idea behind writing it was to make sure that CheckUsers had securepoll-edit-poll so they could see the voter list. By giving them securepoll-edit-poll, they do not need electionclerk, so we should be all set there. –Novem Linguae (talk) 16:30, 29 April 2025 (UTC)

::::::As a practical matter all current CU are also admins and since the plan is to use enwiki CU to scrutinize, this is a "belt and suspender" situation. Best, Barkeep49 (talk) 19:46, 29 April 2025 (UTC)

I think we finally arrived at a draft that most folks support. [https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_elections/SecurePoll_permissions_proposal&oldid=1287850866]. Shall we do a quick survey just to make sure this is good to move forward? Please reply support/oppose below. If there's lots of supports, I'll link to this section in the Phabricator patch to demonstrate consensus.

• Support. We iterated several times (checkusers being election clerks -> requesting election clerk at BN -> admins can assign election clerk to anyone -> admins can assign election clerk only to admins) and arrived at the current stable version. –Novem Linguae (talk) 15:28, 29 April 2025 (UTC)
• Support A stable enough proposal for the first deployment, lets gets started with the elections! ~/Bunnypranav:<ping> 15:36, 29 April 2025 (UTC)
• :I support this but think while essentially using a lightweight form of consensus building (which I 100% support) it would be appropriate to weight more than 24 hours to decide something is stable given that we're not really operating under a time crunch here. Best, Barkeep49 (talk) 19:45, 29 April 2025 (UTC)
• Support The current proposal is my preference, though any of the options are fine. I just want to get this over with. fanfanboy (block_talk) 15:52, 29 April 2025 (UTC)
• Support Good enough to start with. Perfect4th (talk) 15:59, 29 April 2025 (UTC)
• Support Leijurv (talk) 16:06, 29 April 2025 (UTC)
• Support We're in a strong position to move forward. —Ganesha811 (talk) 16:24, 29 April 2025 (UTC)
• Support - all good to me, and we can refine later if needs be. BugGhost 🦗👻 17:44, 29 April 2025 (UTC)
• Support --Ahecht (TALK
  PAGE) 17:58, 29 April 2025 (UTC)
• Support—Mox Eden (talk) 00:29, 30 April 2025 (UTC)
• Support I like that the initial introduction of these roles are limited to people who already have trust from the community to carry adjacent tasks. Good initial proposal to move forward and introduce local processes with. 0xDeadbeef→∞ (talk to me) 12:33, 30 April 2025 (UTC)

It's been a few days. Looks like there's plenty of support here. WMF just gave final approval on their end. I think I'll move forward with this on the technical side. Thanks everyone for your feedback. –Novem Linguae (talk) 08:45, 2 May 2025 (UTC)

:Great! Is it the right time to merge some of the content from this proposal to the main WP:AELECT page, or would you prefer to wait until after the technical changes are implemented? —Ganesha811 (talk) 16:12, 2 May 2025 (UTC)

::Sounds good to me. Maybe a couple minimal details for the AELECT page, and full details for the Wikipedia:Election clerk page. –Novem Linguae (talk) 17:25, 2 May 2025 (UTC)

:::Seeing as this has consensus, I've taken a stab at creating an initial version of Wikipedia:Election clerk, given it the shortcut WP:ECLERK, and added a short mention at AELECT. BugGhost 🦗👻 16:33, 3 May 2025 (UTC)

::::Thanks, looks great. Once the technical changes are implemented and electionclerk actually exists, we should add something to Wikipedia:User access levels as well. —Ganesha811 (talk) 16:35, 3 May 2025 (UTC)