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:
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.