Finally! :)
In all seriousness, I am very excited about this. I have been thinking/wishing that we could do an overhaul and modernization of this extension in the same fashion done for CheckUser (as in, create a parallel set of special pages, etc.)
I am sure you have seen T145653 and its related tasks.
I am the de facto maintainer of SecurePoll so I am happy to assist in any way I can.

Thanks a lot @Huji! It's awesome to know that you have experience working with SecurePoll. We have been asked to look into this extension to see how much work might go into improving it and to decide if we want to adapt something that has been built externally and does the job better.

In that case, perhaps I can help you with listing a set of acceptance criteria for the next tool (may it be a revamp of SecurePoll, or an external tool that people can log into using OAuth or something). For now, I refer to that as "future tool".

Here are a set of features that the future tool should support (most of which are currently supported by the existing version of SecurePoll):

• Support for multiple voting systems
  • Support for multiple ballot types
    • Approval voting (including the support/oppose model as well as the support/oppose/neutral model)
    • Ranked voting
    • Cardinal voting (sometimes called "grading") -- currently implemented as range voting
  • Support for multiple tallying approaches
    • Percentage-based (for approval voting)
    • Average-based (for ballots that can be interpreted as a grade, including s/o/n approval voting)
    • More complex methods
      • Shulze (for ranked voting)
      • Meek (for ranking voting) -- currently not supported, see T117127: Add support for the Meek STV method in SecurePoll
      • Others (see Template:Voting systems on enwiki) -- currently not supported
• Support for multiple questions on the ballot that are tallied in different ways (e.g. one approval question and one ranked choice question, where the first is tallied as percentages and the second using Shulze method)
• Support for specific configurations of the voting system
  • Disallowing ties in ranked choices -- currently not supported, see T118073: SecurePoll option to not allow voters to have ties in their order of preferences
  • Disallowing unranked choices in a ranked choice ballot -- currently not support
  • Disallowing unvoted choices in other methods (such as approval voting) -- currently not supported
• Retention of non-public information for ballots
  • IP and UA associated with each vote
  • Access log for non-public information viewed by election admins -- currently not supported, see T152972: Accessing private information through SecurePoll should be logged

Here are a set of additional enhancements that would desirable; by definition, none of them is currently supported:

• Modernization of the UI
  • Use OOUI throughout the forms (or for an external tool, make sure they have a modern UI with better usability)
  • Drag-drop tiles for ranked choice voting (as opposed to current method which requires entering integers for ranks)
• Possibility of tallying votes using different methods
  • For example, ranked choice ballots can be tallied using several methods (Shulze, Meek, etc.) and it may be desirable to compare the results of those for the same set of ballots
• Independence from shell access
  • For tally: right now, tally really only works through CLI; a deferred job mechanism should be used instead, to allow tallies to be initiated through the web interface
  • For configuration: my understanding is that decrypting an encrypted election still requires shell access to the database
• Better data export
  • T266385: Eligible voter list should be shown in read-only fashion to non-election admins
  • T145695: Dump should return decrypted votes
  • Better documentation of the Dump output (right now, it is pretty cryptic and not documented anywhere)
• Other
  • Users should be able to see their own votes if they go back to the poll page
  • T25727: Extend SecurePoll to allow voters to enter optional comments in some polls

Further to @Huji's helpful comment just above, here's a summary of some more of SecurePoll's features.

Users with the securepoll-create-poll right can:

• create a new poll
• assign particular users as poll admins for particular polls

Poll admins can:

• edit the poll
• tally votes
• view private info of voters
• define voter eligibility (see below)
• translate questions, options, instructions, etc.

i18n support:

• General instructions are already translated into many languages
• Provides interface for translating all questions, options, etc. for each poll
• Voting forms have MediaWiki's RTL support

a11y support:

• Works without JavaScript
• Keyboard accessible
• Voting pages work on mobile
• Appearance of tables on mobile could be improved

Voter eligibility can be determined by:

• minimum edits
• registration before a certain date
• whether blocked
• whether blocked on more wikis than the allowed maximum
• whether flagged as bot
• eligibility/override/exclude lists in addition to the above criteria

Features of polls:

• Specify which wiki (or all wikis)
• Different voting systems and tallying approaches (see T266695#6592442)
• Choose whether voters can change their votes
• Choose whether voter list (without private info) is visible to everyone
• Encryption
• Shuffle questions/options

SecurePoll has some privacy problems (some of which are mentioned in T152972). These include:

• All poll admins can see private information for users who voted on that poll (IP, UA, etc)
• A user with the securepoll-create-poll right can make any other user a poll admin (no restriction on having signed an NDA)
• Poll admins cannot see a list of users without seeing their private information
• When a poll admin views private information, this is not logged

My impression is that SecurePoll meets most of Trust-and-Safety's requirements for polling software, except regarding the privacy problems. If we were to do a revamp of SecurePoll in time for next year's board elections, I think we could meet the minimum requirements by addressing these privacy issues.

I believe @Niharika is looking into using external tools? I could see that route taking more work: e.g. finding a tool that satisfies the requirements, potentially agreeing contracts; hosting the tool (or getting community agreement to use an externally-hosted tool); adding comprehensive i18n support (e.g. integrating with translatewiki, implementing something like SecurePoll's translation UI); determining voter eligibility (we may have to query CentralAuth for user account info). We may also find that it takes a similar amount of work to ensure access to private information is controlled and logged appropriately as with SecurePoll.

Great summary, @Tchanders . I just wanted to add that T268794 should also be in scope for this investigation.

As a scrutineer for this year's enwiki ArbCom elections, I'd like to suggest some improvements:

• Highlighting of votes coming from the same small range (/24's for IPv4, /64's for IPv6), so as to make it easier to identify a possible socking
• Tagging of votes as "already analyzed", so that other scrutineers/electionadmins can know that certain votes were already analyzed for socking or whatever and no action was taken

I also disagree with @Huji's closure of the private data, as that will prevent the detection of possible socking which will most likely (IMO) result in a rubberstamp check of every vote. I don't disagree, however, on the possibility of the creation of a new right (something like securepoll-view-private) that would allow users to view that.

As for the NDA requirement, that is normally covered: enwiki requires election commissioners to have signed the NDA (don't know if that's the case for fawiki, but Huji was the responsible for this year's election and, as a CU, has signed it too), scrutineers for fawiki and enwiki arbcom elections are always stewards, who have already signed it, and the electadmins that set up the polls are WMF staffers, who are covered by NDAs already.

Closing, as the investigation part is done. We'll keep referring to this info as we plan and make more tasks - thanks @Huji and @Tks4Fish.