I would prefer if the input to the software was published and anyone could verify the outcome. Unfortunately, currently none of this information is published and the whole system is based on trust.
Let's say that the software is published, and the code is audited and it looks ok - it seems to implement all of the intricacies of the transfer system and so on correctly. Then what? What if the operator forgets to use the latest version? or puts a different piece of software entirely on the counting system?
Having audited the source code really doesn't help; it won't remove the need to perform independent verification.
Similarly, merely publishing the input won't help much either; how do you verify that the published input corresponds to the actual votes? It won't remove the need for independent parties to observe the raw input (paper votes) and to make their own tallies; in which case those parties can publish their own copies.
Asking for the input to be published and the source to be published is just scraping the surface and won't add meaningful security. You need independent observation by mutually distrusting parties.
You keep saying this like people don't understand your point.
Personally I understand your point, but I think auditing the code is a good and important first step.
Technically it's worth noting that a code audit is required in any "perfect solution", so it isn't wasted effort.
Politically it is important to establish the principle that the AEC should be required to respond to reasonable requests to verify how the process is implemented.
Similarly, merely publishing the input won't help much either; how do you verify that the published input corresponds to the actual votes? It won't remove the need for independent parties to observe the raw input (paper votes) and to make their own tallies; in which case those parties can publish their own copies.
Note that in Australia vote counting itself is manual and is already observed by multiple hostile parties. No one is proposing removing that.
Let's say that the software is published, and the code is audited and it looks ok - it seems to implement all of the intricacies of the transfer system and so on correctly. Then what? What if the operator forgets to use the latest version? or puts a different piece of software entirely on the counting system?
Since we already have access to the raw counts the audited code can be run by anyone to verify it outputs the same output as the AEC claims.
The AEC does publish the totals for each candidate, at each stage of the Senate count [1]. There is a PDF for each state, under the heading "Distribution of Preferences". An example for NSW is at [2] Are these numbers sufficient input, to duplicate and verify the results of the AEC software?
Not really the same as the raw input, because while most people vote above the line, there will be a small number who vote below the line, and the incremental count doesn't show if these were allocated correctly.
The best you could do is compare the expected flow each step, based on group voting ticket, against the actual flow, and make sure the total difference does not exceed the number of below the line votes.
Do they publish how many people vote below the line?
Edit: Antony green has an estimate used in his calculator.
"At Federal election, around 95% of mainland voters, and 80% of Tasmanian voters, fill in their ballot paper using the group ticket ('above the line') voting option."
As I understand it - yes normally these numbers are sufficient to verify outcomes.
However in extremely close races, such as what happened in WA - it can come down to very small numbers of individual ballots and how their preferences are stated, as to what order senators are elected in.
