Solipsism Gradient

This is a follow-up to my post about Apple’s new Lightning mobile connector. Thanks to all who linked or commented.

Apple has since published mechanical drawings of the iPhone 5, iPod nano 7th gen, and iPod touch 5th gen. The nano’s drawing has the best illustration of the connector side:

Applying the known width of 10.02mm to the connector photos, it would seem that the projecting part of the plug is about 1.6mm thick and 6.9mm wide. It so happens that this matches closely the standard printed circuit board thickness of 63 mils (1.57mm). The conclusion is clear: the plug consists of a PCB with 8 contacts on each side in a protective metal cladding. The PCB inside the plug’s body will have components on each side; remember the Thunderbolt cable teardown?

The actual interface specifications are still not available to the public – in fact, I think the old 30-pin connector specs never were officially available. What information we have is reverse-engineered or leaked from companies that are in Apple’s MFi program. But connector trends are clear. Some of you may remember the old SCSI 50-pin and Centronics 36-pin connectors; both interface were comparatively low-speed parallel and were substituted by higher-speed USB and FireWire serial interfaces. Thunderbolt, for instance, despite its relatively numerous 20 pins, is a serial interface. It has two full-duplex, differential, 10Gbps data paths (meaning 2 pin for each of 4 transmit/receive pair) as well as two low-speed transmit/receive pins, a connector sensing pin, a power pin, and several ground/shield pins. This is still overkill for the new generation of mobile devices, hence Lightning, which has only 8 pins (plus the outer ground/shield) and, no doubt, lower speeds.

So what are the technical reasons to go with Yet Another Proprietary Connector? Apple has, of course, gone down that road so often that their engineers are well-aware of the tradeoffs involved. We’ve seen the same happen a year or two ago: instead of going to USB3 or eSATA for external devices, they developed Thunderbolt (together with Intel), which is both faster and much more flexible.

Many people complain that Apple should have chosen micro-USB instead of a proprietary connector. The micro-B connector is almost exactly the same size as the Lightning, though it has only 5 pins and is not reversible. The USB3 version of micro-B has 5 extra pins in a separate section and twice the width of the USB2 version. USB3 has actually two different pin groups: one implements the USB2 standard while 2 extra signal pairs handle the new specification. As I mentioned before, usually the USB2 version has limited current carrying capability which would make it unsuitable for the upcoming Lightning iPad; the USB3 version has enough capability but is larger. Non-standard variations are already on the market, and yes, some connector manufacturers are now specifying higher current capacity on the two power pins. True, there are standards being implemented that expand these limits even more, but they’re not quite on the market yet.

Designing an interface means balancing many technical and design trade-offs, especially for a mobile device where device volume, battery capacity, thermal limitations, available PCB area, charging parameters and statistics of intended use all impose serious constraints. Let’s for the moment posit Apple had gone the micro-USB3 route. This would mean a dedicated USB3 host controller/transceiver chip like the TI TUSB1310A as well as several added passive components. This representative chip actually contains a secondary USB2 controller/transceiver for compatibility, has a peak power comsumption of nearly 0.5W while operational and requires 3 different power supplies. The chip alone is over 12x12mm square. More important, Apple’s SoC (system-on-a-chip) design means that their main chip has to implement the transceivers’ dual data interface and various control signals; several dozen of the chip’s 175 pins would connect to the SoC, needing additional PCB space.

In contrast, support for Lightning will probably need no extra chips and less than a dozen extra pins on the SoC; 8 of these will go straight to the connector. One or two of the pins will probably sense which kind of adapter or charger/cable is connected and the others will go, in parallel, to the power controller – switching them will allow enough current for charging without overloading any particular pin. Any current-hungry drivers, signal converters and so forth wouldn’t on the motherboard at all but inside the plug itself, further reducing cost and power consumption for the bare device. The interface may even be self-clocking, with a clock signal routed to the connector whenever necessary, so future system could implement higher speeds.

All this flexibility means that, probably, the Lightning-to-USB2 cable included with the current devices has a driver/signal conditioner chip embedded inside the plug. Any standard charger may be used but Apple’s charger already has a way of signaling its capabilities to the device. The Lightning-to-30pin adapters have, in addition, at least a stereo D/A converter for line audio out and. Upcoming HDMI and VGA adapters will receive audio/video signals in serial form and convert them to the appropriate formats. Third parties can, should Apple’s software allow it, build audio inputs, digital samplers, video-in or medical instrumentation adapters. All this without impacting users who need none of these adapters, but just want to charge their device.

Could all this also be done with USB2 or 3? Well, in principle, yes, but at a cost. Other manufacturers are using, for instance, MHL, which passes audio/video over the USB connector. However, this simply repurposes the connector itself – you need a separate controller chip to generate the MHL signals while the USB controller is turned off, unless you make yet another non-standard plug. (Note that MHL adapters are in the same price range as Apple’s adapter, so nothing gained there either.)

Update: forgot to mention that, with the assumptions above, nothing but SoC speed restrictions preclude Apple from releasing a Lightning-to-USB3 cable in the future.

Update#2: my comments on the physical details of the connector.

Update#3: my final summary. Please comment there, comments here are now closed.

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.