July 29, 2011

XPC and how it might affect Mac App Architecture

Just finished watching the developer video about XPC from Apple. This is actually pretty cool. For those of you who aren’t hip to the goods, XPC is an attempt at a simper-simple way for separate applications to talk to each other. This feature works well with Lion’s new Sandboxing ability which more strictly reduces the abilities of an application. Now Mac apps can follow the security model that my security-paranoid friends told me about where applications/users/whatever only get the bare minimum privaliges they need to accomplish their task. This allows for app-makers on the Mac to split up parts of their application into it’s own sort of mini-app to do simple, specific units of work that might be dangerous/unstable/etc. These individual chunks then only need the specific privaliges necessary to accomplish their task, so tasks like “decode this video file” can’t be exploited to read a user’s address book or phone home.

For example:

​1) Apple’s Preview.app uses XPC to separate actually parsing a PDF file into a separate little mini-app. That way, bad PDFs won’t cause all of Preview.app to crash and PDF’s attempting to exploit the PDF parser can’t ruin the rest of your app or the user’s computer.

​2) Apple’s Quicktime.app uses XPC to decode video files with a mini-app that only has enough permissions to use the cpu to handle the data it gets fed. This way mean hackers won’t be able to trick Quicktime with bad video files and try to make Quicktime phone home with all of a
user’s address book. Also bad files won’t cause the whole application to crash, yay.

I tried to come up with my own uses for XPC and the first that came to mind was forText Editors: use xpc to crate a mini-app that parses text files. This way large text files won’t cause your application to crash, nor will they pinwheel your text editor for a while (cough cough Textmate).

Feel free to contact me and tell me I’m an idiot if I understand this wrong. :)