The rokeg blood pie^W^W^Wplot thickens

So, having already discussed Klingon Anti-Virus, the under-research Klingon threat detection tool made available by Sophos, it seems that more information has been made available. From no less, or indeed more, of a source than the blog of my Clu-ful conym.

This seems to confirm the impression that the tool has been developed for some special internal use and might not be downloadable much longer. It’s hard to tell, though; most of the company is being very quiet about it (indeed it wasn’t until today that much internal noise was generated about the tool at all).

Of course, maybe I’m being duped. This could be some sort of company experiment to see, well, either how much free marketing they can get or who in the company is responsible for the press leaks. If it’s the latter, then I need you all to take a look at my CV as I’ll probably be relying on it – and you – soon ;-).

Anyway, take a look at the tool if you’re interested, I’ve had reports that it works well but still haven’t heard much feedback about the quality of the translation. BTW, interested in a Mac version of the tool? I can’t promise anything but leave a message after the beep and I’ll forward requests…

Posted in enterprise, klingon, security, star trek | 1 Comment

Detect the gagh lurking in your system!

Following up on my previous ability to get to the top of a Google search for a Klingon word (that one was chuvmey, as in my post Model, View, chuvmey) here is yet another attempt. At what? Why, at skewing the mental associations between science fiction television and the digital security industry, of course!

Sophos Klingon Anti-Virus is a threat detection tool for Windows computers, but in Klingon. Ever wondered what Conficker and Rokeg blood pie have in common? No, neither have I. In fact, I doubt anyone has. Nonetheless, try out the tool and see what Romulan back-doors have been installed on your box.

(N.B. this means we have to expand our remit from “Enterprise” security software, to include at least the “HMS Bounty” from Star Trek IV)

Posted in enterprise, klingon, security, star trek | Leave a comment

Rootier than root

There’s a common misconception, the book I’m reading now suffers from it, that single-user mode on a unix such as mac os x gives you root access. Actually, it grants you higher access than root. For example, set the immutable flag on a file (schg I think, but my iPhone doesn’t have man). Root can’t remove the flag, but the single user can.

Posted in darwin, security, UNIX | 3 Comments

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 in C++, cocoa, conference, objc, ooa/d | 2 Comments

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 in conference, macdevnet, security | Leave a comment

I may have not been correct

When I said Apple should buy Sun, whether that was a good idea or not, it seems to have failed to occur. Instead, we find that Oracle have done the necessary. Well, there goes my already-outdated SUNW tag. Presumably they’ll keep Java (the licensing revenue is actually pretty good), MySQL (I’ve heard that Oracle make databases), the OS and a subset of the hardware gear. Then they’ll become the all-in-one IT industry in a box vendors that Cisco have yet to organise, with (presumably x86) servers running the Solaris-Glassfish-Oracle-Java app stack in some insanely fast fashion. I wonder how many of the recent leftfield hardware projects they’ll just jettison, and who will end up running the Santa Clara business unit…

Posted in Java, orcl, sunw, UNIX | Leave a comment

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 in conference, Keychain, security | Leave a comment

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 in cocoa, conference, iPhone, macdevnet, metadev, objc, security, xcode | Leave a comment

Controlling opportunity

In Code Complete, McConnell outlines the idea of having a change control procedure, to stop the customers from changing the requirements whenever they see fit. In fact one feature of the process is to be heavy enough to dissuade customers from registering changes.

The Rational Unified Process goes for the slightly more neutral term Change Request Management, but the documentation seems to imply the same opinion, that it is the ability to make change requests which must be limited. The issue is that many requests for change in software projects are beneficial, and accepting the change request is not symptomatic of project failure. The most straightforward example is a bug report – this is a change request (please fix this defect) which converts broken software into working software. Similarly, larger changes such as new requirements could convert a broken business case into a working business case; ultimately turning a failed project into a revenue-generator.

In my opinion the various agile methodologies don’t address this issue, either assuming that with the customer involved throughout, no large change would ever be necessary, or that the iterations are short enough for changes to be automatically catered for. I’m not convinced; perhaps after the sixth sprint of your content publishing app the customer decides to open a pet store instead.

I humbly suggest that project managers replace the word “control” in their change documentation with “opportunity” – let’s accept that we’re looking for ways to make better products, not that we need excuses never to edit existing Word files. OMG baseline be damned!

Posted in metadev | 2 Comments

On noodles

It’s usually considered a good idea to keep a blog focused on exactly one subject. Sod that for a game of soldiers! This one’s all about music.

Steph, who is a very good musician and knows what she’s talking about, wrote that there are two ways to play a harp, a “get the music right” recitation style and a “get the rhythm right and everything else follows” style more suited to improvisation, noodling or folk playing.

That’s not only true of the harp, it seems to hold for many instruments. For instance, in a moment of crazed, um, craziness this weekend I bought what’s commonly referred to as a lute. In fact, a lute with much in common with this lute. Now I’ve been playing it for all of about two hours in total since Saturday, and can barely remember what note each course plays, and do a poor rendition of about four different tunes from a book of trivially simple lute tunes. But today marked an interesting transition, as it was the first day that I could make music up on the instrument without either knowing or concentrating on what I was doing. Only a couple of things (the song “Wooden Heart” made famous by Elvis Presley, and that banging dance-floor filler “Parson’s Farewell”) but this represented the point where I could make music on the lute – a different skill than remembering where and when to stick fingers on some bits of nylon, steel and wood.

And I think that’s where the root of Steph’s distinction of playing techniques really comes from; the unprepared style relies on having some music that needs to occur, and the ability for your hands (or nose or whatever your instrument is played with) to move around in some way which causes that music to exist. Whereas the prepared style relies on having some performance in mind that must be repeated, and requires that you think about moving $appendage in such-and-such way to recreate that performance. I find the distinction in conscious application to be an important one when playing the fiddle, an instrument I’m marginally better at than the lute. If I’m reading some music, playing solo or otherwise engaged in trying to play music, then I can only play whatever notes the music contained and in a fairly uninteresting manner. It’s only if I’m able to relax and not think about the music that I can harmonise, ornament and otherwise play more interesting things than what was written on the page – even if not necessarily particularly well :-).

Posted in music | Leave a comment