GUID collision
inevitable, but we
live with the odds

Lifted from Mr. Kradel. I know, I cheated a little.

As we’ve mentioned before, we’ve got a beta of the next version of Tempo running. Most of the changes we made were with regard to user interface, but there are a couple of changes and enhancements (we think) to the API.

Accordingly, I’ve updated the API documentation (this was long overdue), leaving a beta notice on new methods and methods that are changing or going away.

If you have code that relies on the Tempo API, please get in touch with us so we can point you at the beta URL and help with the transition.

To summarize the changes:

• We are introducing a reports API. It’s not complete, but it’s a start.
• By popular demand, /entries, /projects, and now /reports support an id[] parameter for pulling specific entities in one call.
• Searching for entries has been moved to /reports/search GET, replacing /entries/search POST. The /entries/search URL will redirect to /reports/search for now, but you’re better off migrating sooner than later.
• The /entries GET method used to provide the same data you’d get from /entries/search if you didn’t specify any search criteria — a default context. Instead, /entries will now provide a listing of your own entries.

Some folks have asked us for JSON support, and while we’d really like to provide that now, it will be somewhat burdensome to implement, and will be available to us out-of-the-box in Rails 3, thanks to the provides/display feature of Merb.

Dan Grigsby has put together a helper for doing simple Facebook status updates from an iPhone app with a minimal amount of fuss.

Ignore the pirate-speak, that’s my lang setting on Facebook

- (void)session:(FBSession*)session didLogin:(FBUID)uid {
    fbHelper.status = @"is learning to set Facebook status programatically from an iPhone";
}

Most excellent.

Received in email from Apple:

As a developer actively working with iPhone OS, we would like your help in a private test of the Apple Push Notification service. For this test, we have selected AOL’s AIM Developer Preview for iPhone OS 3.0 to create a high-volume test environment for our servers.

I wonder if they are hoping to drum up interest and adoption of PNS, which has received a luke-warm reception from many developers. Putting that aside, I’m surprised to see Apple asking the developer community for help, pro bono. Considering how consistently poorly they treat third-party developers, that’s some nerve.

At the WWDC yesterday Apple announced the upcoming availability of their iPhone 3G S. In addition to a host of speed optimizations and new OS features Apple announced some new security features for the 3G S models: “Hardware Encryption” and remote wipe.

Ostensibly, the plan is that if your phone were lost or stolen you could issue a remote wipe and be confident that your data couldn’t be accessed. This is a feature that security conscious companies expect based on their experiences with BlackBerry’s “Erase Data and Disable Handheld” feature.

It’s interesting, however, to take a close look at careful wording Apple has used in their communications about the feature:

“iPhone 3G S offers highly secure hardware encryption that enables instantaneous remote wipe. You can even encrypt your iTunes backups.”

It almost sounds like the “whole device” encryption is primarily used to drive the remote wipe feature, not as an active security measure in its own right. If the encryption were used behind the scenes to secure the data on flash, then the remote wipe operation may not delete data. It could just remove the key and the device would “instantaneously” be rendered inoperable.

If that is the approach used there are some potential security implications:

• If the encryption is fully in hardware, is it really securing the device while running, or is it just enabling remote wipe? Will a strong passphrase (> 4 digits) be required to unlock the key? It’s not likely if background operations and software are running.
• Next up – the remote wipe trigger. It stands to reason that the device would need cell or network connectivity to initiate a remote wipe. Could you effectively disable remote wipe on an unlocked device by putting it into airplane mode and shutting off networking? What happens if you pop out and replace the SIM card?
• Finally, there is the matter of the encrypted backups. The statement that you can even encrypt your iTunes backups implies that the feature is optional and that backups wouldn’t normally be encrypted. This may in turn imply that iPhone application data is unencrypted when read off the device during a backup and re-encrypted for storage by iTunes. This lends credence to the idea that the scope of the encryption is limited.

This is all wild speculation of course, since very few substantive details have been released. While there is no doubt that the encryption features will enhance iPhone device security, it remains to be seen how the practical improvements will compare to the launch hype. I strongly suspect that highly sensitive information storage will still require dedicated security applications.