You seem to think that paper voting systems by neccessity depend on transporting all the ballots to a central location, where they'll be counted.

This is how paper voting works in Sweden.

To summarize and simplify:

• On election night, the ballots are hand-counted by election officials at every polling station. Results are phoned in to the authorities and tallied, and made available to the general public. (Basically an entire database dump of vote tallies in every district is made available as an XML over the Internet. Pretty cool.)
• Afterwards, ballot boxes are sealed and sent to the local county to be counted again.

• It goes without saying that Sweden is not directly comparable to Brazil, but consider this for a moment. It doesn't require all ballots to be hand-delivered to a central location where they will be counted - it's scalable. And no less secure than electronic voting. Probably just as secure technically, and more secure in practice, because it's easier to see when funny stuff happens to ballots in boxes than when bits are flipped.

No need to guess. I'm from Sweden.

The intent of my grandparent post wasn't to say that everywhere that matters has wireless broadband right now, I'm just saying that within a few short years, cell networks simply are going to get much better all over the world, simply because of the demand for services like this. Well, okay, short of places like North Korea or the North Pole.

Even in the remoter areas of the world, or in areas with practically no telecom infrastructure, cell service is how the world is being connected, because it's simply too expensive to hardwire everyone in.

I simply don't see the attraction of having a read-only device with no real time updates and no communication capabilities, in the long run.

My point is, that a product like this is an technological evolutionary "dead end" - doomed to be swallowed by and forgotten in favor of the ubiquitous web browser in your pocket - technology that exists and works today.

With ubiquitous cellular broadband practically everywhere (that matters) and phones with good web browsers in them, this is a solution looking for a problem.

From my understanding of the blog post, the hole described by the blog post allows you to write a data structure containing the window size into any arbitrary kernel memory location.

The information about terminal window size etcetera comes from the teletype. I'm sure that it wouldn't be too difficult to write an exploit which basically implemented a "stub" teletype which had most features unimplemented except one that returns a fake window size - allowing you to write arbitrary data to kernel memory.

Now, I'm no kernel hacker, I frighten easilly at the sight of X86 assembler, but I'm sure that - once you can actually write arbitrary data to kernel memory - you can get root in pretty short order. I don't know - the most straightforward way to me would sound like just munging the process table.

If Gillette made a wireless optical mouse, the mouse itself would be dirt cheap, but would be powered by proprietary non-standard non-rechargable batteries that cost about 50 euros each for a month of usage.

Just name all your machines Zathras. Slight difference in pronunciation.

Zathras. Zathras. Zathras. Can you hear it?

To give you an idea about how slow Apple are about patching security holes, and to add another data point to the description:

I reported the security issue known as CVE-2009-1697 (which is included in this large patch release). The e-mail back from Apple confirming receiving my report of this issue is dated January 7, 2009 in my e-mail inbox. That's about half a year ago.

Now, granted the security bug I reported is actually very difficult to exploit and do anything actually useful with. Basically, if you used XMLHttpRequests in Safari and requested a URL ending with a newline, it would end up in the final HTTP request as double newlines. I.e. the HTTP header would be terminated prematurely (before the Host: header, significantly) and thereby allow javascript to access files hosted on the default website on the same server the javascript was served from. For example, if victim.example.com is served on the same IP address as evil.example.com - javascript on evil.example.com could use this to request files on victim.example.com.

In other words - you could do cross-site-scripting targetting another web site served on the same IP address as the web site hosting the exploit.

Still, took them about 6 months to patch it and actually roll it out an update, it seems. Heh.

Eil,

This post so wonderfully parallells current political developments in Sweden that I had to re-post it on my blog for more people to read.

Link to blog post (in Swedish -- at least the parts you didn't write :-))

Mostly incomprehensible automatic Google translation

Thanks for taking the time to write your comment.

I just read the draft. That has got to be one of the more awesome hacky ideas I've read about this year.

Thanks for sharing!