Even despite the dominance of webmail, I have long used a traditional desktop email client. I like having a local mail archive should “the cloud” have trouble, as well as the ability to exert control over the user interface and user experience. (That might be partly a euphemism for not having to see ads!)

Apple’s Mail.app built into macOS (going to have to get used to not calling it OS X!) has served me pretty well for quite some time now, alongside Thunderbird when I’m on Linux, and while Mail.app offered the most smooth interface for the platform, it didn’t always have all the features I wanted.

For example, being able to run mail rules is more limited than I wanted in Mail.app. I could have rules run automatically as messages arrived in my inbox, or disable them entirely. But actually how I wanted to use rules was to be able to cast my eye over my inbox, and then bulk archive (to a specific folder) all emails of a certain type if I’d decided none needed my fuller attention.

Recently, I moved to Thunderbird on my Mac for managing email and discovered QuickArchiver.

As well as letting you writing rules yourself, QuickArchiver offers the clever feature of learning which emails go where, and then suggesting the right folder to which that message can be archived with a single click.

It’s still early days, but I am enjoying this. Without spending time writing rules, I’m managing email as before, and QuickArchiver is learning in the background what rules should be offered. The extra column I’ve added to my Inbox is now starting to populate with that one-click link to archive the message to the correct folder!

It’s just a nice little add-on if, like me, you (still??) like to operate in this way with your email.

Today I release DfontSplitter 0.4.2 for Mac. This is a critical security update that fixes an issue relating to the Sparkle software update framework when the update pages are served over HTTP. As of 0.4.2, the update pages are now, naturally, served over HTTPS. (It was more than five years ago when the last release was made!)

The vulnerability means that in a scenario where an attacker could launch a man-in-the-middle attack during a Sparkle-enabled app’s update detection process, arbitrary JavaScript could execute in the WebView hosting the release notes. Due to the context that the WebView runs in, the app could then be convinced to run local files, expose local files to a remote server and even execute arbitrary code. More details and a full breakdown are at the post on Vulnerable Security.

This update fixes the Sparkle-related security issue by updating Sparkle and requiring HTTPS for all future DfontSplitter app update communications. Due to new build requirements in Xcode 7.2, the application now requires at least OS X Snow Leopard (10.6) and a 64-bit Intel processor.

The automatic updates feature within DfontSplitter should detect the update, but you can also download and install it manually.

Thanks to Kevin Chen for pointing out the existence of the issue with Sparkle and that it affected DfontSplitter. I had somehow missed the original reporting of the vulnerability, so I particularly appreciate Kevin bringing this to my timely attention.

The astute among you may note that in the Info.plist for this update, I explicitly disable the OS X 10.11 SDK’s check for HTTPS forward secrecy in the HTTPS communications to the update server. Once I figure out a cipher suite configuration that I am happy with, and understand, in Pound (my reverse proxy acting as the TLS terminus), I will update the app again to require forward secrecy.

It turns out that I have had an unintentional hiatus from podcasting for a number of months.

I’m glad, then, to have broken that with the release of Episode #222 of the International Mac Podcast — “Bezos’ Bezels”.

We talked about the state of all things Apple and iOS, speculated wildly about the future of the processors we will find in our Macs and made mention of the titular Amazon CEO’s strategy as compared to Apple.

It is always great to be invited on by Stu and the team and I thank everyone for the great show!

You can listen to the show on this page, download the MP3 file directly and also subscribe in iTunes or via RSS.

I am available for other podcast engagements; I would particularly be interested to talk about Apple, Linux, web development or computer security. Please do get in touch!

In my most recent article for For Mac Eyes Only, I ponder the implications of the remarkably speedy scheduled release of Apple’s OS X Mountain Lion on the longer term viability of older Mac hardware. Mountain Lion is due to arrive just a year after the release of Lion.

We now await OS X 10.8, Mountain Lion. Scheduled to be released a mere year after Lion, we are promised even more features ‘inspired by iPad’.

Wait a second. What was that? It is due to arrive this summer. Just one year after Lion was released.

A new release of OS X hasn’t come so quickly since the operating system was very young and was still being established and stabilised.

This strikes me as quite a shift, and it brings me to an important issue — how does this affect the lifespans of the Apple products we buy?

You can read the full article over on the For Mac Eyes Only site.

The opening of a new Apple Store is always an interesting experience — and one that never fails to inspire enthusiasm unheard of anywhere else in retail! I actually went along three and a half years ago to the opening of the WestQuay store in Southampton, but today, there was the Grand Opening of the new store in Festival Place, Basingstoke.

It is a really convenient store for me — it is just a 20 minute train journey away, so it is now even easier to get to the Apple Store should anything need fixing, or anything new need purchasing. 😉

I have put together a short video of the Grand Opening event, which you should see embedded below.

Definitely nice to go along, share in the experience — and pick up that all-important Festival Place Apple t-shirt to add to the collection. 🙂

I was delighted to be invited by Mark from Everyday Mac Support onto Not Another Mac Podcast — and the episode has now been published.

