Commons talk:Picture of the Year/2019/Committee

Let's get this going

@Christian Ferrer, -revi, Steinsplitter, Moheen:

It's 2020 now :) Would you mind adding yourself to Commons:Picture_of_the_Year/2019/Committee/User so people know us?

Unfortunately I'm still got a lot of IRL stuffs going on, but I will get all the technical stuffs like gadgets and modules ready this few weeks.

Start date: In Commons_talk:Picture_of_the_Year/Archive_1#POTY_date I think we agreed to do March and April. So how about March for R1 and April for R2, and make the start times close to the starts of the months and two weeks in between?

Categorization: Christian Ferrer, Moheen, would you mind handling Commons:Picture_of_the_Year/2019/Candidates?

It's fine for me. ~Moheen ^{(keep talking)} 18:17, 24 January 2020 (UTC)

Central notice: Steinsplitter, revi, would you mind handling that?

--Zhuyifei1999 (talk) 18:04, 24 January 2020 (UTC)

• Hi, ok I added me to the list, I will begin soon to check/start sort the images. Christian Ferrer ^(talk) 09:19, 25 January 2020 (UTC)

How about R1 March 8 - March 22, R2 April 5 - April 19? --Zhuyifei1999 (talk) 06:23, 1 February 2020 (UTC)

• Fine. Christian Ferrer ^(talk) 07:02, 1 February 2020 (UTC)
• OK --Steinsplitter (talk) 08:52, 2 February 2020 (UTC)

CN

• The request is placed here: meta:CentralNotice/Request/Picture of the Year 2019 --Steinsplitter (talk) 09:10, 2 February 2020 (UTC)

Categories

I just went to Commons:Picture_of_the_Year/2019/Candidates, IMO the categories are fine now. Christian Ferrer ^(talk) 12:23, 6 February 2020 (UTC)

FYI

Commons:Village_pump/Technical#Looking_for_someone_to_take_my_part_in_POTY --Zhuyifei1999 (talk) 22:01, 22 February 2020 (UTC)

Cryptography proposal

The problem is:

• people analyzing the the vote statistics prematurely and publishes them -- Commons:Village_pump#Commons:Picture_of_the_Year/2019/Real-Time-Results
• people votes are completely public and being thanked for -- Commons_talk:Picture_of_the_Year/2019/Help#Concerns_on_german_signpost

Because we have to be transparent, and do eligibility checking, and perform the entire voting process on-wiki, we have to release who voted for what after each round, instead of homomorphic encryption compute the tally because the latter does not not allow for the decryption of voter.

I'm thinking of using asymmetric encryption of this scheme:

Instead of vote pages like Commons:Picture_of_the_Year/2019/R1/v/Foobar.png, we have pages like Commons:Picture_of_the_Year/2019/R1/v/AB where AB is the first two characters in the hex payload (explained later)

Each vote page contains entries of the form:

* [[User:Username|Username]] ABCDEF1234567890

• [[User:Username|Username]] exists for abuse filter purposes, you can only delete the entries you created.
• ABCDEF1234567890 is the entire hex-encoded payload, consisting of:
  • an asymmetrically encrypted random symmetric encryption key -- I'm thinking of using RSA here

    The purpose of this is en:IND-CPA

  • an symmetrically encrypted message, containing the voter and candidate -- I'm thinking of using AES here

    Ignore the entry if the voter is not the given plaintext username -- prevents someone from replaying someone else's vote

    Ignore the entry if candidate is invalid

    Other checks like eligibility, double voting, and more-than-three-votes-during-R2 still apply

  • a checksum of the payload prior -- I'm thinking of using CRC here

    The purpose is just to prevent absolute junk from being considered at all, so no need for a cryptographically secure hash function

We publish the asymmetric encryption public key to the JS before the round, and publish the secret key along with the vote counting script output after each round so that results can be verified. Each round will use a new key pair for asymmetric encryption.

The JS will first attempt to use Web Crypto API, and if that is not there, we polyfill it. For non-JS users, we provide a toolforge tool to do the crypto, asking the user for a username and a candidate to vote, it generates the line to add to the vote page and the page name.

