It’s been a little bit since we provided an update on Strip for Mac OS X and Windows and some folks have been asking, “what’s up?” We are submitting the 1.0 version of Strip to the Mac App Store, a universal binary, 32/64 bit. Keep your fingers crossed for approval and not rejection! This is one of the reasons why we don’t have a release date set yet, we need to get approval before we can realistically set one. It may turn out that changes will be required before we can publish it. Strip for Mac OS X requires you to be running Mac OS X 10.6 Snow Leopard or later (it is untested on Lion developer seeds).

We’re going all in with this Mac App Store for Strip, we won’t be distributing the app outside the Mac App Store. On the Windows side, we’re still working on our own purchasing system. There is no official Microsoft app store service for selling Windows software yet (would someone please light a fire under Uncle Fester’s derriere?), so we’ve had to do some work to set up our own purchasing and authorization system. Nothing too complex, but it’s work.

We’re also working on a major update to the product site for Strip, as the way it is currently set up isn’t quite inadequate for providing information on what are ostensibly two more products. Our merchant account provider for the Windows side isn’t cool with us launching the product without a supporting site, so we can’t just push it off until later.

All things considered, looks like we’re a couple of weeks out, as we’re juggling a couple of other things, too. Thanks for waiting on us!

By the way, if you have been thinking about buying Strip for iOS but have been leery of paying $9.99 just to try it out, we’re running a sale at the moment. For the time being, Strip for iOS is now available for $4.99 in the iTunes App Store.

Our time-tracking service Tempo will be undergoing some brief maintenance on Wednesday night at 9pm EDT. We don’t expect it to result in any noticeable downtime, although you might experience a blip. There’s a real gem in this update, we’ll begin using a new charting library that should greatly improve the display of charts on the reporting page. In particular, users who were reporting on a very high number of projects and/or users should find it quite a bit more useful.

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.

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.