3 ms·

Almost every democratic country on Earth today does it like that, and all democratic countries have done it like that for the last 100-200 years. Counting paper

Almost every democratic country on Earth today does it like that, and all democratic countries have done it like that for the last 100-200 years. Counting paper ballots is just not that hard. Machines are infinitely more complex and exploitable. Plus, you have the extra layer of public perception: it's much easier to convince a chunk of the public that all the machines in some area are miscounting, than it is to convince them that all human vote counter in those areas are miscounting, and all in the same direction.

Aerroon 2y ago
that all human vote counter in those areas are miscounting, and all in the same direction. And you can send observers that can watch the entire process.
- Dalewyn 2y ago
  >watch the entire process. "Entire" is the keyword here. Any programmer worth their salt knows that it's practically impossible to vet that what is executing is 1:1 the code that someone at some point in time audited somewhere, or that the code is worthy of trust from the commons in the first place. Anyone and everyone can watch someone count paper ballots, noone can watch a computer count electronic ballots.
  - ethbr1 2y ago
    > Any programmer worth their salt knows that it's practically impossible to vet that what is executing is 1:1 the code that someone at some point in time audited somewhere, or that the code is worthy of trust from the commons in the first place. What? There are entire systems built around doing exactly that. Embedded, military, high-trust. It's never state of the art performance or mass deployed, because most people would rather have performance and cost optimized over assurance, but it exists and is in production use. You verify hardware, chain of custody from production to delivery, track every deployed piece of hardware, then lock the firmware and enforce restrictions on anything that executes after that. It's not easy or cheap (or foolproof, as anything can be exploited), but it's also not impossible. And substantially hardens security. And for simpler systems with lower performance requirements, completely achievable. F.ex. voting machines don't need to be running 16-core, hyperthreaded CPUs running multi-process operating systems
    - Dalewyn 2y ago
      >What? There is no way to demonstrate that what is executing is the source code unless you're compiling at execution time from a local vetted copy of the source code. Is the guy who vetted the source code vetted? Who vets the vetter? Is the compiler actually compiling the source code? Is the compiler compiling as generally expected? What about bugs in the compiler? Is the source code even what it claims (binary blobs!)? What about the hardware? Are there any black box enclaves? Bugs? Does it actually crunch as would be generally expected of a number cruncher? Does it even have the vetted software? All this complexity and anyone would be fully within their right to say "I don't and won't trust this." Meanwhile, someone counting paper ballots by hand can be immediately understood by anyone and everyone. It's simple and it's brutally effective. So what if the process takes time? Good stuff usually takes time, what's the rush? So what if the human counter(s) screw up? Human errors are inevitable, that's why you count multiple times to confirm the results can be repeated. The most secure, most hardened, most certified ballot counting machine cannot compare to a simple human counting paper ballots in witness of anyone and everyone.
      - ethbr1 2y ago
        The questions you're asking make it seem like (a) you're not thinking about this very hard, (b) you're trying to reach the answer you've already decided on, or (c) you're not familiar with high trust systems. Still, in the interest of a conversation, some brief answers. Please ask in detail about any you're interested in (but realize I'm going to balance the time I spend answering with the time you spend researching and asking). "Is the guy who vetted the source code vetted?" Yes, because he or she was assigned a key and signed the code with it. "Who vets the vetter?" Whatever level of diligence you want, up to and including TS+SCI level. "Is the compiler actually compiling the source code? Is the compiler compiling as generally expected? What about bugs in the compiler?" This is why you test. And it's pathological to believe that well-tested compilers, that have built trillions of lines of code, are going to only fail to successfully compile election code. "Is the source code even what it claims (binary blobs!)?" See test and also dependency review and qualification. "What about the hardware? Are there any black box enclaves?" Yes, by design, because that's how secure systems are built. And no, the enclaves aren't black boxes. "Bugs? Does it actually crunch as would be generally expected of a number cruncher?" Testing and validation. "Does it even have the vetted software?" Signed executables, enforced by trusted hardware. > Meanwhile, someone counting paper ballots by hand can be immediately understood by anyone and everyone. It's simple and it's brutally effective No, it's not. Because people are messy, error-prone entities, especially when it comes to doing a boring process 100+ times in a row. You're not comparing against perfection: you're comparing against at best bored/distracted and at worst possibly-partisan humans. Human counts rarely match exactly, because humans make mistakes. And then they make mistakes in the recounts intended to validate counts. If you can't envision all the ways humans can fail, then I'd reflect on why things never fail at your work because of people, and everything always runs smoothly.
sadeshmukh 2y ago
Human counters can be biased, and they're definitely more inaccurate. Machines, unless actively exploited by a third party, will always do the same thing, time after time. I don't believe it's worth the extra expenditure to hire tens of thousands of counters (again, human counters adds manual counting into the process, meaning another place for it to go wrong/be manipulated) when machines do the same thing with no fuss.
- simiones 2y ago
  > Machines, unless actively exploited by a third party, will always do the same thing, time after time. That "unless" is the whole problem. And it's not just if a third party gets involved, it can well be from the builders or the current operators of the machine who are the ones actively exploiting it as well.

Aerroon 2y ago

that all human vote counter in those areas are miscounting, and all in the same direction. And you can send observers that can watch the entire process.

Dalewyn 2y ago
>watch the entire process. "Entire" is the keyword here. Any programmer worth their salt knows that it's practically impossible to vet that what is executing is 1:1 the code that someone at some point in time audited somewhere, or that the code is worthy of trust from the commons in the first place. Anyone and everyone can watch someone count paper ballots, noone can watch a computer count electronic ballots.
- ethbr1 2y ago
  > Any programmer worth their salt knows that it's practically impossible to vet that what is executing is 1:1 the code that someone at some point in time audited somewhere, or that the code is worthy of trust from the commons in the first place. What? There are entire systems built around doing exactly that. Embedded, military, high-trust. It's never state of the art performance or mass deployed, because most people would rather have performance and cost optimized over assurance, but it exists and is in production use. You verify hardware, chain of custody from production to delivery, track every deployed piece of hardware, then lock the firmware and enforce restrictions on anything that executes after that. It's not easy or cheap (or foolproof, as anything can be exploited), but it's also not impossible. And substantially hardens security. And for simpler systems with lower performance requirements, completely achievable. F.ex. voting machines don't need to be running 16-core, hyperthreaded CPUs running multi-process operating systems
  - Dalewyn 2y ago
    >What? There is no way to demonstrate that what is executing is the source code unless you're compiling at execution time from a local vetted copy of the source code. Is the guy who vetted the source code vetted? Who vets the vetter? Is the compiler actually compiling the source code? Is the compiler compiling as generally expected? What about bugs in the compiler? Is the source code even what it claims (binary blobs!)? What about the hardware? Are there any black box enclaves? Bugs? Does it actually crunch as would be generally expected of a number cruncher? Does it even have the vetted software? All this complexity and anyone would be fully within their right to say "I don't and won't trust this." Meanwhile, someone counting paper ballots by hand can be immediately understood by anyone and everyone. It's simple and it's brutally effective. So what if the process takes time? Good stuff usually takes time, what's the rush? So what if the human counter(s) screw up? Human errors are inevitable, that's why you count multiple times to confirm the results can be repeated. The most secure, most hardened, most certified ballot counting machine cannot compare to a simple human counting paper ballots in witness of anyone and everyone.
    - ethbr1 2y ago
      The questions you're asking make it seem like (a) you're not thinking about this very hard, (b) you're trying to reach the answer you've already decided on, or (c) you're not familiar with high trust systems. Still, in the interest of a conversation, some brief answers. Please ask in detail about any you're interested in (but realize I'm going to balance the time I spend answering with the time you spend researching and asking). "Is the guy who vetted the source code vetted?" Yes, because he or she was assigned a key and signed the code with it. "Who vets the vetter?" Whatever level of diligence you want, up to and including TS+SCI level. "Is the compiler actually compiling the source code? Is the compiler compiling as generally expected? What about bugs in the compiler?" This is why you test. And it's pathological to believe that well-tested compilers, that have built trillions of lines of code, are going to only fail to successfully compile election code. "Is the source code even what it claims (binary blobs!)?" See test and also dependency review and qualification. "What about the hardware? Are there any black box enclaves?" Yes, by design, because that's how secure systems are built. And no, the enclaves aren't black boxes. "Bugs? Does it actually crunch as would be generally expected of a number cruncher?" Testing and validation. "Does it even have the vetted software?" Signed executables, enforced by trusted hardware. > Meanwhile, someone counting paper ballots by hand can be immediately understood by anyone and everyone. It's simple and it's brutally effective No, it's not. Because people are messy, error-prone entities, especially when it comes to doing a boring process 100+ times in a row. You're not comparing against perfection: you're comparing against at best bored/distracted and at worst possibly-partisan humans. Human counts rarely match exactly, because humans make mistakes. And then they make mistakes in the recounts intended to validate counts. If you can't envision all the ways humans can fail, then I'd reflect on why things never fail at your work because of people, and everything always runs smoothly.

sadeshmukh 2y ago

Human counters can be biased, and they're definitely more inaccurate. Machines, unless actively exploited by a third party, will always do the same thing, time after time. I don't believe it's worth the extra expenditure to hire tens of thousands of counters (again, human counters adds manual counting into the process, meaning another place for it to go wrong/be manipulated) when machines do the same thing with no fuss.

simiones 2y ago
> Machines, unless actively exploited by a third party, will always do the same thing, time after time. That "unless" is the whole problem. And it's not just if a third party gets involved, it can well be from the builders or the current operators of the machine who are the ones actively exploiting it as well.