Solipsism Gradient

In keeping with recent meteorological themes – iCloud, Thunderbolt – yesterday Apple introduced the new “Lightning” connector for its mobile hardware. This will be the replacement for the venerable 30-pin dock connector introduced 9 years ago. I haven’t seen it in person yet, but here’s some speculation on how it may work.

First, here’s a composite image of the plug and of the new connector (which is, apparently, codenamed “hero”):

You can see that there are 8 pins and that the plug has a metallic tip which, from all accounts, serves as the neutral/return/ground. Since the plug is described as “reversible”, the same 8 pins are present on the other side and, internally to the shell, connected to the same wires. However inside the connector you can clearly see that the mating pins exists on one side only – presumably to reduce the internal height of the connector by a millimeter or two, at the expense of slightly better reliability and a doubled current capacity.

There are locking springs on the side of the connector that mate with the cavities on the plug, hold it in place, and serve as the ground terminal. The ground is connected before the signal pins to protect against static and the rounded metal at the tip (from the photos it seems to be slightly roughened) wipes against the mating pins to remove any dirt or oxide buildup. At the same, the pins on the connector (not on the plug!) are briefly shorted to ground when the plug is inserted or removed, alerting the sensing circuitry to that.

People keep asking why Apple didn’t opt for the micro-USB connector. The answer is simple: that connector isn’t smart enough. It has only 5 pins: +5V, Ground, 2 digital data pins, and a sense pin, so most of the dock connector functions wouldn’t work – only charging and syncing would. Also, the pins are so small that no current plug/connector manufacturer allows the 2A needed for iPad charging. Note that this refers to individual pins; I’ve been told that several devices manage to get around this by some trick or other, but I couldn’t find any standard for doing so.

This takes us back to the sensing circuitry referred to. If one of the pins is reserved for sensing – even if it is the “dumb” sensing type that Apple has used in the previous generation, using resistors to ground – and two pins are mapped directly to the 2 USB data pins [update: I now think such direct support is unlikely] whether the USB side is plugged to a charger or to a computer’s USB port, and the other 5 pins can be used for charging current without overloading any single pin.

This also explains the size (and price) of the Lightning-to-30 pin adapter. It has to demultiplex the new digital signals and generate most of the old 30-pin signals, including audio and serial transmit and receive. The adapter does say “video and iPod Out not supported”; I’m not sure if the latter refers to audio out, though I’m now informed that the latter exports the iPod interface to certain car dashboards.

It’s as yet unknown whether Lightning will, in the future, support the new USB 3.0 spec – the current Lightning to USB cable supports only USB 2.0. This would require 6 (instead of 2) data pins, which is well within the connector’s capabilities. But would the mobile device’s memory, CPU and system bus support the high transfer rate? My guess is, not currently. Time will tell.

Update: deleted the reference to “hero” (I didn’t know it’s designer’s jargon). Also, for completion, I just saw there’s a Lightning to micro-USB adapter for European users, where micro-USB is the standard.

Update#2: good article at Macworld about Lightning. Also, Dan Frakes confirms that Apple says audio input is not included in the 30-pin adapter.

Update#3: found out what “iPod out” means, and fixed the reference.

Update#4: I added to the micro-USB paragraph, above. Thanks to several high-profile references (The Loop, Business Insider, Ars Technica – who also credited my composite picture – and dozens of others), I saw a neat traffic spike here. WP Super Cache held up well. The comments on all those sites are – interesting. 🙂 Of course whoever is convinced that everything is a sinister conspiracy by Apple won’t convinced by any technical argument, and I want to restrict myself to the engineering aspects.

Update#5: more thoughts (and some corrections) in the follow-up post. Please read that first and then comment over there.

RB App Checker Lite 1.0.2 is out. Sorry for the delay; to compensate, there are some neat new features and a lot of infrastructure work has been done to prepare for the upcoming non-lite version.

…while Apple catches up with sent-in FAXes. Yes, you read that right.

