acb's technical journal


Functionally generating UIImage in Swift

When developing iOS apps, one often needs a simple UIImage, to use as a background or texture. Traditionally, the facilities for making these on the fly have been minimal to nonexistent, leaving one with two options: either (a) write code which allocates a memory buffer, fills it with pixel values, then does the CoreGraphics dance that turns it into a UIImage, or, more commonly, (b), hacks something up by hand in an image-editing program on one's computer and puts the PNG in the app bundle. The latter has the disadvantage of inflexibility (if the dimensions or colours need to change, it's back to laboriously hand-crafting a replacement image); the former, meanwhile, requires enough work to put one off, unless image generation is a central part of the app's value proposition. However, in the age of Swift, it doesn't have to be this way.

The Swift language, borrowing from functional programming, lends itself nicely to the making of labour-saving abstractions; pieces of code which implement the outline of a process, allowing the caller to provide only the code that does the specific details they want. (This has been, to a lesser extent, possible with Objective C since the addition of blocks, but Swift has further highlighted it.) In which case, it stands to reason that we should be able to do something like:

// make an 8-by-8 black-and-white checkerboard tile
let checkerboard = UIImage(width: 8, height: 8) { (x,y) in return Float(((x/4)+(y/4))%2)  }

Below the cut, I present a UIImage extension which allows you to do exactly this, as well as RGB and RGBI variants.


cocoa touch functional programming iOS swift uiimage 0


Dropbox for paranoiacs

Like many people, I have a Dropbox account; it comes in handy for sharing files with collaborators. However, Dropbox has one significant problem: that of trust. It is a closed-source program, running a proprietary protocol; the user has no means of verifying its operation or its security, and thus using it is giving an opaque program access to one's system, and having faith that (a) it only does what it says it does (i.e., synchronising a directory tree of files between machines), (b) it cannot be quietly subverted by its creators to do other things without one's consent, and (c) it has no security holes that a third party could exploit to pwn all your stuff.

Other people have noticed this as well, and there are several existing articles on ways of compartmentalising Dropbox on a Linux system. These articles generally rely on running it in a chroot jail, restricting its filesystem access to an isolated subtree. The problem with this is that chroot is a thin layer of defense against an untrusted application; it only restricts access to the filesystem, and there have been ways to break out of it; if an attacker can get root privilege, they can get out. In short, trusting chroot to secure an untrusted application is a leap of faith.

Fortunately, chroot is not the only possibility these days; with improving CPU performance and the falling cost of RAM, a moderately powerful computer has enough power to run several virtual machines, each one running its own isolated operating system. These can be run using the freely available VirtualBox application, which is able to run its virtual machines in headless mode. In other words, it is possible to devote a small amount of memory, disk space and CPU power to simulating a small dedicated Linux box dedicated to running a Dropbox client. This box can run a NFS server, through which you can access your Dropbox files from your main machine as if they were stored locally. And, should the Dropbox client turn out to be, or be compromised by, malware, it has access to literally nothing more than a freshly-installed Linux box running itself.

The process has multiple stages: one will need to create a virtual machine, install Linux on it, install the Dropbox client (and configure it to connect to one's account), set up networking and NFS to get at one's files, and configure the host system to automatically start the virtual machine at boot time. In my example, I am using the Debian Linux distribution (in particular, Debian Jessie 8.2.0); the instructions will differ for other distributions.


dropbox linux security virtualbox 0

This will be the comment popup.
Post a reply
Display name:

Your comment:

Please enter the text in the image above here: