Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ElectionGuard – A free open-source voting SDK

blogs.microsoft.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: ElectionGuard – A free open-source voting SDK

#21

Post by mises »

24gttghh wrote: post #19
mises wrote: post #18

Earlier quoted context omitted.

"It is very important that you use a No. 2 pencil. It is very important that you fill in the entire circle darkly and completely. If you change your response, erase as completely as possible. Incomplete marks or erasures may affect your score." And here I was, thinking I was done with scan-trons when I finished high school. But seriously, couldn't you modify a scan-tron's firmware to falsely report results? It's much…

A hand recount of the physical ballots would hopefully expose the correct count if a modified scan-tron was miscounting.

...which takes us back to hand-counting. In that case, what is the purpose of scan-trons in the first place? They may be easier for machines to grade, but are harder for humans to grade (harder to follow question number to line). So we will lose time gained with scan-trons to slower human re-counts.

Re: ElectionGuard – A free open-source voting SDK

#22

Post by pfranz »

gregmac wrote: post #3

> The ElectionGuard SDK will be available through GitHub beginning this summer. We encourage the election technology community to begin building offerings based on this technology and expect early prototypes using ElectionGuard will be ready for piloting during the 2020 elections in the United States, with significant deployments for subsequent election cycles. Where is the "we invite interested developers and groups…

My understanding from previous articles is that the DARPA grant went to coming up with the architecture and spec, then vendors would do the actual implementation. This looks like middleware.

From this random coder's perspective, the architecture previously designed sounded good. Voting and tallying were two separate systems. A physical, user-decipherable, paper that the voter carries over connected the two (it sounded something between a QR code and scan-tron).

It's good to see an open source codebase that multiple vendors would implement against.

Re: ElectionGuard – A free open-source voting SDK

#23

Post by pfranz »

ch wrote: post #10

Cool use of Hom encryption, but does nothing about disenfranchisement.

One problem at a time. This wasn't specifically intended to address disenfranchisement. But commoditizing the infrastructure helps protect against "we don't have enough resources to let all these people in an underserved community vote."

In previous (recent) elections you hear about voting machines sitting in storage or running out of paper ballots. Having a mature and open voting infrastructure allows old, commodity hardware to be used (including paper) instead of expensive, proprietary machines that can go "out of date" and "no longer supported/updated."

Re: ElectionGuard – A free open-source voting SDK

#24

Post by northernjames »

mises wrote: post #21
24gttghh wrote: post #19

Earlier quoted context omitted.

A hand recount of the physical ballots would hopefully expose the correct count if a modified scan-tron was miscounting.

...which takes us back to hand-counting. In that case, what is the purpose of scan-trons in the first place? They may be easier for machines to grade, but are harder for humans to grade (harder to follow question number to line). So we will lose time gained with scan-trons to slower human re-counts.

When margins are wide, you could count 10% of the ballots by hand as a sanity check on what the machines are reporting.

When margins are close, you could count them all by hand.

Pretty sure we could develop ballots that are easy for both humans and scanners to read. By using computer vision rather than whatever they had in the 1980s I'm pretty sure we could find a solution here.

Even so, given the value of our democracy, I'd happily support returning to counting all ballots by hand every election.

Re: ElectionGuard – A free open-source voting SDK

#25

Post by hawaiian »

maze-le wrote: post #11
deevolution wrote: post #6

Earlier quoted context omitted.

Care to explain why you think pen and paper is the best solution?

It is documented all the way down to a single vote (some voting-computers must implement a paper-trail as a secondary feature, here it is free). Tempering is very hard when there are enough volunteers, providing oversight over the procedures. Everyone (not just security specialists, versed in reverse engineering) can verify if a vote has been tempered with. Well that said, I don't think its the "best" solution per se…

>Everyone (not just security specialists, versed in reverse engineering) can verify if a vote has been tempered with.

Tampering with paper elections is extremely easy. You can throw out entire ballots, fill in choices where left blank, or force the ballot into an invalid state.

Not to mention the task of counting ballots using people necessarily requires splitting up the task and trusting people.

Electronic voting systems are supposed to address many of these problems, especially as processing the election becomes laborious. We don't need to give up on electronic counting solutions. We just need to make them impervious to tampering and/or verifiable.

>But it is far better than trusting a computer, that by definition "can do everything computable". And falsifying an election is definitly computable.

Tallying up votes by hand is also computation, you're just switching silicon for people.

Re: ElectionGuard – A free open-source voting SDK

#26

Post by nicoburns »

hawaiian wrote: post #25
maze-le wrote: post #11

Earlier quoted context omitted.

It is documented all the way down to a single vote (some voting-computers must implement a paper-trail as a secondary feature, here it is free). Tempering is very hard when there are enough volunteers, providing oversight over the procedures. Everyone (not just security specialists, versed in reverse engineering) can verify if a vote has been tempered with. Well that said, I don't think its the "best" solution per se…

>Everyone (not just security specialists, versed in reverse engineering) can verify if a vote has been tempered with. Tampering with paper elections is extremely easy. You can throw out entire ballots, fill in choices where left blank, or force the ballot into an invalid state. Not to mention the task of counting ballots using people necessarily requires splitting up the task and trusting people. Electronic voting sy…

> Tampering with paper elections is extremely easy. You can throw out entire ballots, fill in choices where left blank, or force the ballot into an invalid state.

Hard to do this while you're being watched by observers though...

And if you need to recruit many people to make your tampering scheme work, then it's much harder to keep it a secret.

Re: ElectionGuard – A free open-source voting SDK

#27

Post by ElijahLynn »

Love that there is more movement around solving this. Paper ballots DO NOT allow a voter to verify there vote was counted and is a huge issue with TRUST. Allowing users to verify their votes (however it happens) COULD have a big impact in voter participation.

Looking forward to seeing this movement keep advancing.

Re: ElectionGuard – A free open-source voting SDK

#28

Post by xmprt »

mises wrote: post #15
shinigami wrote: post #13

Earlier quoted context omitted.

It's a terrible idea. Paper-only elections are easily corrupted. The right answer is combining paper & electronic.

But tampering with a paper-only election requires physical interference and working across many different locations. It is much easier, if you have the talent, to break into an electronic election.

That's why you use both. Paper for tallying and electronic for auditing. I used to think electronics wouldn't help but now I'm starting to be convinced.

Re: ElectionGuard – A free open-source voting SDK

#30

Post by Mankaninen »

There is one more problem with encrypted elections not yet listed here; the vote is secret for now but 5, 10 or 20 years later it will be easy to break.

This might mostly be a problem for those then powerful, if someone find out that they voted "wrong" long time ago, our trust in them will be reduced. Yet a way to do negative campaigning.

Post reply on HN