danwallach / star-vote Goto Github PK

We need to move VoteProofs inside the vote they correspond to, for ease of access in the tallying process.

Somewhere an important width value got removed during the refactor. I'll track it down.

To improve functionality with the new Precinct and Ballot classes, BallotStore's hashchaining and PIN generation functionality need to be moved into Supervisor.Model (see #41 and #42). BallotStore's ballot handling needs to be moved into Precinct (see #38). Tallier's tallying needs to be moved into Precinct (see #43). Supervisor.Model needs to react to several new events that are underway regarding #34 #35 #36 #37.

A lot of the preptool's input fields are hard to see. For instance, if I go to add a party or candidate, the field will get added to the table, but will have a white background with no border, so it blends in perfectly with the background. This may be an OS thing, I'll need to test it in Linux and Windows, but on Mac it can definitely be a big problem. Here are some pictures for examples:

On the candidate's screen, after adding a candidate

The newly added candidate focused

On the party screen, before adding a new party

After adding a new party, unfocused

After adding a new party, focused

We need to ensure that this is re-fit into the current code properly. This may affect whether #41 is still necessary since it seems there should be some sort of hashchain record kept in Auditorium.

This event needs to be created for Supervisors to notify Tap that they're done uploading ballots.

I may be able to rewrite it into a visitor. I think that would save a lot of heartache, but this is probably an optional thing.

This will be done in the votebox.events package

A lot of the file path construction is buggy and flaky, needs an overhaul.

Figure out how these are supposed to be implemented, and then figure out if they are actually implemented that way.

Evidently the t2s is broken in the launcher.

Currently, we allow mutiple supervisors to be active at once, which is a good thing. However, as of right now multiple supervisors do not share whatever ballot they have currently loaded. In the event that a supervisor issues a PIN corresponding to a specific ballot style and then goes down, there is no way for a votebox to get the ballot style. This is bad.

The supervisors should, on loading a ballot, broadcast that that ballot style was loaded and then send the ballot to the other supervisors. On issuing a PIN for a ballot style, the supervisor should set up a hierarchy of which supervisors will try to send the ballot style to the querying voting booth when. This has yet to be hashed out, but I know it will involve adding at least one more event in addition to a general reworking of the ballot loading process, and the way votebox asks for ballot styles. This needs a lot more discussion, and I'm not sure how much priority it should be given in the context of a demo.

The Votebox UI will go blank if it is alt+tab'd out of and then back to. I think the only real fix for this is to not use full-screen...

Selection boxes on the printed ballots are not rendered to the proper size.

HashChain class can/should be created in Model.java to deal with hashchain recording instead of Supervisor directly handling it.

A lot of the adder crypto has been messed with to function the way we need it. We should rewrite it so that it makes more sense. For instance, elections currently take in list of lists of things, which often are only one list or one element lists. See the following:

    /**
     * This will decrypt and return the final sum at the end of the election.
     *
     * @see ITallier#getReport()
     */
    @SuppressWarnings("unchecked")
    public Map<String, BigInteger> getReport() {
        /* Ensure the private key is still valid before decryption */
        _finalPrivateKey = AdderKeyManipulator.generateFinalPrivateKey(_publicKey, _privateKey);

        /* this map will house the final results after they've been decrypted */
        Map<String, BigInteger> report = new HashMap<String, BigInteger>();

        /* For each race group (analogous to each race), decrypt the sums */
        for(String group : _results.keySet()){

            /* Here our races are represented as "Elections", a class provided in the UConn encryption code */
            Election election = _results.get(group);

            /* From the election, we can get the sum of cipher texts */
            Vote cipherSum = election.sumVotes();

            /*
             * As per the Adder decryption process, partially decrypt the ciphertext to generate some necessary
             * information for the final decryption.
             */
            List<AdderInteger> partialSum = _finalPrivateKey.partialDecrypt(cipherSum);

            /* This is a LaGrange coefficient used as part of the decryption computations */
            AdderInteger coeff = new AdderInteger(0);

            /* This is a list of partially computed sums that are used in the decryption computations */
            List<List<AdderInteger>> partialSums = new ArrayList<List<AdderInteger>>();

            /* Add our local partial sum to the list of partial sums */
            partialSums.add(partialSum);

            /*
             * Add the coefficients to a list. This is largely due to the way the Adder code is written, and has little
             * to do with the actual mathematics of the decryption.
             */
            List<AdderInteger> coeffs = new ArrayList<AdderInteger>();
            coeffs.add(coeff);

            /* Rely on the Adder election class to perform the final decryption of the election sums */
            List<AdderInteger> results = election.getFinalSum(partialSums, coeffs, cipherSum, _finalPublicKey);

            /* Split off the results by candidate ID*/
            String[] ids = group.split(",");

            /* For each candidate in the race, put the decrypted sums in the results map */
            for(int i = 0; i < ids.length; i++)
                report.put(ids[i], results.get(i).bigintValue());
        }

        return report;
    }

Partial sums typically are only one list of integers, so the List<List<AdderInteger>> partialSums can be reduced to just List<AdderInteger> partialSum. Also, the LaGrange coefficient is only ever one number so List<AdderInteger> coeffs can be reduced to AdderInteger coeff.

I don't quite understand logging. Theoretically, should new machines connecting to STAR get the full log files? I recall this being discussed at our meeting in May, and I know there was discussion about opening a discreet socket between machines and beaming the log data, but I also recall someone suggesting that as long as the machine logs from when it comes online the logging and verification process can be preserved.

This is important largely due to issue #26. When a Supervisor machine comes online, it needs to figure out if the polls are open or not. As of right now, we have an event, LastPollsOpenEvent that notifies that the last polls opened event is being announced by a supervisor if the polls are currently opened.

Note: there may be a potential race condition if a machine comes online, inquires about the status of the polls, then the polls are closed, but a LastPollsOpenEvent is sent by a machine that hasn't received or processed the event yet. The new machine could query the poll status, hear that the polls are closed, and then hear the open event, resulting in all but the new Supervisor thinking the polls are closed.

The current implementation holds up regardless of the log transmission policy ultimately decided on, but in the case we decide to transmit the whole log to every new machine, then we could also check the logs to verify that the polls are indeed opened (notably eliminating the race condition discussed above). Regardless, this needs to be vetted more with people who know more things than I do.

When navigating the VB interface, if one element is focused and then another in quick succession, their sound files overlap. This is not supposed to happen, and the threads should be killed whenever an item is unfocused. I'll investigate it later, but my suspicion is that our refactor messed it up, or it was messed up before that.

Tallying does not currently occur on the server at all. It should, as per the STAR spec. Also investigate whether local precincts should decrypt and tally votes.

When the window is closed using the OS's window close operation, the whole application shuts down. I believe this has to do with the fact that the spoil pane has the normal Supervisor view pane as its parent component, and somehow its default operation on close is set to close the whole application. This is bad.

Some of our code has LaTeX in the method headers -- it would be good to be able to display these properly within the API on the website, if possible.

The inheritance hierarchy of ASExpression is terrible. It would be nice to fix it.

Need to migrate C++ comments from .jar to the adder subpackage files and inline comment to improve code readability and usability.

Apparently the ASExpression matcher isn't very well implemented. It works and I know how to get around it now, but it tends to match things incorrectly if it can't find the correct rule, and it will match using the first rule it finds if it matches at all.

This is another file path issue. Revamp webserver code to set up and use correct paths to challenged ballots at the end of an election.

As of now, when a new Supervisor comes online after the polls have opened, it does nothing to attempt to discover the status of the polls. We even have an event for this (PollsOpenedQEvent), I just don't think it's been implemented all the way.

The good news is that if the newly added machine attempts to open the polls, it gets updated locally and nothing bad happens on the other machines.

>>> ERROR: The IDrawable L2 is not in the list of keys: [L22, L24, L18, L25]

Line 212 of AWTView

As far as I can tell, this only happens in the Launcher. It's not due to a direct mishandling of the map, so I think it may have to do with a refactor of the draw methods. I'll have to look at it later.

We need to add this so that when one Supervisor gets a new ballot style, all of them do

Should the supervisor commit or cast the ballot? Not prescribed behavior...

As of right now, only one supervisor can be active at a time. Connecting and activating a second supervisor will force any active supervisor consoles into the inactive state. I think this needs to be fixed somehow.

This event needs to be created for Supervisors to notify Tap that they're going to be uploading ballots.

BatteryStatus.java currently doesn't correctly return the battery status.

This class should have all of its HTML moved into a file that is then read in and out by the class. See HTMLPrinter.java.

Note that it also needs to be commented.

Two different tallier classes to be created. SupervisorTallier will handle encrypted ballots and homomorphically tallying them while WebServerTallier will deal with decryption of challenged ballots and tallying total results.
#65 is related

Different QR readers lead to different results with our current QR codes.

Uploading shouldn't necessarily initiate immediately after a 'PollsClosedEvent'. There should probably be a button on the UI that should have to be pressed. A good reason for this could be if the polls need to be reopened.

The launcher also throws an index out of bounds when it goes to print:

Exception in thread "Thread-1" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:635)
at java.util.ArrayList.get(ArrayList.java:411)
at printer.HTMLPrinter.generatorHelperForTwoColumns(HTMLPrinter.java:192)
at printer.HTMLPrinter.generateHTMLFile(HTMLPrinter.java:107)
at printer.Printer.printCommittedBallot(Printer.java:217)
at votebox.middle.datacollection.Launcher$1$2.update(Launcher.java:221)
at java.util.Observable.notifyObservers(Observable.java:159)
at supervisor.model.ObservableEvent.notifyObservers(ObservableEvent.java:55)
at votebox.middle.view.ViewManager.drawPage(ViewManager.java:191)
at votebox.middle.view.ViewManager.nextPage(ViewManager.java:534)
at votebox.middle.view.widget.Button$1.execute(Button.java:154)
at votebox.middle.view.widget.Button.select(Button.java:309)
at votebox.middle.view.ViewManager.select(ViewManager.java:239)
at votebox.middle.view.ViewManager$4.handle(ViewManager.java:790)
at votebox.middle.view.AView.run(AView.java:137)
at java.lang.Thread.run(Thread.java:744)

