Solipsism Gradient

This twitter thing can be a serious time sink if you’re not careful, but so far I like it. I’m even getting linkback from stuff I posted only there! (Thanks, Jeff.) But in retrospect, this is worth linking to directly: On the Effectiveness of Aluminium Foil Helmets: An Empirical Study. Jeff’s found the crucial quote, too:

The helmets amplify frequency bands that coincide with those allocated to the US government between 1.2 Ghz and 1.4 Ghz. According to the FCC, These bands are supposedly reserved for ”radio location” (ie, GPS), and other communications with satellites… The 2.6 Ghz band coincides with mobile phone technology. Though not affiliated by government, these bands are at the hands of multinational corporations.

It requires no stretch of the imagination to conclude that the current helmet craze is likely to have been propagated by the Government, possibly with the involvement of the FCC. We hope this report will encourage the paranoid community to develop improved helmet designs to avoid falling prey to these shortcomings.

Some years ago, when I needed to re-check my eyeglasses’ prescription, I found an article on the Internet about an optician – I think in Los Angeles – who was making special glasses for computer users. (I can’t find that URL anymore, unfortunately.)

Aside: my personal case is rather uncommon. I’ve always been nearsighted in the left eye (-4 to -5 diopters), while my right eye was normal. The left eye also has a slightly different color response, seeing things a little greener and darker than the right. Until my late 30s, both eyes had an overlapping range where both would focus well… starting at 30cm out and going to about 90cm (1 to 3 feet if you’re stuck in the imperial backwaters). Then, presbyopia set in and astigmatism became worse; my eyes’ focusing ranges no longer overlap at all, so I started needing different eyeglasses to work and to drive. (I still need no glasses to read with the left eye, at least.)

Anyway, having two different eyes taught me to be able to switch between them as needed and to tense and relax the eyeball voluntarily – call it manual focus. I hear this can be learned in a short time even if your eyes are equivalent.

So, the trick is to learn to relax your eyeballs, deliberately making stuff go out of focus. When you do that, you should see things at some distance between 4m and infinity in perfect focus. Next, you should measure your desired working distance to your screen; mine is exactly at arm’s length.

Now you go to the optician and do all the standard procedures, except that you’ll hold that small eyechart at arm’s length, or whatever your preferred distance is, and relax your eyeballs throughout – think of “idly gazing into the distance”. I find that the resulting diopters are about 0.25 to 0.5 stronger than they are for my driving glasses, but of course YMMV. Ideally this should also be done without any of those pesky dilating eyedrops, as you want your eyes to be as near to the normal state as possible.

If you did this correctly, you should be able to sit at your screen for hours without any eyestrain. Of course you still should get up and stretch every thirty minutes or so, unless you also have an “infinity focus” chair…

I seem to remember hearing that there are modern laser-based machines that measure your lens directly without having you read charts or whatever; I suppose that if you run into such a thing, you’d have to do the “relax” trick while this is done. Be sure to talk it over with your optician; mine needed some convincing the first time.

Update: this article about computer glasses confirms my experience. You may want to check other articles on that site for more up-to-date information about vision problems and corrections (especially if you’re based in the USA).

So, last August I switched over to the Lumix FX100 – great camera, if a bit noisy in the high-ISO shots. Then a few weeks ago the Lumix FX35 came out, with a wider lens angle and 30fps HD video, so I ordered one on the day it became available and found a buyer for the FX100.

Now, while the FX35 is still in transit, the Lumix FX500 is announced, with a better lens and larger LCD. Argh. In a couple of years I suppose we’ll have to just rent the camera du jour for a few days while a better one is shipping…

Then again, the FX500 won’t fit into the old, battered cellphone case I always walk around with, so I shouldn’t be too upset. Also, they haven’t yet implemented my ideal features; namely, an option for RAW storage, manual speed/aperture selection (correction: it does have that!), a way to override autofocusing, and a remote shutter release (for doing shake-free tripod shots).

