Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Wednesday, April 28, 2010

WWDC dates announced

The entire of Twitter has imploded after noticing that Apple has announced the dates for WWDC, this year June 7-11. That’s too short notice for me to go, and having only recently started working again after a few months concentrating solely on Professional Cocoa Application Security, I can’t scrape together the few thousand pounds needed to reserve flights, hotel and ticket at a month’s notice.

I hope that those of you who are going have a great time. The conference looks decidedly thin on Mac content this year, and while I still class myself as more of a Mac developer than an iP* developer that shouldn’t be too much of a problem. The main value in WWDC is in the social/networking side first, the labs second, and the lecture content third – so as long as you can find an engineer in the labs who remembers how a Mac works, you’ll probably still have a great week and learn a lot.

posted by Graham Lee at 15:52  

Tuesday, March 2, 2010

How to hire Graham Lee

There are few people who can say that when it comes to Cocoa application security, they wrote the book. In fact, I can think of only one: me. I’ve just put the final draft together for Professional Cocoa Application Security and it will hit the shops in June: click the link to purchase through my Amazon affiliate programme.

Now that the book’s more-or-less complete, I can turn my attention to other interesting projects: by which I mean yours! If your application could benefit from a developer with plenty of security experience and knowledge to share in a pragmatic fashion, or a software engineer who led development of a complex Cocoa application from its legacy PowerPlant origins through Snow Leopard readiness, or a programmer who has worked on performance enhancement in networking systems and low-level daemon code on Darwin and other UNIX platforms, then your project will benefit from an infusion of the Graham Lee magic. Even if you have some NeXTSTEP or OPENSTEP code that needs maintaining, I can help you out: I’ve been using Cocoa for about as long as Apple has.

Send an email to iamleeg <at> securemacprogramming <dot> com and let’s talk about your project. The good news is that for the moment I am available, you probably can afford me[], and I really want to help make your product better. Want to find out more about my expertise? Check out my section on the MDN show, and the MDN security column.

[] It came up at NSConference that a number of devs thought I carry a premium due to the conference appearances, podcasts and other material I produce. Because I believe that honesty is the best policy, I want to come out and say that I don’t charge any such premium. My rates are consistent with other contractors with my level of experience, and I even provide a discounted rate for NGOs and academic institutions.

posted by Graham Lee at 13:22  

Friday, January 1, 2010

CocoaHeads Swindon, January and February

The next CocoaHeads Swindon will take place on 4th January, at the Glue Pot in Swindon. Get here at 8 for some NSChitChat with your (well, my) local Mac developer community.

There is no February meeting of Swindon CocoaHeads, on account of NSConference Europe taking place in Reading on that weekend. So buy your NSConference ticket and come along to say hi!

posted by Graham Lee at 14:15  

Tuesday, July 14, 2009

NSConference videos

Scotty and the gang have been getting the NSConference videos out to the public lately, and now sessions 7-9 are available including my own session on security. The videos are really high quality, I’m impressed by the postproduction that’s gone in and of course each of the sessions I watched at the conference has some great information and has been well-presented. All of the videos are available here.

I’ve also put the slides for my presentation up over on slideshare.

posted by Graham Lee at 23:20  

Saturday, June 13, 2009

WWDC wind-down

As everyone is getting on their respective planes and flying back to their respective homelands, it’s time to look back on what happened and what the conference means.

The event itself was great fun, as ever. Meeting loads of new people (a big thank-you to the #paddyinvasion for my dishonourary membership) as well as plenty of old friends is always enjoyable – especially when everyone’s so excited about what they’re working on, what they’ve discovered and what they’re up to the next day. It’s an infectious enthusiasm.

Interestingly the sessions and labs content has more of a dual impact. On the one hand it’s great to see how new things work, how I could use them, and to realise that I get what they do. The best feeling is taking some new information and being able to make use of it or see how it can be used. That’s another reason why talking to everyone else is great – they all have their own perspectives on what they’ve seen and we can share those views, learning things from each other that we didn’t get from the sessions. If you were wondering what the animated discussions and gesticulations were in the 4th Street Starbucks at 7am every morning, now you know.

On the other hand, it makes me realise that OS X is such a huge platform that there are parts I understand very well, and parts that I don’t really know at all. My own code spreads a wide path over a timeline between January 1, 1970 and September 2009 (not a typo). For instance, it wasn’t until about 2003 that I knew enough NetInfo to be able to write a program to use it (you may wonder why I didn’t just use DirectoryServices – well even in 2003 the program was for NeXTSTEP 3 which didn’t supply that API). I still have a level of knowledge of Mach APIs far below “grok”, and have never known even the smallest thing about HIToolbox.

There are various options for dealing with that. The most time-intensive is to take time to study – I’ve got a huge collection of papers on the Mach design and implementation, and occasionally find time to pop one off the stack. The least is to ignore the problem – as I have done with HIToolbox, because it offers nothing I can’t do with Cocoa. In-between are other strategies such as vicariously channeling the knowledge of Amit Singh or Mark Dalrymple and Aaron Hillegass. I expect that fully understanding Mac OS X is beyond the mental scope of any individual – but it’s certainly fun to try :-).

posted by Graham Lee at 16:01  

Thursday, May 28, 2009

Prepping for WWDC

With the obvious first question being which parties do I go to? See you there?

posted by Graham Lee at 22:54  

Saturday, April 25, 2009

On dynamic vs. static polymorphism

