Apple, Open Source, and the iPhone SDK

So, Apple is not going to require that free iPhone/touch apps are delivered through iTunes. Yup, Apple is making a provision for free software? Well, their kernel is based on it, so is the iPhone's browser; and any free software written for the iPhone can always be adapted and built on later for Apple. What will be really interesting is to see if installer.app makes the cut, because package managers may make things more complicated.

A forecast of things to come

I've been thinking about Android, and the iPhone SDK lately, and I have formulated what I think will happen with the mobile industry over the course of the next five to ten years.

• Handsets and providers that provide an excellent all-around mobile experience are going to sell well.This seems like a bit of a given, but I would like to start here. Apple and AT&T provide a complete mobile experience by working together, from registration in iTunes without having to talk to an AT&T customer service rep to the method on the handset's keyboard that lets you type alternate letters. The iPhone provides a complete experience, and what other handset manufacturers and carriers need to get is that multi-touch is only a vessel for making the iPhone experience special. The iPhone could have been done just as well, albeit differently, without multi-touch. The innovative people at Apple would find a good way to make some other input technology suit their needs. There are a lot of handsets embracing new things hardware wise, but not a lot of new things software-wise. The need for deep integration between hardware and software at the mobile level is something that these handset manufacturers need to get in order to be successful as the mobile market evolves.
  One of the things that makes the iPhone experience such a good experience is that it has a fast enough processor to run graphics really, really well. The iPhone is estimated to have a processor clocking in at somewhere around 500 Megahertz, which allows it to show movies, run a compositor, and perform its fancy animations.
• Handset makers will be forced to adopt phones with better processors. Currently smartphones run at somewhere between 100 MHz and 150 MHZ. As the market for mobile phones grows, vendors will be forced to adopt faster processors. The processor used in the MacBook Air may become a mobile phone processor, clocked down to about 1.0 GHz to save power. Handsets will begin integrating video cards by default to run OpenGL accelerated graphics. Handsets will have more power-efficient 3G chips and bigger storage media.
• XMPP will become the new messaging and alert service of choice. The android phone already includes XMPP as a way to get messages. With XMPP, services such as news and weather alerts will become better, an RSS reader-like application will be able to run on the phone, allowing customers to set up specific feeds as to alerts, and unlike current SMS alerts, the alerts can have coherent formatting. XMPP also provides for chat and IM services (jabber), and can send more than just text and small images, making SMS and MMS more obsolete. And unlike SMS and MMS, the jabber services will cost only a monthly data plan.
• More phones will come bundled with data plansAll of the new technology described above requires money to spend on phones. Currently in the United States market, mobile phones are subsidized by the carrier, which is then made up for with a contract for a certain amount of time. As data plans start to become more ubiquitous, carriers will be able to charge more per month for them, enabling greater subsidies. Expensive phones with two year data plan contracts may become as cheap as non-data phones.

In the end, it all boils down to a more complete experience. Integration between hardware and software, good hardware specs backed by subsidies, and XMPP or a better version of SMS that makes use of data will make up the next couple of mobile generations. A laptop processor fits into a phone, and things such as Android and the iPhone drive the market to brave new worlds.

Cold Boot Attacks

There has been a little fuss about cold boot attacks recently, and I've been thinking about it. While it cannot be prevented altogether on the software/firmware side, it can be made harder to orchestrate. First, all macs for a long time now have come with a feature called "Automatic reboot after power failure." It can still be found now under energy saver in the system preferences dialogue. This was achieved by an Open Firmware extension, and with Intel Macs an EFI extension. The logical thing to do to prevent against cold boot attacks that involve booting off of a USB key is to have the power failure extension clear the key from RAM by writing zeros to it if there is an encrypted disk. Since Open Firmware loads before the operating system, the key will be long gone before that pen drive operating system has a chance to load. An even simpler way to do it would be to just set the firmware to clear the contents of memory, commonly known as ECC, or Error Correcting Ram.

Preventing against the transferring to another computer would involve more difficulties, since the cutting of power can't be anticipated. The best way to do this would be to use a kind of volatile RAM that does lose its contents immediately. However, a way to do this software level is to clear the key when the computer goes to sleep, then require the user to enter the password to get the key once the computer wakes up again. Of course, the best defense is still shutting down your machine until it goes into ACPI G3 mode (off).

Thoughts on the iPhone SDK

Well, the iPhone SDK is slated to come out near the end of this month (I'm guessing the 26th). Just some conjecturing about some security things not present in the jailbreak. First, permissions. Nothing will be run as root. Nothing. Why? Because the iPhone user's password is set to null; the hash does not match anything. So, there will be no way to elevate to root on the iPhone? Partially correct. There will be no way to run a process as root on the iPhone, however folders with permissions of root will be writable when the iPhone is mounted in iTunes, just like currently. This will let people load things in /Applications, and currently lets Apple update the firmware.

Second, application distribution. As of right now, all applications for the jailbreak version are delivered through installer.app. There have been theories that Apple will charge a distribution fee for iPhone apps through iTunes. I do not think that this will be the case, because Apple has provided other application directories, including one for the iPhone web apps. What's to prevent them from making a mobile applications page today, and host developer's applications for free, like in their other application directories?

That, of course, brings us to the topic of downloading and installing web apps. My best guess is that web apps will either be delivered as .app bundles, or as a special iPhone installer, such as .ipkg, to avoid confusion between desktop and mobile apps. This would fit in well with my predicted iPhone interface builder files.

Lastly in my conjecture, I think that Apple and its partners are going to release several applications at the same time as the SDK, such as Lotus Notes, a native bejeweled game, and the possibility of a company like Nintendo releasing some great touch screen games.

iPhone Style

So, I spent last night making my blog printer friendly and iPhone friendly. The iPhone friendly version still has a little work to go, but it works right now (the sidebar is hidden and there is some special formatting). I acknowledge that it is a work in progress, and it may still change over the next couple of days. It should be really cool when it is done.

Another example of bad web form

I was looking over the CSS Media tag reference, part of CSS3 and implemented less in-depth in CSS2/HTML4. Distinguishing between print media and screen media is available in IE 5 and above, all versions of Firefox, Safari, Konqueror, I think Opera. Why do we still have these funny printer friendly versions for articles on sites such as the New York Times. If the New York Times removed their printer friendly link for one year and instead had a short text box that basically says,

"This page uses standards-compliant web technology to automatically print in a printer friendly version. Supported browsers include IE5 and better, Safari, Firefox, Opera, and others,"

that would be great. Such a thing would stop people like my mother from not seeing the printer friendly link and printing three or four pages to get the one page of content. It just takes better coding, and a knowledge of CSS. As the web evolves, hopefully we will begin to see more tree-friendly sites as well.