How does this sound? Input welcome. CC @Eatcha: also. --Zhuyifei1999 (talk) 16:56, 12 March 2020 (UTC)

I'll also note that I have no time to implement it for this year so this proposal is for next POTY. --Zhuyifei1999 (talk) 16:59, 12 March 2020 (UTC)

Implementation will be tested on beta first prior to attempting here. --Zhuyifei1999 (talk) 17:31, 12 March 2020 (UTC)

Thinking about this, there's a significant issue: until phab:T128602 becomes a thing, if one changes browsers, the gadget forgets what they have voted for and cannot unvote. This cannot be restored easily without the unpublished secret key. Perhaps have a toolforge tool to tell what images a user has voted for after they themselves authenticate via oauth? --Zhuyifei1999 (talk) 01:30, 13 March 2020 (UTC)

Sounds good to me. --Steinsplitter (talk) 17:04, 12 March 2020 (UTC)

Outside my skills. Christian Ferrer ^(talk) 17:29, 12 March 2020 (UTC)

IMO the benefits of encryption do not outweigh the costs. Concerns about privacy can be addressed by making it clearer that votes are public. As for issues with outcomes influencing subsequent votes, I think the current/tentative compromise seems reasonable: keep a heavily qualified version in userspace that's not advertised in any way. I think the number of votes it would influence would be exceptionally small. On the other hand, I'm probably not the only one who prefers to err on the side of transparency and visibility except when there's potential personal harm (as with the political nature of some arbcom elections or WMF board elections). $0.02 — Rhododendrites ^talk |  17:59, 12 March 2020 (UTC)

Special:Diff/403647810 was not addressed. The page will be known no matter whether you advertise it or not. Regarding transparency and visibility: I will publish the plaintext of every valid ciphertext with the vote counting script. --Zhuyifei1999 (talk) 18:09, 12 March 2020 (UTC)

I don’t entirely understand how these steps prevent both issues, but the question is: if we go for privacy (I’d also rather support openness, but in case privacy wins), do the votes really have to be stored as wiki pages? Shouldn’t we rather use either Special:SecurePoll (if it fits our needs), or entirely a Toolforge tool (which can store data privately until the end of the round, and open source can prove the results haven’t been tampered with)? —Tacsipacsi (talk) 18:05, 12 March 2020 (UTC)

Openness wins IMO. Votes should not be known during the round, but should be known after the round. --Zhuyifei1999 (talk) 18:11, 12 March 2020 (UTC)

No, openness definitely loses with any change compared to the current situation. (I was speaking about current vs change, not change A vs change B, so, to make clear, I support keeping the current situation.) I’m sure a custom web application can be as open as the proposed cryptographic solution, although it may be more difficult to create that web application. —Tacsipacsi (talk) 23:22, 12 March 2020 (UTC)

The current situation does not work. Openness during a round and preventing someone from analyzing and publishing the vote statistics are mutually exclusive. So no that is a no-go. --Zhuyifei1999 (talk) 00:17, 13 March 2020 (UTC)

A custom web application are more difficult to trust than cryptography. The web application cannot prove the results have not been tampered with without crypto. I did ask a cryptographer about this issue and he recommended Helios, but it is homomorphic encryption and does not suit our use case perfectly. --Zhuyifei1999 (talk) 00:23, 13 March 2020 (UTC)

Regarding SecurePoll: this seems discussed before and the extension lacks some features we absolutely require. Commons_talk:Picture_of_the_Year/2009#Votine_system_:_about_SecurePoll Commons:Picture_of_the_Year/2009/Preparation#Final_-_using_SecurePoll? --Zhuyifei1999 (talk) 18:35, 12 March 2020 (UTC)

• I do not want to comment or have any opinion. I would also try to Abstain, from discussions related to real-time results or POTY unless pinged. I am also on a wikibreak, right now. // Eatcha (talk) 19:00, 12 March 2020 (UTC)