ph14nix

> And the reason you can't add your digital signature to your vote is that you could then prove to someone you had voted for candidate X and collect your bribe.

I was arguing against treating a blot on a paper as a certification of one's opinion rather than proposing a real electronic voting protocol. Of course, simple digital signature doesn't solve all the problems, it only certifies with known assumptions that I and only I have signed the document.

What fascinates me in the electronic voting is not the economical benefits of it or computers being involved, but the guarrantees provided by the cryptography. Not the paper itself, but the handritten signatures are driving me crazy.

Of course, the particilar implementation of an electronic voting protocol can be hacked. Also, some cryptographic algorithms are not proven to be completely secure, so there is a chance that someone will learn to break them. We should take those facts into consideration and be aware.

What about paper elections? Aren't they fundamentally broken because of their protocol? I go to the election, sign a ballot paper and drop it into a box. Then some people from the government report me the voting result. Why should I trust it? Because I trust all the people who were involved in collecting the ballots, counting them and so on?

Why should I trust people at all if the cryptography allows me to verify their actions?

You are afraid of voting machines being hacked? No problem, let's use paper. I'm OK with paper certifying my vote as long as my digital signature is printed on it (in hex, QR-code or whatever). Alternatively, the government can publish an open protocol of internet voting so that everyone can use an implementation that he accepts to be secure.

Should be noted that I am not very proficient at cryptography. All I know is based on a couple of books and a university course.

> UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison.

Well-designed high-level programming language (see Perl6) compares strings depending on how they look, not on their binary representation [0].

For example let's play with Perl6 REPL:

  > my $a = Blob.new(0xc3, 0xa4)
  Blob:0x<c3 a4>
  > my $b = Blob.new(0x61, 0xcc, 0x88)
  Blob:0x<61 cc 88>
  > $a eqv $b
  False
  > $a.decode() eqv $b.decode()
  True
  > $a.decode() eq $b.decode()
  True

As another example, Python3 would fail:

  >>> a = b'\xc3\xa4'
  >>> b = b'\x61\xcc\x88'
  >>> a == b
  False
  >>> a.decode() == b.decode()
  False

Perl6 is definitely going to dominate the world one day.

[0] https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...

> With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught.

Most of these tools require support from an operating system. This is not the case when you do kernel programming. For some reason even existing tools are not popular among kernel programmers [0].

IMO, there are bugs that can be caught well a compile time without my effort, so why should I waste time on catching them at runtime?

I would better make love to compiler instead of having sex with debugger.

[0] http://lwn.net/2000/0914/a/lt-debugger.php3