Page MenuHomePhabricator

Investigate SecurePoll [8Hr]
Closed, ResolvedPublic



We want to look into the SecurePoll extension to assess its current state.

Event Timeline

Niharika triaged this task as Medium priority.Oct 28 2020, 6:29 PM
Niharika created this task.

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
    • Support for multiple tallying approaches
  • 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
  • Retention of non-public information for ballots

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
  • Other
ARamirez_WMF renamed this task from Investigate SecurePoll to Investigate SecurePoll [8Hr].Nov 4 2020, 5:25 PM

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.