Trying out this newfangled Twitter thing… hopefully it’ll mean faster updates on the latest memes.

So far, I like it. Took out a few hours to build a starting list of people to watch; it’s an oddly familiar neighborhood, of course, as it duplicates parts of my list of chat buddies, RSS feeds and so forth.

In a way it’s a slow-motion, somewhat less coherent, version of IRC. Which is actually a good thing.

Good extra argument against background processes from Craig Hockenberry:

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

Two interesting developments came up while I’m studying for my next post about code signing.

Firstly, every developer who has signed up for the $99/year program has gotten a letter which says, in part:

We have received your enrollment request. At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period. We will contact you again regarding your enrollment status at the appropriate time.

The message for non-US developers also mentions that the program will be implemented in the US first. At this point, some developers went off in a huff, interpreting it as a rejection, and numerous complaints and conspiracy theories have been aired. So far (as I know) nobody who applied to the $99 program has been formally accepted – the ones who said they were are apparently newbies interpreting their ability to download the SDK as “acceptance”. On the other hand, a handful of companies have stated they’ve been accepted into the $299 enterprise program.

Well, my understanding of English may be faulty (it’s only my fourth language, after all) but let’s look at the 3 sentences I quoted above:

We have received your enrollment request.

Nice of them to reply.

At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period.

This is just repeating what Steve Jobs said during the iPhone event… nobody would expect Apple to accept all applicants immediately and at the same time. There certainly are several thousands at the very least.

We will contact you again regarding your enrollment status at the appropriate time.

Meaning, as soon as we dig out from under, we’ll check your application. I see no problem there either.

Apparently, some people are indeed interpreting this as a poorly worded rejection, or at best as an ambiguous directive that you have to go to the end of the line or try again. Now, I’m the type of person who has difficulty in understanding the logic of “I’m afraid I’ll have to tell you that your credit card has been declined” – the first time I heard that in person I couldn’t follow at all (heh! he’s afraid of what? will he have to say what in some unspecified future? Why doesn’t he then say whatever he will have to say, then?) But I can’t see anything like that buried in that last line either.

Second item is that the SDK’s restriction on background process has been much-commented on, among others by John Gruber and Mike Ash. Along the way, there have been complaints about this and other restrictions imposed on third-party applications. Some have even pointed out (I can’t confirm or deny) that the APIs published in the SDK are just a small subset of the APIs ferreted out by people examining the previous iPhone firmware. Some commenters even seem to believe that Apple not publishing certain APIs is illegal in some way… witness the comments about unpublished APIs called by WebKit/Safari some weeks ago.

Well, Apple can certainly opt to tell people not to use certain APIs. In fact, on the Mac in the past, some large software publishers went ahead and used some of those “hidden” APIs anyway, with the result that Mac OS X still has to support lots of legacy calls that are broken, but can’t even be properly fixed without breaking those applications!

So, on the iPhone, they’re certainly making sure to avoid the legacy/unsupported/hidden API problem at all costs. Apparently the SDK license says that applications may not use any unpublished API, period. Note that this does NOT mean that Apple will have to examine your precious source code line-by-line; no, they’ll just run a tool that looks at your executable, sees what symbols in which frameworks are referenced, and produce a listing of whatever non-documented stuff you’re calling.

So, there are no documented APIs that let you run an application in the background, or start a background process. I’m sure we all agree that having any GUI application continue in the background after another GUI application starts will be too resource-hogging – after all, if you allow one, you have to allow any. From what I’ve read, no Apple application does that either; a few seem to have a background process or daemon running to take care of communications, but that’s of course much more lightweight.

I agree with Mike that obviously the iPhone OS does support multitasking in a generic way. I also agree that the relatively limited RAM (I heard that 64M are available to a third-party application) and CPU speed are no obstacles. To mention an even older example than he gives, I managed to write an embedded system running on a 4MHz Z80A CPU, with 32K of RAM, that handled a GUI, a foreground thread, and two background threads tracing several realtime signals on a screen.