In the meantime, RB App Checker Lite is momentarily off the Mac App Store. (It’s still normally available from the product page, of course.)

With very few interruptions, I’ve been a registered Apple Developer since mid-1984, when I bought the original loose-leaf edition of “Inside Macintosh”. From a reasonably early date onwards, I always paid by credit card. At some point – I think it was the late 1990’s – most developers were switched to paying over the iTunes store – quite practical in the US and Europe, since that was already tied to the Apple ID.

However, Brazil was very late in getting the iTunes store and from then on developers here had to send in an annual FAX stating their identification, credit card number, and so forth. A few years ago, the the iOS app store, the iTunes store, and the Mac app store (in that order, I think) became available and every time we heaved a collective sigh of relief, thinking that easy payment would be again possible.

Unfortunately, it’s now late 2012. All the stores are available but we still have to send in a FAX to Cupertino to renew our developer programs! No shipping Mac even has a built-in FAX-Modem anymore, which was what I used in the early years. Twice, I’ve asked developer relations at WWDC to send in the FAX for me – which they did, to their credit; and for the last few years I’ve asked their counterparts at Apple Brazil to do so, as they’re the only place I know of which still has a FAX machine stashed away somewhere. Still, the renewal was effected in a few days.

When I renewed my iOS membership a few months ago it took an unprecedented 7 days to be effected after sending the FAX, so when my Mac membership renewal came up, I thought it prudent to send in the FAX 20 days (!) before to ensure a timely response.

Unfortunately, the 20 days have come and gone, my renewal application still hasn’t been processed, and I’ve been cut off from the developer sites. Moreover, my app is no longer visible in the Mac App Store. I’ve already complained twice to Developer Relations and re-sent the FAX (both by machine and by email) 3 times; at first they admitted that it should have taken at least two weeks (!) to process, but haven’t replied since.

In the meantime, the new version of RB App Checker Lite had been in the review queue for 15 days and was finally rejected this week; first because of the pending renewal, second because of a temporary entitlement that had been accepted in the first version. I’m working on that. More soon (hopefully).

Update: just got email from Apple, stating that they put in a temporary extension while my renewal is being processed. The app isn’t back on the store yet, but at least it gives me breathing time to submit a new version; perhaps as soon as tomorrow.

Update #2: the app is back on the store. Stay tuned…

Update #3: my renewal has been processed, and we’re back to normal. Now working on the app again.

Recently someone figured out an attack against in-app purchasing on iOS. Only a few days later Apple, with commendable speed, put up a page detailing how to counter this crack by implementing better receipt checking.

Now there’s news that a similar attack also works on OS X. For this, users have to install two bogus certificates, point their DNS at the cracker’s server, and run an auxiliary application while making the in-app purchase; this builds an apparently valid receipt inside the application bundle. (Of course this means that the user is trusting those certificates, that server and that application to be otherwise innocuous – not a good policy! And it asks you for your admin password while you’re connected to that server, too…)

So how to implement better receipt checking on the Mac? The details are different, in that OS X in-app receipts are stored inside the application bundle, inside the application’s original receipt from the Mac App Store. Furthermore this receipt has a known format and is signed by 3 certificates:

• “Mac App Store Receipt Signing” (SHA1: 4A 7B 3A 17 00 A4 DA 4A D4 EA 43 3A 83 61 43 2E CF 1C A1 AF)
• “Apple Worldwide Developer Relations Certificate” (SHA1: 09 50 B6 CD 3D 2F 37 EA 24 6A 1A AA 20 DF AA DB D6 FE 1F 75)
• and the “Apple Root CA” (SHA1: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60)

the latter can be found, of course, inside every Mac user’s System Keychain. All this was easily obtained with my RB App Checker Lite utility (ahem). 🙂

Apple’s currently recommended receipt verification code, however, does not contain any recommendation to check the certificates used to sign the receipt; it does check if the receipt is for that particular application (otherwise people would just copy a receipt from another app) and if the receipt was generated on that particular computer (otherwise one could just copy the app from a friend’s computer).

