At this time, when a user accesses the details of a vote (which contains IP and user-agent information) this is not logged. Similar to T152934, we should also modify SecurePoll such that:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | jrbs | T152972 Accessing private information through SecurePoll should be logged | |||
| Resolved | STran | T271276 Log when admins access voter data in SecurePoll |
I...believe accessing PII in votes already _is_ logged? See T290808#7346530 for how it can be used (with direct DB access, admitted) and https://github.com/wikimedia/mediawiki-extensions-SecurePoll/blob/master/includes/Pages/ListPage.php#L130 for the code.
For requiring scrutineers/election admins to request CU data before seeing it, I don't think that'd be a wise choice, as it would more or less destroys the way how scrutineers do its job.
For enwiki, scrutineers are routinely appointed local checkusers for the duration of the election. If we required scrutineers to request CU data via a form, there would be no difference between "CUing selected users locally" and "CUing at votewiki", except the former gives me significantly more information than the latter (so...there'd be no reason for me to use the latter at all). Scrutineers don't have any other way to suspect things than limited CU-like data votewiki provides: they're not active on the wiki, and subsequently don't know most of the usernames (and that's true even on enwiki).
Bonus point: As you surely know, part of the fawiki supervisory council election procedure for scrutineering is to strike proxy votes. How am I going to do that, if I don't see all of the IPs? :-)
Also CC @Tks4Fish, one of the scrutineers for recent elections.
I completely agree with @Urbanecm here, and have said so previously at T266695#6650245: there is no point in hiding the data that is on the table from the scrutineers, it'd only make our job way harder to be done, which would probably result in a rubber-stamp of votes since asking for the data of every single vote is definitely going to get tiresome (this year's enwiki ACE already has 1633 votes). The accessing additional data part *is* already logged, with those logs available to the elections committee.
Miscommunication here.
My reason for filing this task was to take that log that is only accessible through direct server access, and make it something that can be seen in SecurePoll's web interface. That is, when I, as an scrutineer, load a page that lists 25 users along with their IPs and UAs, a log (or 25 logs?) should be generated to indicate this, and this log be accessible at, say, Special:SecurePoll/accesslog
Was this resolved with T271276? The last few comments were months after this was implemented so I don't want to boldly close without confirmation.
No response so boldly closing this task given the successful implementation of T271276: Log when admins access voter data in SecurePoll.