Sep 21, 2017

Back to Apps

For about two years, I take some time off and adventure into a different world of PHP, Node JS, Spring Boot, and Vue. With only a handful of updates to my apps from time to time, I keep an eye on the iOS ecosystem with a little bit of distance.

The recent iOS 11 update has been a wake up call. Some of my apps don't work any more after the update. Should we just let them turn into zoombies before they are deleted and forgotten? As long as we have some faithful users out there, it's hard to abandon them. So I think it's time to get back to the apps. There is nothing cool about app development these days, but it's always given me great satisfaction to serve power users. This time, I hope we can find a sustainable way to stay on it.

Oct 27, 2015

A Not-That-Great Update of iDOS

As you may know, iDOS has been crashing on iOS9. We tried to submit a fix one month ago, but then we had a hard time getting it through the time-consuming review process. In the end, we had to turn off every possible way to access the file system inside this app, specifically, both iTunes file sharing and file import are prohibited. If you are a long time user, you know that these features are badly needed since the release of iOS 8.4. Unfortunately this is the only choice we have if we want to have a usable iDOS release in appstore.

For every user who has already installed one copy before, don't update until you upload everything you need to this app. It's recommended that you save the IPA package in iTunes to somewhere.

To compensate for the loss, we also offer beta versions to paid users. These releases may include beta features that are unavailable in the official app store release. Please send your request to, preferably with a receipt of your purchase. Slots are limited, therefore first come first served.

App Store Link: iDOS 2

Sep 25, 2015

TeX Writer Update for iOS 9

Today TeX Writer update with the bluetooth keyboard fix is available. We have to apologize for the delay. Last time we tried, Apple wasn't ready to accept iOS 9 builds. Then we sort of took a nap, and when we woke up, it's already very late in the game. Thanks for bearing with the inconvenience during the wait.

A quick fix of iDOS2 is also on the way. But a more thorough fix will have to wait because the incompatibility issue is so tough that we have to spend more time on it.

May 18, 2015

A Quest for Syncable Private Online Storage

It's necessary for apps to sync data, either documents or preferences, among our devices. Syncable means that modifications made on one device must be transferred to other devices swiftly. Private means that data must be encrypted with a user provided key before upload to server, so that neither cloud provider nor app developer can look inside your documents.

These requirements seem to contradict each other. Encrypted data is extremely expensive to sync. Even if you just change one byte, newly encrypted data will be entirely different, therefore a full syncing will have to copy every byte. However, if we design the storage file to be append-only, and use a stream cipher instead, then our goal can be met.

An append-only file is opened for reading and writing, only that the writing always happens at the end of file. For C programmers, such a file is opened in this way:

fopen("datafile", "a+");

Since it's append only, it's easy to sync by comparing file size and only downloading the missing data at the end, and another benefit is that your data will never get corrupted. When things go wrong, we can simply revert to earlier versions. Stream cipher encrypts data on the fly as they are being appended. There is no need to re-encrypt whole file from the start. Effectively we also have an encryptable version control storage.

The problem of append only data storage is that, unlike usual database systems, we need to build an external index file for fast queries. The external index file has to be built on first time load, and always be updated whenever there is new data coming in. It can also be encrypted so even if other people get access to your device, your index file is still safe.

Normally a remote server is required to help devices sync with each other. The server only has meta information, for example, size of the data file, timestamps of updates from clients. It can do some basic conflict resolution. When a client tries to push or append new data, the server requires the client to provide its local head position (same as file size) and checksum. If client head position is not equal to the head at server, then the server will reject updates from the client. The client should catch up with the server head position first, by downloading missing data and doing conflict resolution locally. Since the server has no idea of the contents, keeping the content in proper status is at the discretion of all clients. A badly behaving client could post garbage data to the server. Even in such case, we can still revert data to earlier versions, and revoke access permission for those bad clients if necessary.

Like git, clients have full copy of data. Therefore they can switch to another remote storage provider at will.

Data syncing can also be peer-to-peer. Two different local storages can negotiate a common head position by exchanging checksums of different portions of data, and then try to merge their differences after that.

Going forward, this is how app developers should protect private data of users, and this is how we can completely close any possible backdoors to user data, yet still provide convenience of fast syncing.

Mar 20, 2015

Trusted Cloud Computing

We all know non-public data on the cloud servers should be encrypted. What if data has to be processed right on the servers? Data processing programs need to know about the encryption key, however, we must only hand over the key to programs that we can trust. Trusted programs are those we can build from source, that means that we can embed one-time-use secrets to them. Every time when we want to run a program on server, a different executable copy with different secrets is uploaded to server, and server should launch it as soon as possible. The running program has to answer questions correctly, and shortly (to protect against secrets being reverse engineered), before we can send over the data access key. A trusted program must keep the key only in memory, never write the key to disk, and should hide or destroy the key after use. If it's restarted, it will have to ask for the key again, then we will know something is wrong. Open source programs are easier to be reverse engineered, therefore we must add secrets to it in an obfuscated way to make sure secrets can not be revealed by an attacker in a short time. Depending on security measures, the access key must be invalidated or the data should be removed after a certain period.