But make no mistake, embedded systems are hard to keep responsive, even if you have no arbitrary code running at all. Apple apparently elected not to have full virtual memory swapping in the iPhone OS; here again, it’s not a limitation of the hardware (Flash memory can support swapping) or of the OS (it’s Unix-based after all) or of the CPU (it does have page tables etc.).

No, I think Apple simply is trying to keep “teh snappy” always happening, keep battery duration as high as possible, and avoid Flash RAM filling up by swapping. Also, swapping pages takes time and burns battery power. A wait of 2 or 3 seconds may be shrugged off if you sit at a desktop computer but may be unacceptable if you’re trying to answer a call on the iPhone.

Consider the MacBook Air with SSD. It has 64GB of flash and 2GB of RAM, with full swapping virtual memory of course. I’ve seen people leaving 20 or 30 applications running on a Mac and not noticing that their swap files grew to 12 or 20GB… but even that may already become a problem on the Air. I suppose Apple didn’t want to face telling people that they should leave 2 or 3GB free on their 8GB iPhone… and risk crashing or hanging when it suddenly fills up.

Still, I feel that if you do have a compelling application that absolutely depends on having a background process running, you’ll probably be able to ask Apple for an exemption… if you can prove that your process won’t hog the system. Also, Leopard (for one) has facilities to start processes on-demand – using launchd, you can have the system watch a certain port or socket and start up your process when data arrives there. No doubt we’ll see more such facilities being deployed.

Before getting to the actual discussion of code signing on the iPhone, here’s an interesting tidbit I discovered while researching details about Apple’s certificates: a PDF file detailing the iPhone certificate conditions – officially, it’s a CPS (“Certification Practice Statement”). This is publicly available, and linked to from Apple’s Root Certificate Authority page, by the way.

Some interesting parts:

This CPS is applicable to the following certificates issued by the WWDR Sub-CA:

? WWDR iPhone Software Development Certificates (“Development Certificates”)

? WWDR iPhone Software Submission Certificates (“Submission Certificates”)

? WWDR CRL Certificates (“CRL Certificates”)

That means, in order, certificates for testing an application on actual iPhone/iPod Touch hardware during development; for actuallly submitting an application for publishing on the App Store; and finally, for submitting a CRL (“Certificate Revocation List”). This shows that development and publishing keys are different, as I’d thought. It remains to be seen whether the publishing keys will be applied by developers themselves before submitting their apps, or (more likely) by Apple after verifying the apps for compliance. Also, CRLs are the technical explanation for Steve Jobs’ comment that “if [developers] write a malicious app we can track them down and tell their parents”… meaning, certificates can be revoked and those apps will cease to function.

No fees are charged for this service. Digital certificates are available at no additional cost to

members of the iPhone Developers? Program. Certificates are valid for the duration of the membership period unless otherwise revoked.

This clears up details about the $99 fee. This is an annual fee, then, for membership in the “iPhone Developer Program”, distinct from the “Mac Developer Program”. See the new http://developer.apple.com/ page, which is now split left/right between these two programs. The certificates themselves are free of charge. Elsewhere, expiration and renewal are discussed, but no actual expiration period is mentioned.

There doesn’t seem to be an equivalent document for signing Mac OS X applications, although a separate page says that you can apply to Apple for the purpose of getting your own root certificate recognized. The conditions (especially regarding auditing) appear to be much more stringent, so this looks to be directed at larger companies. Even so, there’s no fee for that either.

Mike Ash recently posted about code signing. We’d talked about the subject a few days before and that is a great summary of Mike’s thoughts about it.

Code signing on Mac OS X is still evolving, but with the release of the iPhone SDK, the subject is suddenly being thrust into the limelight. To quote the Wikipedia article:

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash.

In the past, code signing has been used on several platforms with differing intents and implementations; Microsoft, for instance, has a driver signing program that lets only Microsoft-certified device drivers run without warnings on Vista. In contrast, here’s a statement from an Apple engineer on the apple-cdsa mailing list:

Windows “code signing” is not only completely different in design and implementation, it also has a completely different *intent*. The Windows version tries to determine whether *Microsoft* thinks your program (or driver etc.) should be used. Mac OS X Code Signing is a general medium to let the manufacturer and user negotiate as to whether/how they want to trust each other, with the system providing the infrastructure to make this possible.

From what I’ve learned about the subject so far, the Mac OS X implementation seems indeed to be aimed in this direction – there’s very little documentation available. Even less is, of course, available for the iPhone OS implementation, and details are under NDA. But let me try to explain what I learned so far.

Mac OS X code signing is an implementation of the X.509 standard public key infrastructure. It depends on a cryptographical algorithm which gives reasonable assurance that signatures cannot be forged with currently wide-available technology. Of course that’s a rapidly moving target, and the twiddly mathematical details are beyond the scope of this post (and, in parts, of my poor brain too).

So, you can have signed executables (single binary files) and signed bundles (which can applications, frameworks, plug-ins and so forth). A signed bundle is easily distinguished by the presence of an extra “CodeResources” file inside the bundle’s Contents folder. This file is a XML file containing, among other data, a dictionary that contains a hash code for every file inside a bundle. It also has a list of “optional” files or folders; this allows you to remove things like unwanted localizations from an application without invalidating the signature. Of course, if you later re-add a localization its hash codes must match the one inside the file. Additionally, a signature is added to the bundle’s executable.

If you check Mac OS X’s system folder and applications, you’ll find that, beginning with Leopard, every framework, application and command-line tool is signed. This signature, by various convoluted means, is checkable (currently only by Apple’s codesign command-line tool). It also points back at Apple’s “root certificate“. This certificate is is a component in X.509’s chain of trust tree, which basically tells you which authorities certify that a particular signature is valid; in effect, when you reach the root of such a tree you have to decide whether the root certificate can be trusted. (X.509 also can be used for distributed, or peer-to-peer, trust networks.) Let’s see how you can check this in practice. Open Terminal and try this:

$ codesign -vvvv /Applications/Safari.app
/Applications/Safari.app: valid on disk
/Applications/Safari.app: satisfies its Designated Requirement

(as usual, type the line after the $ prompt and you should see the resulting lines.)

So this means that the Safari application is signed and its signature is intact. Otherwise, you’d get either a “code object is not signed” message, or if the signature has been tampered with, a “code or signature modified” message. Now let’s try a small variation on the command:

$ codesign -dvvvv /Applications/Safari.app
Executable=/Applications/Safari.app/Contents/MacOS/Safari
Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7621 flags=0x0(none) hashes=375+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=23
Sealed Resources rules=9 files=283
Internal requirements count=1 size=68

This gives more information. Specifically, we see that there are 3 “certification authorities” included into the signature, and that there is one “internal requirement”. To see this requirement, try:

$ codesign -dr- /Applications/Safari.app
Executable=/Applications/Safari.app/Contents/MacOS/Safari
host => anchor apple and identifier "com.apple.translate"
# designated => identifier "com.apple.Safari" and anchor apple

This is admittedly hard to wrap your neurons around. From what I understood, the “requirements” are actually a little language that establishes what conditions the signed bundle should satisfy. But satisfy to able to… what? Now there’s where everything is (on purpose) still a little vague. “anchor apple” apparently means that the basic requirement is that Apple’s root certificates be present and trusted. Open the Keychain Access utility, click on “certificates”, and you’ll see somewhere in the list a certificate called “Apple Root Certificate Authority”. You can double-click on it to see details.

But what is all this useful for? Your proverbial “Aunt Tillie” will certainly not be interested in typing commands into Terminal, following certificate chains, and reading up on trust audit procedures. Apple’s keychain software tries to make all that as transparent as possible. Simply logging into Mac OS X can open parts of the keychain, and when Aunt Tillie goes to her banking site, the bank’s certificate should be checked against the keychain’s certificates and with the issuing certification authority, and everything should “just work”. For that to be reliable, Safari’s code signature should also be checked – otherwise it could be hacked by some malicious entity to say that the bank’s site checks out OK even when it’s some phishing site masquerading as that bank!

