A Capitalistic Fix for America's Broken Immigration System?

Immigration in America is broken. There is no way to sugarcoat it, unfortunately. Failure of the administration to separate legal and illegal immigration concerns and to treat the politics of both as distinct from each other is jeopardizing the future of America.

There are several articles, memos and blog posts which articulate what is wrong in a lot of detail, so I won't repeat those. To illustrate the problem though, here is a short blurb about my own situation.

I have been a legal immigrant in America since I arrived to study Computer Science at the University of Texas at Austin in 2000. I graduated with a BS in Computer Science, interned at National Instruments for many months and went on to work at Microsoft for several years. I now work at a software startup. I'm a legal resident alien, but I'm still awaiting my permanent resident card ("green card"). I've been in the US for over 11 years now. I pay my taxes (TurboTax computes that ~16% of all income I've earned over the last 10 years has gone towards taxes, and this doesn't include local sales taxes), I occasionally speed on freeways and get pulled over, I spend money to stimulate the local economy (Mint.com says I spend ~2.5x what the average American my age spends), I eat junk food, I save money for retirement and invest it in American companies, I volunteer at a local high school, I support the Texas Longhorns and the Seattle Seahawks, I drink a lot of coffee, I donate to local and international causes, I whine about the weather... basically, I do what most average Americans do. I have a decent life here in America, and I'm thankful for it. But, barring any change in legislation, the estimated date for my green card being issued is 2024. Yep, that's not a typo. If nothing changes, I will get my green card 24 years after I legally entered the United States of America. Not citizenship, just permanent residence!

I assume I don't need to explain to any reasonable person how ridiculous and ironic this situation is, given that American was built by immigrants. I won't get into how my personal and professional life are impacted by this silly situation. Instead, I want to propose a possible solution, one that I haven't heard mentioned previously.

What if one of the criteria for issuing a green card was - if your stay in America has been legal and you have paid more in federal+local taxes than the average American pays over his/her entire lifetime then your green card application should be fast-tracked.

If this sounds too simple, it's because it is -a simple, capitalist, pragmatic approach to immigration. This rule ensures that prospective immigrants enter America using legal means and remain legal, that they are employable and have documented income that is in line with or exceeds that of average Americans, that they will not be a burden to society but an asset and that they have an incentive to contribute to the success of their adopted nation.

Thoughts?

Unfortunately, immigration reform is a political issue instead of a practical one, and a solution to legal immigration doesn't seem possible without a solution to illegal immigration (which just baffles me - anyone know why the two are joined at the hip?). America and Americans will eventually have to suffer the consequences of such nearsightedness, I fear. Illegal immigration is a political minefield though, so I don't have much hope for any real reform anytime soon, but then again... "hope and change", right?

Some Notes on Implementing In-App Billing on Android

About a year ago, I implemented in-app payments for iOS, and it was painful. Technically, it wasn't too hard but there were a number of hoops to jump though to get everything working. Lack of clear documentation and undocumented error responses seemed to be the primary problem - I think a hold up with verifying tax information on the developer account resulted in strange, undocumented failure codes in my case. There were several dozen blog posts complaining about many such "magic" issues back then. It was almost comical, to be honest.

This last weekend, I decided to add in-app billing to an app that's already shipping for Android, and I ran into a couple of hiccups that I think are worth documenting here to save others some time/pain. Overall, I think the Android folks learnt from some of the pitfalls that early developers hit with in-app payments on iOS and worked to fix those. The documentation is a lot clearer and precise compared to where iOS was a year ago. Android Market also has a nifty static test/response facility which makes it easy to test code without worrying about external influences. iOS was desperately lacking something of this sort (not sure if it's better now) - I even wrote a dummy implementation of the iOS in-app payment API and the different response conditions to let me test my code in an emulator, which was really helpful. I'm glad Android got this right (still no testing in an emulator though, which is a bummer because of the inability to test with different Android OS versions).

At a high level, the in-app billing protocol on Android is extremely chatty (see the diagrams on this page). It seems particularly so when compared to PayPal's rival offering. PayPal's in-app billing module handles payment using startActivityForResult and onActivityResult methods which can be used for communicating between child/parent activities. This is very similar to how Facebook's Android SDK handles single sign on. That model is extremely simple to understand and implement for developers - you could probably have it coded up and tested faster than you can finish reading this blog post. I think part of this chattiness is to ensure a higher level of security and also to handle managed purchases, which are both likely harder to do using PayPal's approach. I assume they had good reason to make it as chatty as it is now, but my gut says that Google loses out on a lot of developers because of this apparent complexity. Having said that, the sample application Google provides does a really good job of illustrating the various communications that need to occur, so studying that code makes the chattiness easier to understand (for some reason, code registers more easily in my brain than verbose documentation - good code and good documentation together are very rare, and Android seems to have gotten this right - kudos!)

One of the biggest red flags with using Android's in-app billing, however, is the development teams non-responsiveness to critical bugs. This issue, marked critical and accepted, talks about transactions failing 4-6% of the time, and has been active for over two months without an owner being assigned. An equally disturbing issue with unacceptably long latency when handling authorization has been open for almost two months without any comment from Google or even an owner being assigned. In fact, browsing the issues list certainly doesn't inspire confidence in the platform. It would be a big mistake by Google to not take these issues seriously. In my case, I'm certainly debating the merit of jumping into this as an early adopter.

Some other notes about implementing in-app billing on Android:

• It sounds obvious in hindsight, but you need to make sure that your application is signed with the release key before testing in-app billing, even the static response stuff. Developer's aren't used to doing this while debugging, so it's worth calling out in the documentation.

• If you want valid signatures for the JSON responses as suggested by the table here, the "debuggable" attribute in the app manifest should be set to false, even if you're using a release-key-signed APK and static responses. I was a little annoyed by this un-documented restriction because it basically meant that I had to resort to using logging as the only real means of debugging my code. If there is indeed some way to debug this using a debugger (and yet receive valid signatures), it’s definitely not obvious to me. Again, not a terribly big deal once you realize that this attribute actually seems to affect signatures, but that isn't documented anywhere.

• If you're using a server to validate signatures (as you should), be aware that the public key you obtain from the Android Market profile page is a base-64 encoded string. You will almost certainly need to convert it to PEM/DER format or use the x509 certificate for it to be usable with most server openssl implementations. For instance, this command can be used to convert the base-64 encoded key into a key usable by PHP:

  openssl enc -base64 -d -in publickey.base64 -A | openssl rsa -inform DER -pubin > publickey.pem

  Also, if you're using the PHP function openssl_verify, remember that $signature needs to be the binary signature, not the base-64 encoded signature string that the Android Market app sends (I found out the long way).

• Unavailability of subscriptions/auto-billing is a big gap in the offering currently, but I assume support for it is coming soon, since iOS already supports it.

• I hit an issue when testing payments using carrier billing, where accepting the carrier ToS basically causes the transaction to get lost somewhere between the carrier and Android Market. I logged this bug to track the issue.

Well, I hope that the web-search spiders do their job and this post helps others out there looking at implementing in-app billing on Android. And making Google get a move on those bugs.

Discuss this post on Hacker News