When a non-numerical value is entered into the BallotScanner, it correctly sends a BallotScannedEvent and receives a BallotRejectedEvent, but then it infinitely loops, sending and receiving those events forever. Should fix this...

When a votebox goes offline in the middle of a voting session and then comes back up, the supervisor assumes that the machine is still voting, doesn't label it, and doesn't send it a polls opened message. This is bad.

Can/should create a class to do to/from ASE conversion rather than having classes use static to/from ASE methods.

We need to investigate whether or not an election keyword is needed in the STAR-Vote process.

Dialogues pop up multiple times in a votebox session every time the program returns to the PIN prompt.

When machines come online, we need a mechanism for determining if they are valid and for handling the case where they aren't. This is sort of done with keywords, but is not completely fleshed out.

PINValidator class needs to be tested and will replace functionality handled in the past by BallotStore.

Needs to be refactored to match CommitBallotEvent (switch from using one byte array to using multiple SExpressions). Currently causes an error in Votebox's registerForOverrideCastConfirm (line 430ish). Should probably also change the names of the override events.

Update SupervisorTallier to work the the new version of Ballot that contains a list of Votes. Related to #43.

We need a better way of dealing with ballot information flow than BallotStore, Tallier, and Supervisor (and what they're doing right now). We are going to design a class called Precinct that will hold all of the ballots for a given precinct (and therefore ballot style) and be able to perform functions such as homomorphically tallying as well as simple retrieval and mutation.

The interface seems to be the victim of inconsistent design. We need to get rid of the "Enable write-ins" option, I think.

For some reason provisional voting sessions end, but the voting session doesn't terminate. It could be because the Supervisor never sends a BallotReceived event in response, or it could be because the driver is not properly configured to kill at the end of provisional voting sessions.

votebox.events.ChallengedBallotUploadEvent does not do a very good job of serializing all of the ballots to be sent to the server. As a result, the server can't parse the incoming ballots properly, and therefore cannot recognize whether ballots have been challenged or not.

Fixing this will be 2-fold:

1 - fix the ChallengedBallotUploadEvent to package up the plaintext ballots in a nicer way

2 - Edit web-server.app.controllers.AuditServer.ballotDump() to handle the plaintext challenged ballots better.

How should voting booths react to polls closed event if they are in a voting session? Also, how should booths handle the case when a supervisor goes off line?