ronin coder

I’ve twittered about this already, but I think that it’s worth repeating: collecting redundant and invalid voter registration cards is not the same thing as fraudulent voting. I repeat: by registering people multiple times, or even submitting invalid registration cards, ACORN (and every other voter reg group) is not committing voting fraud. They are simply doing a bad job of actually registering voters.

The whole reason that voter registration is required before you’re allowed to vote is so that the local and state election boards can have a chance to verify your eligibility. If you submit more than one registration, it may cost them a few minutes of work to update or reject your registration records, but it won’t allow you to vote more than once.

So, if it doesn’t let people “vote early and often,” why in the hell would ACORN, as an organization, have such a poor record regarding bad registrations? It’s simple: they require their workers to meet a certain quota in order to get paid. I’ve done a bit of volunteer voter registration, and while it’s easier than many other types of direct-contact political work — fundraising and candidate canvassing are both harder, if only because of their inherent partisan focus — you still have good days and bad days out on turf.

Try to imagine yourself in the following position: you’re a high school or college student trying to make a little money over the summer, while still doing something a bit more proactive than flipping burgers. Furthermore, your meager paycheck is dependent on hitting your quota each and every week, and you’ve heard horror stories of the poor-performing workers who got canned just last month.

Now, imagine you’re two registrations short of your quota for the week. Would you be even a little bit tempted to fake one, or press that nice stranger who insisted they were already registered to do so again, in order to save your job? I suspect that most people, if they’re being honest with themselves, would answer at the very least that they might be at least a little bit tempted. I know that I would, which is part of the reason that I’m not very interested in doing any paid political work — as a volunteer, the temptation to cheat goes away.

(Please note that I’m not trying to defend this sort of behavior as ethical, but it is at least understandable.)

Personally, I think the interesting argument isn’t even about whether ACORN does a good or bad job of supervising their staff, or encouraging the right behaviors. The real debate we should be having is whether paid voter registration does more harm than good. The same question extends to signature-gathering, an especially hot issue in Oregon given the recent flood of bad ballot measures.

I personally haven’t decided one way or the other, but I think that a much more constructive discussion is there, waiting to be had, once we get past the current baseless accusations being leveled at ACORN and its partner groups.

Since the Android phone announcement on Tuesday, there has been a decent amount of wild speculation going around the ‘tubes about the differences in “developer experience” between the iPhone and Android platforms. While my opinions on Apple’s legal and business restrictions on iPhone developers are pretty clear, I haven’t really written much about the technical underpinnings.

Generally, both platforms mostly abstract away the underlying UNIX-y system, and heavily sandbox 3rd-party applications to limit their ability to corrupt or expose the user’s data. Android gives users more options to replace or augment core applications, but the underlying sandbox mechanisms remain in place — i.e., an app can’t access your contact list unless you explicitly grant it that privilege at install time.

Also, both platforms rely heavily on code signing. You can’t distribute an iPhone app through the App Store unless it’s been signed with an Apple-issued certificate; The Android OS, on the other hand, allows developers to use the certificate of their choice to sign apps. (Carriers could lock this down further, of course, but there’s been no indication that such a lock will be in place for the G1.)

In terms of the actual toolchain, there are some major differences. While the iPhone uses a simple cross-compiler to build Objective-C projects, the Android tools are designed to support compilation to VM bytecodes, which are then transferred to the mobile device and JIT-ed in place. The XCode/Eclipse distinction is really one of personal preference, and both systems provide first-class support for command-line compilation and packaging, so you could configure Emacs/Vim/TextMate/etc. to handle project build tasks.

I also have the sense (and this is where my lack of access to the full iPhone SDK becomes a problem) that that the iPhone tends to package shared services as Framework libraries (ala OS X) while Android relies on a high-level IPC framework and reusable sub-processes (called Activities) to allow applications to invoke each other to perform common tasks.

Of course, one of the biggest distinctions to my mind is that Android projects can make use of multithreading and background daemons (Services in Android-speak) to handle long-running and GUI-less tasks. The notification APIs provided in the iPhone may cover a lot of asynchronous messaging use cases, but having full use of threads opens  up a lot of other interesting possibilities.

Overall, both platforms offer an interesting environment to work with. iPhone apps are likely to be less inter-dependent, with better protections against any one badly-authored app causing the phone’s performance or battery life to suffer. However, iPhone developers will struggle much more than their Android-targeting-colleagues to find ways to integrate their applications, both due to their inability to coordinate between simultaneously-running threads, and due the the NDA’s restrictions on information-sharing amongst themselves.

…for voting! (Well, for trying to convince people to vote, anyway.)

Rails has a fun (well, okay, kinda crippled and lame but still interesting) piece of infrastructure called ActiveResource. It basically lets you glue domain model objects from multiple Rails apps together via REST, and it actually works pretty well if you’re using vanilla ActiveRecord models and/or don’t mind doing your own XML serialization logic.

Unfortunately, the authors of said module appear to either a) not understand how SSL works, b) not really care or c) both. As implemented currently, the ActiveResource HTTP client will blindly accept any certificate presented to it, no matter who signed it. This is a Big Deal, at least for any apps using ARes across the firewall.

For those who don’t already grok SSL, here’s a shortened version:

Each site that wants to use SSL to protect traffic first generates a private key (which must be kept secret). They use that key to generate a public key encoded in a certificate-signing request (CSR), and then send that CSR to a certificate authority (CA). The CA signs the CSR using their own private key, and returns it as a finished SSL certificate.

At this point, the certificate serves two purposes: it provides a public key for others to use when encrypting traffic to and from the server, and it asserts that the entity bearing the certificate is the one named in its description. It is the responsibility of the CA to make sure that certificates are only issued to the right organization, which basically means that certificate authorities must themselves be very trustworthy indeed.

Clients connecting to a server using SSL ask for a copy of that server’s certificate before sending any sensitive data. Since the certificate is unforgeably signed by a single CA, the client can decide whether to trust the signing CA. If they do, they can then be reasonably safe in the assumption that the entity identified as the bearer of the certificate is who they say they are. (In most cases, this “entity” will be a simple hostname, like ‘mail.google.com’.)

If, on the other hand, the client does not trust the signing authority, there are two reasonable paths: it can allow the user to temporarily accept the certificate, or just reject the connection entirely. The former is a somewhat-common case for interactive applications like web browsers, but the latter usually makes more sense in a backend-systems case, since it’s better to fall back on secure defaults.

Now, the ActiveResource code takes yet another approach, which I consider unsound: it simply ignores the certificate error and continues with the connection as planned. This unfortunately means that anyone at all could claim to be a popular web service provider (think Twitter, or Campfire, or any of a thousand other popular APIs), and ActiveResource clients would simply accept that assertion and pass along user data without even logging an error.

Normally, I wouldn’t disclose a security issue like this on my blog before making every effort to make sure that the project maintainers had a chance to evaluate and patch the issue, but the current ActiveResource implementation actually goes out of its way to squelch any certificate-related errors. Given that, I suspect that this is really more a case of just needing to identify where ActiveResource is an appropriate solution.

Ignoring certificate verification may be fine and dandy for quick development work, and even within a trusted server subnet, but could easily burn you out on the wild world of the ‘net.

I’ve submitted a ticket and patch, so we’ll see what happens.