Signatures and certificates are also checked by the parental control preference panel, by Mail when it receives signed e-mail, and so forth. You may be familiar with the dialog asking if a recently-updated application may access the keychain to store or retrieve passwords; for signed applications, this dialog will be issued only once. If a newly-installed update has the same signature as the previous version, which had already been authorized to access the keychain, it’s assumed to also be trusted to do so.

A similar scenario applies to critical code such as the codesign executable itself. Ideally, such code should refuse to run if it’s modified; Apple has some facilities already in place to do so, and even to detect if an executable ihas been modified while it’s already running by some malicious code injection. However, that sort of thing isn’t widely used yet; mostly because it would break certain facilities, like Input Managers, that people currently rely on.

One aspect I haven’t touched upon yet is the so-called “self-signed certificate”. This is a certificate which is its own root certificate, like the top certificates of the various ‘big” authorities. The difference is that these authorities are large companies that undergo serious auditions and verifications. As an example, Quay is currently self-signed; I’m still evaluating how to publish my certificate in a way that easily allows my users to check if new versions have indeed been signed by myself. Let’s run one of the same verifications on Quay:

$ codesign -dvvvv -r- /Applications/Quay.app
Executable=/Applications/Quay.app/Contents/MacOS/Quay
Identifier=net.brockerhoff.Quay
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20001 size=245 flags=0x300(kill,hard) hashes=6+3 location=embedded
Signature size=1671
Authority=Rainer Brockerhoff
Signed Time=Mar 8, 2008 08/03 22:28:09
Info.plist entries=14
Sealed Resources rules=4 files=18
host => anchor apple and identifier "com.apple.translate"
# designated => identifier "net.brockerhoff.Quay" and anchor leaf = H"4cbb97c74336f7ee6aa566122a5e7688e1c725dc"

See the difference? It shows only my name as authority, and a SHA1 hashcode at the end. I could publish this hashcode on my site and it would be not too difficult for a technically knowledgeable user to verify that his copy of Quay matches that.

What does this really mean? Actually, not too much. It means that two versions of Quay that give identical names and hashcodes, which additionally match the ones published on this site, giving reasonable assurance that the author of both versions and of the site are the same; but nothing at all beyond that. However, there are ways around that – SHA1 hashcodes can be duplicated with some effort, though perhaps not yet for certificates, and this site doesn’t have a secure (https) variant. A malicious person could easily strip away my code signatures, resign everything with a new self-signed certificate using my name, make a phishing site that looks like mine, and so forth, and to a normal user everything would appear to be OK. Would someone do that for a €7 utility program? Very probably not worth the trouble, but you can’t be sure.

Then again, I could invest in a secure site, an official certificate signed by a trusted authority – perhaps even by Apple itself – and all that would just make the code signature itself more reliable; it wouldn’t necessarily correspond to what extent the code itself can be trusted to always “do the right thing”.

As Mike points out, there’s a huge gap between “signed” and “trusted”. Ultimately you have to trust somebody, or you would be too scared to buy a box at a computer store and open it, much less connect that computer to the Internet or let your children touch it. If I buy a certificate from Apple, and use that to sign my code, you have to trust someone in the certificate chain even if my code seems to “just work”… it wouldn’t necessarily mean that Apple has audited and quadruple-checked my source code. Indeed, it doesn’t even touch the question of whether Apple as a company can be trusted!

All that is still largely theoretical; Mac OS X still runs unsigned code with no problem, even though with some small restrictions regarding use of the keychain, the firewall, and internet access as I mentioned above. But Apple engineers say that in the future code signing will become mandatory. In the next post, I’ll try to discuss the implications of that – especially regarding the upcoming iPhone OS 2.0, where it will be mandatory from the outset.