I believe it was a couple of years ago that I first met Nate Freitas at No↔Space co-working here in Brooklyn (née The Change You Want To See). He was working on ideas to help enable and protect communications amongst fellow activists, and I took an instant liking to him—this was a trouble maker! I mentioned our SQLCipher project to him, it was still pretty new in 2008, and he was immediately interested in being able to use it in Android applications. Since then he’s gone on to help found the Guardian Project, which aims to arm and protect mobile devices against unwanted surveillance and intrusion. Recently, he got back in touch with some big news:

After some major breakthroughs during last week’s development sprint, we’re extremely excited to announce SQLCipher for Android, Developer Preview r1.

SQLCipher is already on mobile devices on other platforms, but this is the first time it’s been made easily accessible for an Android developer, bringing compatibility with the native SQLite interfaces provided by Android. I’d say that probably makes it even easier to work with on Android than on iOS, as it closely integrates cursors with views (in Cocoa-land, you can’t just plug SQLCipher into Core Data, you have to role your own data management classes). Our teammate Erik was able to easily drop it into a sample Android project and get it working in no time.

In an environment where mobile data privacy is increasingly in the headlines, this project will make it easier than ever for mobile developers to properly secure their local application data, and in turn better protect the privacy of their users. The data stored by Android apps protected by this type of encryption will be less vulnerable to access by malicious apps, protected in case of device loss or theft, and highly resistant to mobile data forensics tools that are increasingly used to mass copy a mobile device during routine traffic stops.

Big ups to Hans-Christian Lee of Guardian who did brilliant work achieving this high level of integration with the Android platform. Please check out the Guardian Project and their apps, especially if you own an Android device. If you’re a hacker, give the developer preview a shot, and consider helping them hack on some seriously cool software.

Recently, we had a query on the SQLCipher Users’ mailing list inquiring about the performance of a LIKE query, where the user was wondering if SQLCipher’s encryption engine was responsible for poor performance he was seeing in his code. “It depends,” is the cheapest and most accurate answer we could give without seeing his query and the EXPLAIN plan generated by SQLite (no index, for instance, could lead to a full table scan, thus requiring every page to be decrypted). What we do know is that performance of SQLCipher compared to SQLite is really pretty good, and certainly good enough for our needs as application developers.

If you’ve been wondering what kind of performance hit you can expect using SQLCipher as compared to vanilla-SQLite, we’ve published a new tool to help you get an idea. In the end,EXPLAIN and EXPLAIN QUERY PLAN cannot be replaced, but for a quick side-by-side reference to see that we’ve done a half-decent job, check out Stephen’s SQLCipherSpeed. It’s an iPhone OS project that rips through the various SQLite speed tests. I ran it on my crunky iPhone 3G and the results were about what I expected, and pretty interesting:

In this next one, note that there is no performance impact for 2500 selects on an index.

You’re highly encourage to check out the code yourself, and to fork it. It would be really cool if someone added an action button to the results screen to email the data off-device. More tests wouldn’t hurt either.

Apple has informed us that Strip 1.5.2 has been approved, so we’re releasing it this morning, it should be available in the iTunes App Store by the time this post goes live. As previously communicated, this release removes the In-App upgrading service and reverts Strip to a paid-only application. All existing customers should upgrade, it’s free. Please let us know if you see any issues.

Updated: 6/6/2012 This blog post is out of date, and the software referenced in it, Strip Sync, has been discontinued in favor of Strip for Windows and Strip for OS X. For more information on our data export format, please see this newer blog post.

Strip Sync is a free tool we distribute for customers of our password manager, Strip. It’s a kind of hold-over until we’ve got a proper desktop port of Strip that provides some basic but necessary capabilities, in particular the ability to bulk import your data (say, from another program or source), and to export your data (so you can print a hard copy to store in a safe, or so you can move off Strip someday).

The import and export files are CSV files. That is, plain-text files structured in a particular way, that can be opened in a spreadsheet programs like Excel. A good many people out there are familiar with spreadsheet programs, but Excel has some issues when it comes to opening a CSV file and displaying the data correctly:

• UTF-8 is not supported when opening a CSV, ASCII is assumed, so international characters turn into garbage.
• Leading zeros on numbers like PINs and postal codes are lopped off.

Our international customers, being quite fond of their umlauts, have written us a few times about the first problem, one that MSFT does not appear poised to fix this century. The second issue can be a real nuisance if you have a column like “Zip Code”. Excel always assumes such data is a Number (even if it’s wrapped in double-quotes), and if you format the column as Text after you’ve already opened it, the zeros have already been lopped off. Obviously, this isn’t a show-stopper, but it’s not appropriate for printing a hard copy of your secret keys for safe storage.