An interesting juxtaposition in the ACCU 2009 schedule put my talk on “adopting MVC in Objective-C and Cocoa” next to Peter Sommerlad’s talk on “Design patterns with modern C++”. So the subject matter in each case was fairly similar, but then the solutions we came up with were entirely different.

One key factor was that Peter’s solutions try to push all of the “smarts” of a design pattern into the compiler, using templates and metaprogramming to separate implementations from interfaces. On the other hand, my solutions use duck typing and dynamic method resolution to push all of the complexity into the runtime. Both solutions work, of course. It’s also fairly obvious that they’re both chosen based on the limitations and capabilities of the language we were each using. Nonetheless, it was interesting that we both had justifications for our chosen (and thus One True) approach.

In the Stroustroup corner, the justification is this: by making the compiler resolve all of the decisions, any problems in the code are resolved before it ever gets run, let alone before it gets into the hands of a user. Whereas the Cox defence argues that my time as a programmer is too expensive to spend sitting around waiting for g++ to generate metaprogramming code, so replace the compilation with comparitively cheap lookups at runtime – which also allows for classes that couldn’t have possibly existed at compiletime, such as those added by the Python or Perl bridge.

This provided concrete evidence of a position that I’ve argued before – namely that Design Patterns are language-dependent. We both implemented Template Method. Peter’s implementation involved a templatized abstract class which took a concrete subclass in the realisation (i.e. as the parameter in the <T>). My implementation is the usual Cocoa delegate pattern – the “abstract” (or more correctly undecorated) class takes any old id as the delegate, then tests whether it implements the delegation sequence points at runtime. Both implement the pattern, and that’s about where the similiarities end.

posted by Graham Lee at 19:44  

Tuesday, April 21, 2009

Did you miss my NSConference talk?

The annotated presentation slides are now available to download in Keynote ’08 format! Sorry you couldn’t make it, and I hope the slides are a reasonable proxy for the real thing.

posted by Graham Lee at 20:40  

Sunday, April 19, 2009

On default keychain settings

After my presentation at NSConference there was a discussion of default settings for the login keychain. I mentioned that I had previously recommended some keychain configuration changes including using a different password than your login password. Default behaviour is that any application can add a secure item to the keychain, and the app that did the adding is allowed to read and modify the entry without any user interaction. As Mike Lee added, all other apps will trigger a user dialogue when they try to do so – the user doesn’t then need to authenticate but does have to approve the action.

That almost – but not quite – solves the issue of a trojan horse attempting to access the secure password. Sure, a trojan application can’t get at it without asking the user. What about other trojan code? How about a malicious SIMBL hijack or a bundle loaded with mach_override? It should be possible to mitigate those circumstances by using custom code signing requirements, but that’s not exactly well documented, and it’s not really good usability for an app to just die on its arse because the developer doesn’t like the other software their user has.

There’s a similar, related situation – what if the app has a flawed design allowing it to retrieve a keychain item when it doesn’t need it? Sounds like something which could be hard to demonstrate and harder to use, until we remember that some applications have “the internet” as their set of input data. Using a web browser as an example, but remembering that I have no reason to believe whether Safari, Camino or any other browser is designed in such a way, imagine that the user has stored an internet password. Now all that the configuration settings on the user’s Mac can achieve is to stop other applications from accessing the item. If that browser is itself subject to a “cross-site credentials request” flaw, where an attacking site can trick the browser into believing that a login form (or perhaps an HTTP 401 response, though that would be harder) comes from a victim site, then that attacker will be able to retrieve the victim password from the keychain without setting off any alarms with the user.

If the user had, rather than accepting the default keychain settings, chosen to require a password to unlock the keychain, then the user would at least have the chance to inspect the state of the browser at the time the request is made. OK, it would be better to do the right thing without involving the user, but it is at least a better set of circumstances than the default.

posted by Graham Lee at 17:00  

Friday, April 17, 2009

NSConference: the aftermath

So, that’s that then, the first ever NSConference is over. But what a conference! Every session was informative, edumacational and above all enjoyable, including the final session where (and I hate to crow about this) the “American” team, who had a working and well-constructed Core Data based app, were soundly thrashed by the “European” team who had a nob joke and a flashlight app. Seriously, we finally found a reason for doing an iPhone flashlight! Top banana. I met loads of cool people, got to present with some top Cocoa developers (why Scotty got me in from the second division I’ll never know, but I’m very grateful) and really did have a good time talking with everyone and learning new Cocoa skills.

It seems that my presentation and my Xcode top tip[] went down really well, so thanks to all the attendees for being a great audience, asking thoughtful and challenging questions and being really supportive. It’s been a couple of years since I’ve spoken to a sizable conference crowd, and I felt like everyone was on my side and wanted the talk – and indeed the whole conference – to be a success.

So yes, thanks to Scotty and Tim, Dave and Ben, and to all the speakers and attendees for such a fantastic conference. I’m already looking forward to next year’s conference, and slightly saddened by having to come back to the real world over the weekend. I’ll annotate my Keynote presentation and upload it when I can.

[] Xcode “Run Shell Script” build phases get stored on one line in the project.pbxproj file, with all the line breaks replaced by n. That sucks for version control because any changes by two devs result in a conflict over the whole script. So, have your build phase call an external .sh file where you really keep the shell script. Environment variables will still be available, and now you can work with SCM too :-).

posted by Graham Lee at 18:16  
Next Page »

Powered by WordPress