Mark, Glenn Künzler of MacTrast.com and myself discussed several post-WWDC topics, MacDefender and the Mac security landscape, iCloud and user control, the new iTunes Match and iTunes in the cloud features, the revamped ‘Apple Store 2.0’ experience, rumours about the Apple A5 chip in the MacBook Air and more.

You can take a listen to Episode 8 on the Your Mac Network site and also subscribe to the show in iTunes.

Thanks again to Mark for inviting me on the show. Mark and Dennis are always looking for other contributors on their show, even if you are not a seasoned podcaster. Please do go over to the site or contact them via @YourMacNetwork on Short-Form “Bird” Social Media Site Before It Went Terrible or by email if you think you might be interested.

I have actually been meaning to announce this here on my blog for quite some time, but just had never got around to it! Oops…

Anyway, I’m pleased to announce that I am now blogging for esteemed podcast For Mac Eyes Only‘s new Articles section. This is a great opportunity for me to get back into more regular blogging (I hope! 😉 ), which is something I love doing — and it’s a great opportunity to share some of my Mac knowledge with others.

I’ve already posted my initial thoughts on the Mac App Store as well as begun a Mac security series — and there should be much more arriving in the coming weeks.

I’ll be writing in the Articles section alongside fellow Mac-head Eric Erickson.

If you’re interested, please do go ahead and take a look!

I don’t have a single default browser that I use. I use both Firefox and Safari as my primary browsers (and I throw SRWare Iron into the mix sometimes too).

Of course, my primary OS, Mac OS X, requires me to pick one browser that is used by default when I click on a link in another application. The browser that I want to use for any given link will differ, however. I might have one of the two browsers open right now and want to use the one that is open rather than opening a new application, or it might be a potentially untrusted link, where I’ll want to use Firefox (with my restrictive NoScript configuration) rather than Safari.

Enter Choose Wisely. It is a small application which you set up with the browsers you might want to use. You then set Choose Wisely itself as your default browser. Whenever you click a link, it will pop open.

You simply click the browser you’d like to use on this occasion and the link will open as normal in your chosen browser. It is a really light, simple solution to this problem that takes no more than a second extra of your time.

Initial Setup

When you initially launch the application, there will be no browsers in the window. Go to your Applications folder in the Finder and just drag and drop the browsers you would like in the list onto the window.

You will also want to set Choose Wisely as your default browser. To do this, open Safari. In Safari > Preferences, go to the General divider and select Choose Wisely under Default web browser.

Conclusion

As I said, it is a wonderfully simple solution if, like me, you want to use different browsers for different tasks and on different occasions. Some will find it an annoying extra step — and if you’re happy with just the one browser, it won’t be any use to you at all.

But if you do like to pick and choose browsers on a per-link basis, this is a great solution. You can download it from this page (scroll down to the Download section).

This month marks three years since I purchased my white MacBook, my first Mac computer. Other than the AppleCare coverage stopping (good job they just replaced my battery, yay!), this represents quite a milestone in my technological life.

So I ask myself — objectively, why has the Mac become my primary desktop platform?

• Mac OS X is a Unix operating system. This has a number of advantages, but it mainly means rock-solid reliability (in theory at least) and a decent way to interact with the machine via the command line.
• It is elegant and put together with passion and care. Some bits of software, especially third-party driver and hardware support software for other platforms, aren’t. They are hacked together at the last minute and at low budget, just to work. Almost everything that ships with the Mac and a lot of third-party stuff for it is just done in this fundamentally different way of building stuff you would be proud to show off.
• It ‘just works’. Often dismissed as hyperbole, this marketing phrase more often than not is true on the Mac. There are notable exceptions and a few annoying things that you don’t get with generic PC hardware as well, but most of the time, you plug something in, or switch something on for the first time and it just does what it is supposed to.
• Generally speaking, you get what you pay for. Apple don’t make cheap computers. But neither do I think they make overpriced ones. You pay a premium price for an Apple computer, but you get a fair return for that price in terms of the quality of the product. Again, it comes back to the point about passion — Apple will not ship something that they are not entirely happy with, so what you get is something that meets their high standards.

Having said all that, I am still very interested in using everything and anything. While the Mac may be where my primary focus is on the desktop for now and the forseeable future, I am still very much interested in what is going on in the Linux desktop and Windows worlds and you can be sure I’ll continue playing with all sorts of technology in the future.

Here’s to the next three years of Mac — and perhaps beyond!

I just downloaded the new Google Chrome for Mac beta. I like to clear out my cookies after each time I quit the browser, so tracking information and so on doesn’t hang around any longer than it needs to.

On Google Chrome for Mac, there is no built-in setting to force all cookies to be session cookies, but you can use this hack to achieve the same thing. After launching Chrome at least once, then quit it and run the following commands in Terminal:

rm "~/Library/Application Support/Google/Chrome/Default/Cookies"
ln -s /dev/null "~/Library/Application Support/Google/Chrome/Default/Cookies"

The first command deletes the cookies file and the second command creates a symbolic link, so that anything dropped in the cookies file goes to /dev/null (i.e. the cookies gets deleted and not stored once you quit!)

UPDATE 2010-01-29: JeanVal reports in the comments that this process works on Chrome for Linux too. The Cookies file is stored at the path ~/.config/chromium, so just adjust the commands above to fit that path.