Looking for another work-around, I tried using Excel’s “Get External Data” wizard to import the text from a CSV, but it doesn’t respect line-breaks in quoted text fields, so even though you can mark your Zip Code column as text on the way in, the rest of your spreadsheet gets wildly munged by any line-breaks you might have in a note field.

This morning I fired up Open Office.org for the first time in a long while to see how it’s spreadsheet program Calc handles this, and it’s just the thing for our customers. Did I mention that it’s free? Here’s how it went down: I exported from Strip Sync, I right-clicked on the file, selected OpenOffice.org, tweaked some settings on the dialog panel that came up, and I was in business.

Step-by-step

First, right-click (or control-click) on the export file, and instead of opening it with Excel, go with OpenOffice.org.

When the Text Import dialog pops up, take a look at the Separator Options: the only one you should check off is Comma. Make sure Text Delimiter is set to straight double-quote (“).

Next take a close look at the Fields listing, and scroll over to any column that contains numeric data that you don’t want munged, e.g. PIN, or Zip Code, etc. Select the column header, and choose Text from the Column Type pop-up to ensure that leading zeros won’t be lopped off.

Then open it up, you’re all set! You get to keep those leading zeros.

From here you can manipulate and format the spreadsheet for printing however you like, or you can export it to a native Excel workbook format if you prefer to work in Excel. Excel does support UTF-8 characters, just not when opening a CSV file.

Updated, below: Apr 18 10:00 AM

On March 1st, we released Strip 1.5.0, largely a pretty successful release with a low number of bugs, crashes, and some big improvements that were long over-due. However, in that same release, we started using Apple’s In-App Purchasing system, and it’s caused a lot of confusion and frustration for our current customers. That’s really the last thing we wanted to do, as our customers are particularly great, so this post is about what happened, what we’ve done so far to fix it, and what comes next.

The Issue At Hand

Thousands of people have already paid the full price for Strip, $9.99 USD. We wanted to make sure that when they upgraded, they weren’t charged again by the new In-App Purchasing system in Strip 1.5.0. To ensure this, the program looked for a previous install on first launch, and made sure not to ask the customer to pay for an upgrade, which worked—on the upgraded device.

It didn’t prevent users from being charged for the new version on new or replacement devices where the old version of Strip wasn’t already available on the device for detection by the new version. Thus, anyone upgrading to a new device, doing a restore, replacing a device, or buying a new device was faced with being charged a second time, because they no longer had the old version on the device in question and could only download the new version. To make it worse, there appears to be no way for us to remedy this with the App Store and the In-App Purchase system as provided by Apple.

To add to the confusion, purchases made once in the iTunes store don’t have to be made again on the same account, they are free, but the iTunes store still presents it as a purchase until you agree to pony up the cash. Only then does it inform you that you get the new download for free, so you’re always trying your luck. But the In-App Purchase for Strip is considered a different “Product” in the iTunes App Store, and buying the old version didn’t make the new version free on a new device. Many users in this situation confirmed the purchase when prompted, expecting it to be free thanks to their previous purchase experiences, and were charged anyway. To these folks, it looked like we’d performed a bait-and-switch (or just screwed up).

What We’ve Done So Far

Answering everyone’s email and getting to the bottom of the various problems wasn’t going to be enough, so we got to coding.

We published Strip 1.5.1 to the iTunes App Store on Monday, April 4th. It fixes a couple of bugs in 1.5.0 (thus the delay in getting it out), so we recommend you install it now. This version has a facility allowing us to remotely grant a user unlimited access to Strip on their device. When a customer gets in touch and it turns out she has or will be double-charged, we can put their UDID in a remote database and give her a couple of steps to perform in Strip to cause a remote HTTP request to check with a little web service we set up for authorizing instances of Strip.

Back to Paid Downloads

We will be publishing Strip 1.5.2 as soon as it’s approved by Apple (we’ve already submitted it for review to the App Store). It contains a one-line adjustment to disable the in-app upgrade completely, and we’re going back to what works: $9.99 to download, no more screwing around. Anybody who upgrades won’t be charged for the download.

We’re really grateful to our customers for being so patient with us while we worked through all the email and got back to everybody. If you are currently in a pickle yourself, get in touch, and we’ll pull you out of the brine. We’ll post a note here and to the mailing list once Strip 1.5.2 is available for download.

Update: Strip 1.5.2 is now available in the iTunes App Store, all customers are advised to install this update.