No doubt Apple will now recommend to all OS X developers that their receipt verification codes also check the certificates – and in fact, that’s what my apps are already doing. The certificates are, after all, available from the same parsing process recommended in the above link. At the very least, I recommend obtaining the SHA1 fingerprints of all 3 certificates (openssl has a SHA1() function for that) and checking them against the list above. And once that’s done, obtaining the app’s own signing certificates, and checking them, is also advisable, even if the app is signed with a Developer ID.

I’m not giving specific code examples here, to avoid people copy&pasting it into their apps and offering a clear path to hacking the binary. The usual precautions to make binary hacking more difficult (though it’ll never be impossible) apply, of course.

If you’re using Quay, please check out the release notes and install this new version as soon as possible.

Note that older versions of Quay will break on Mountain Lion, giving you a persistent error message. Sorry about that, but the installation should be painless. Quay is now signed with my Developer ID for Gatekeeper compliance. And with RB App Checker Lite this is easy to verify. 😉

That said, I’m hard at work to get new stuff out in time for Mountain Lion (rumors say that will be sometime between July 19 and 31). Details are still fluid but I’ll post them here as soon as I get the basic functions working reliably.

My main concern is keeping my promise of upgrading paid users of Quay and XRay to the new stuff. This is unfortunately impossible with the Mac App Store, but not all utilities will be there, so i still think it’s going to work out.

Update: while this runs fine on 10.8 in my tests here, it may not behave well on the new Retina display (remember this was originally coded for 10.5!). I’ll try to do some tests tomorrow.

Update 2: OK, tests show it’s not Retina-compatible, so I’ve uploaded a new build with the “Open in Low Resolution” option checked. My apologies for the oversight. It’s not at all clear – looking at the source – how I could make it compatible both with high-resolution and 10.6.8 on short notice. And it’s still a 32-bit application, too.

Summing up: Quay is getting elderly and this update is, really, only for current users who like it. Don’t expect it to be updated again. But, as I said above, cool new stuff will soon be out. Suggestions welcome!

RB App Checker Lite 1.0.1 (187) has just gone live on the Mac App Store, and the corresponding Developer ID-signed build (186) is now available for direct download.

In the last month, almost exactly 1000 copies have been downloaded from the Mac App Store, and about 300 copies have been downloaded directly from my site. Not bad; the download curve shows the usual decaying exponential shape, but it is decaying much more slowly than I thought it would. And this with no marketing except for Twitter and a single press release.

Since both versions are free, I suppose that the main reason for users preferring the MAS version is the ease of updating; the direct-download version doesn’t have automatic updating, nor is it cost-effective to have it now. The popular Sparkle framework is over double the size of the entire application, and does much more than I need. When a non-MAS RB Utility comes out, it will have automatic updating, and that will automatically appear in all direct-download RB Utilities; a benefit of using a common app framework.

Update: here’s a common use scenario for RB App Checker Lite: an automatic updater starts and requests your administrator password. Is this safe? Easy to check:

• Command-click on the updater’s icon in the Dock; this will show the updater’s icon in the Finder;
• Right-click on this icon and select the “RB App Checker Lite ” service;
• RB App Checker Lite’s results should tell you if the updater can be trusted or not. Be especially wary of unsigned or self-signed updaters that ask for your admin password, unless you’re really sure!

…and you probably hadn’t realized I was away. Well, we spent 10 days away in Chile (more precisely, the Atacama Desert) and Bolivia (Salar de Uyuni). Here’s our updated world map (61 countries):

Briefly, it was tiring and cold but the landscapes were worth it.

Now back to the old drawing board; a bug-fix update to RB App Checker Lite should be out tomorrow, I hope. Stay tuned.

Yesterday evening RB App Checker Lite was approved for sale in the Mac App Store. Whew; it’s been a difficult couple of weeks, but it’s done. Now to relearn my php-fu and do a better product page, and of course restart work on other apps in the RB Utilities suite. Next in queue are “RB File Counter”, “RB File Alias” and the non-lite version of RB App Checker.