iOS Security Overview

I recently read Apple's iOS security overview which outlines the various security measures present on iOS devices.

It's a fairly short read at under 20 pages and it's great stuff to familiarize yourself with if you're developing on the platform. Here is a summary / some limited thoughts (I don't know much about security):

• A lot of Apple's security measures are possible due to novel hardware solutions
• The ARM processor's Execute Never which marks pages as non-executable
• AES 256 crypto engine and SHA-1 are built into the file system and implemented in hardware, which drastically reduces the overhead of encrypting everything
• Novel ways of wiping sensitive data that would otherwise linger in flash memory
• UIDs are not readable by software or firmware, yet still used as input to crypto

A lock inside a lock inside a lock

• The file system encryption is of an onion nature
• File metadata is not available all the time. This is to restrict access when the device is locked or interrupted by a phone call, etc. and availability rules are described by a files' class
• File metadata is encrypted. The file data itself is encrypted too, and that key is only available after decrypting the file metadata (that's right, each file has its own key)
• Did I mention that the file class which points to the file's metadata is also encrypted? See image above
• It's fast to remote wipe your device: just destroy the top level keys and nothing else on the filesystem is accessible
• Every encryption/security algorithm I've heard of is deployed here (ok not ROT13):
• Address space layout randomization
• Lots of certificates to authenticate trusted code
• Asymmetric elliptic curve cryptography (Curve25519)
• Yarrow
• PBKDF2
• SSL, VPN, etc.
• AES and SHA-1
• escalating time delays: it'd take years to brute force a short password
• I don't understand keybags yet
• My eyes glazed over and it sounds too similar to teabags

"We have a false model of what thinking is"

This is a tasty excerpt from a great interview with David Graeber:

We have a false model of what thinking is. Because you can't really think by yourself, can you? You have to create someone else in your mind to explain things to, and to have an imaginary conversation with. This idea was inspired in part by the philosopher of cybernetics, Andy Clark, who proposed something he calls the extended mind hypothesis. Basically, the argument goes like this: Say you're doing long division on a piece of paper instead of doing it in your head. Clark asks why the piece of paper is not just as much a part of your mind while you're doing that calculation as the part of your brain that's doing the math. He says there's no reason at all.There are a million similar examples that philosophers like to trundle out—you have a bad memory so you write everything down. Is that piece of paper then part of your mind?

"Mind" isn't "brain"— the brain is just an organ; your mind is the dynamic interaction of various moving elements that culminates in thought. Philosophers like Clark are willing to take that argument this far, but the question that never seems to occur to them is this: when you're having a conversation with someone else, is their mind part of your mind? Nowadays, many philosophers of consciousness like to note just how razor-thin this thing we call "consciousness", that self-aware part of our mental operations, really is. The average person can rarely hold a thought for more than three or four seconds, eight at the most, before the mind wanders. It's very unusual to be fully conscious for more than a tiny window of time. That is, unless you're having a conversation with someone else, in which case you can often do it for long periods of time, especially if the conversation is with someone you find particularly interesting. In other words, most of the time we're conscious is when we're talking to someone else, or otherwise interacting intensely; during moments in which when we're not clear whose mind is whose. So consciousness is interactive, it's dyadic or triadic. It's a fallacy to imagine that thinking is something you largely do alone. On some level, of course, we already know that. But I don't think we've even begun to explore the full implications.

error: unknown warning group

I try and write about really frustrating issues that I manage to figure out or interesting problems that I solve in hopes that it will help other poor developer souls who would otherwise be without a guiding light. Here's an Xcode-inspired episode of the former.

I decided to see what would happen if we moved our iOS project to Xcode 4.3 and it nearly went without a hitch except that I spent several hours trying to figure out why our rake scripts weren't working.

...actually let me back up a step and describe a couple of tools we use.

We use Cedar to run automated tests ("Specs" to follow the parlance of rspec), and one Cool Thing is that they can be run in Xcode or from the command line using rake.

Another Cool Thing, or at least a Thing That Used To Be Cool Before Upgrading Xcode, was our use of PivotalCoreKit to make spec writing more convenient.

PivotalCoreKit uses (abuses?) the dynamic-ness of Objective-C categories to override existing class behavior and suppress NSUrl from making an actual network connection, for example. The advent of 4.3 discourages this sort of flippancy and will issue a warning/error by default, which the newest commit of PivotalCoreKit suppresses with pragma preprocessor macros.

Now is where the wonkiness really starts. Running our specs from Xcode went swimmingly after updating PivotalCoreKit, but building the same spec target from the command line would fail with errors such as:

Externals/PivotalCoreKit/SpecHelperLib/Extensions/UIWebView+Spec.m:4:34: error: unknown warning group '-Wobjc-protocol-method-implementation', ignored [-Werror,-Wunknown-pragmas,2]
 #pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation"

What the heck??? They are the same target!

But after comparing the build outputs of Xcode 4.3 and the command line spec script, they were drastically different. For one, I could not get the command line to compile with SDK 5.1. Despite my various environment variable tweaks, the -isysroot parameter pointed firmly at yesterday's SDK.

Here's how I (eventually) fixed it:

• I ran

  xcodebuild -version

  and found out I was *still* on Xcode 4.2 (I had decided not to delete it yet)!


• I warily installed the latest command line tools (Apple: "The command-line tools are not bundled with Xcode 4.3 by default. Instead, they can be installed optionally using the Components tab of the Downloads preferences panel")


• After installing the latest command line tools I was still on 4.2. After digging in /usr/bin/ to ensure that xcodebuild had in fact been updated, I serendipitously discovered

  xcode-select

  ...



• sudo xcode-select -switch /Applications/Xcode.app/




• xcodebuild -version

  is now 4.3!!


• All is well is command line specs land

So here I am 4 hours later to administer the following advice:
--Delete old versions of Xcode when installing the latest if possible
--Otherwise, remember always: xcode-select -version

This weekend was one well spent as I participated in Music Hack Day SF for the first time.

I initially partnered with Kelly Dunn, who has been working on a project to send OSC messages triggered by Sifteo cube user interaction events (more here: Siftosc).

From 2pm on, we toyed with the idea of creating an air drum setup, which treats the cubes as shakers or drum sticks, using Renoise's built-in OSC server. Ultimately this didn't pan out since we weren't able to trigger note events without preprogramming a beat into Renoise, but Kelly did get the shaker implementation working and went on to do a crazy hack where he used the Sifteo cubes to manipulate his monome controller .

I moved on to experimenting with PureData on iOS with libpd a good 3-4 hours later. I got a basic grid-based synth working, but was unhappy with the sound quality on the iPhone simulator, which is a known issue with libpd. I learned a lot about puredata and could have potentially demoed the app despite its annoying distortion issues, but since I didn't have a device to deploy to and it was still before midnight on the first day, I decided to start over with something else.

Looking for examples of manipulating microphone input on iOS, I found aurioTouch, a powerful demo app created by Apple to showcase audio processing with the microphone. I started tinkering with this but was starting to feel fatigued from wrangling libpd and wanted to move on from audio low level synthesis.

I took an hour break and decided to work on a zany, assuredly demo-able project.

Enter sideTrack. It's a Rube Goldberg-esque python script which leverages many different APIs to mutate an initial seed song many times over until it eventually plays a completely unpredictable song, while speaking the nonsensical phrases it uses to perform each search.

Similarly to how one might fall down a wikipedia hole, this python script uses random lyrics, geography, song titles and more to repeatedly mutate different searches into a track with a spotify url, which is finally played via AppleScript after exceeding a depth limit parameter.

It leverages APIs from MusiXMatch, EchoNest, Spotify, and google maps to mutate the songs at each depth level. It worked and the results were always surprising. I was grateful to receive generous prizes from spotify and 3scale.

Here's a screen cap of sideTrack:


Regardless of frustration from my numerous aborted project ideas, music hack day was a ton of fun. I met some very talented and passionate folks, and eagerly await the next music hackathon.

brief notes from graeber talk

30% of the world's mined gold exists underground Manhattan, and you can take tours!
"You can tour the trading rooms, the museum and the Fed's vault, which holds 900 tons of gold."

In many ways, war gave rise to capitalism and not vice versa.

Modern coinage and money arose largely out of the enormous challenge of feeding and paying a medieval army.

Kings would print money and distribute it to their populace, then ask for some of it back. Markets arose out of the need to pay this tax, and it benefitted soldiers who had lots of spending power. So it was governments creating the markets, not regulating them once they'd come to fruition.

Additionally, it was unwise to do business with armed passerbys with IOUs, so cash was the logical material of exchange, especially since the soldiers had most likely recently looted some gold/silver/whatever on their way to visit your humble market.

Precise exchange rates were born of violence, for instance to stem a blood feud, exact legal damages were conferred, and substitutions were made when necessary. Otherwise, most trades were conducted with rough equivalency, with shame or death as a possible punishment for underhanded-ness.

Also the anarchism of Barcelona

also the war debt that is circulating from the king of england and the british bank notes that act as IOUs

The power and insanity of C++ templates

exhibit 12941b: analog literals


it is possible for this to compile as valid c++ code:

  assert( ( o-------------o
            |L             \
            | L             \
            |  L             \
            |   o-------------o
            |   !             !
            !   !             !
            o   |             !
             L  |             !
              L |             !
               L|             !
                o-------------o ).volume == ( o-------------o
                                              |             !
                                              !             !
                                              !             !
                                              o-------------o ).area * int(I-------------I) );

here's more: analog literals
still more: yep, they're turing complete

why, bjorne, why?

Don't use defaultCStringEncoding

It isn't exactly news that this innocuous-sounding parameter is "considered harmful."
But this fact needs a bit more SEO-juice, so here's another voice speaking out against defaultCStringEncoding:

(from NSString.h):

/* User-dependent encoding who value is derived from user's default language 
and potentially other factors. The use of this encoding might sometimes be needed
 when interpreting user documents with unknown encodings, in the absence of other hints.  
This encoding should be used rarely, if at all.  Note that some potential values 
here might result in unexpected encoding conversions of even fairly straightforward 
NSString content --- for instance, punctuation characters with a bidirectional encoding.
*/
+ (NSStringEncoding)defaultCStringEncoding; //Should be rarely used