Category: Uncategorized

I like a nice, useful maxim. A pithy truth; something sharp and memorable and useful. They’re the building blocks of arguments and add an air of finality to proclamations.

This morning I woke up to a very polite note in my inbox from a friend of mine, linking me to some incredibly specious research by a company called Square X Labs who had demonstrated – with moderate fanfare – an apparent gaping flaw in Passkeys, leading to the conclusion that while the technology had promise it had inherent, terrible flaws that make it less than ready for prime time. This study – and its attendant demonstration – are, not to put too fine a word on it… well. I’m sure the good people at Square X are all very intelligent and industrious, so I’ll be generous and say that their conclusions are muddled, and not that they’re profoundly shoehorned into a world view that serves their overarching interest of selling security services for web browsers.

A less than generous take would be that this is a company that sells fire extinguishers in the lobby of a crowded movie theater, and that when they start yelling “Fire” while you’re in the second reel of “Freakier Friday” then you might want to pause and assess whether their motives are – just possibly – not self-serving.

This was the maxim I was going for. The whole fire-extinguisher-salesman thing. Yes, I know, it needs polishing. I’m workshopping some ideas. I’ll get there.

In a very, very simple nutshell, here’s how Passkeys work:

1. Passkeys work by generating a cryptographically strong (read “realistically unbreakable by modern cryptographic technologies) set of two keys – a Private key and a Public key.
2. You – the user – supply Face/TouchID as a component used to create those keys, making them unique.
3. Your computer actually generates those keys by taking input from you and your fingerprints/entrancing facial features, then stores the Private key.
4. The Public key goes to the Server of the service you’re authenticating too, so that essentially your computer and the server at the other end each have an individual piece of code that’s useless by itself and only works to do anything when it’s paired with the other piece.
5. When you go to access that server through a web browser, that web browser talks to both your computer and the server and generally handles the business of making sure that everyone gets the key that they need.

This is all very ingenious and works just fine, provided that nobody tampers with the process and does something to the one component in the above example that actually handles setting things up and telling both your computer and the server to exchange their keys. That part being the web browser, which, hey, whaddya know? Is sort of the crux of their entire, silly argument.

By creating a browser extension that sneaks in to the setup and use of keys – and then by installing that browser extension on your computer through social engineering (bolded/italicized for emphasis) it is possible to put a man in the middle of both the creation and use of a passkey, turning the process into this:

1. I want to make a passkey, so open my browser with its installed illicit browser extension.
2. The server I’m trying to make a passkey with tells the browser that it’s time to tell the computer to create a pair of cryptographic keys.
3. The extension jumps in there and makes its own set of keys. It also sends a call to part of the OS to make it pop up a window so that you can put in your FaceID/TouchID, but this is really just to make you – the end user – think that everything is okay, and the extension ignores that data.
4. The extension sends a Public Key to the server you’re trying to get to, and keeps the Private key to itself so that as long as you’re using that browser/browser extension then the server will be able to see your Private Key, match it with its Public Key, and you’ll be able to go and pay your electricity bill via online banking and be reasonable assured that interaction is safe.
5. Meanwhile, the browser extension is secretly sending your Private Key to its evil Criminal Overlord Masters so that they, too, can go and log in to your bank and drain your accounts and generally ruin you.

None of what they’re proposing is impossible. Nor, really, technically very complicated. But while they’re positioning this as an inherent flaw in the Passkeys system, I’d like to break out another maxim:

Hackers don’t hack. They log in.

That part I italicized earlier? That’s the part to pay attention to. If someone has created a browser extension explicitly designed to intercept the creation and use of Passkeys, they haven’t obviated Passkeys as a technology. If someone gets you to install that extension on your computer then that’s bad, sure, but it’s not indicative of a flaw in the Passkeys process. What they’ve done, simply speaking, is the equivalent of getting you to tell them your bank account details and then when you’re not looking, cleaning you out. They’re not hacking your accounts; they’re taking the passwords that you gave them when you cheerfully circumvented all the protections that you were afforded, and then they’re using them to log in and rob you.

So. What’s the takeaway here? Well, it’s not fun and it’s not exciting, but it is valuable, and it needs to be said and said clearly – Don’t Install Things On Your Computer That You Don’t Trust. Also? Don’t believe everything you read, particularly when the people who are telling you things are also selling you things…

Back in 2022, Apple released macOS Ventura and iOS 16, and at the same time announced that they were including support for Passkeys – an authentication technology that would eventually replace the tired, broken, venerable institution that is Passwords. A grateful world rejoiced, all conflict ceased and we danced in the streets, embracing our bright new future, free from the tyranny of having to remember complex series of letters and numbers in order to buy all the things we needed to buy back in late October 2022. Truly, it was those were the days of wine and roses; a halcyon period where all was right with the world.

Except, well, no. I mean, on paper this all sounded great; by using Public Key Encryption, people who provided services and products over the web would be able to allow people to sign into their accounts without ever having to worry about customers losing passwords, using insecure passwords like “Password123!”, and the ever-present, liability bugbear of vendors having users’ passwords leaked and traded on the Dark Web. What could go wrong with that? We were all ready to jump on that, weren’t we?

Again, no. Uptake on the technology was slow, and besides, we were all too busy trying to get global civilization back online in late 2022 – so as far as transformative technologies went, it wasn’t really what you’d call great timing. After all, we all had passwords and knew how to use them, right? And really – when you really got down to it – were passwords really that bad?

Yeah, okay, so, let’s talk about passwords…

Passwords are… good enough. The basic idea of a password is solid; a shared secret between both parties of a transaction, with the transaction contingent on that shared secret being accurately reported. Pre-internet, passwords were the go-to way of defining access to a information resource, whether that be your 1990’s college email account or your ATM PIN, which, yes, is really just a four-digit numerical password. The world – back then – was a happier place, but as I think we can all agree that the ceaseless, roiling nature of progress ruins everything nice and simple, they just won’t do any more.

People – and computers, sure, but mostly people are behind all that progress, so maybe it’s more accurate to say that it’s people that ruin everything. It turns out that most folks could handle having a secret word or phrase to memorize back in the nineties when all they had to worry about were one email account and maybe something they had to say over the phone to their bank, but I currently have… seven hundred and forty-two items in my Passwords.app, and it turns out that in a world where pretty much everyone who has more passwords than they have fingers needs to remember those wretched things, problems will creep into the mix.

People use simple passwords instead of complex ones (because who wants to try and memorize “iN765ku-!4228Llama” when “Password123!” is right there), and they re-use the same password over and over again (because if “Password123!” is good enough for their Amazon account then what the heck, might as well use it for everything, right?) Nor are vendors and the folks on the other end of those transactions blameless. In a world where everyone did the things they were strictly supposed to then no customer data would be kept or passed in clear text, everything would be encrypted, and no employee would ever fall prey to social-engineering attacks or phishing.

Using long, complex, random passwords solves some of those issues (see: 1Password et al, although I like Apple’s Keychain/Passwords ecosystem for its secure syncing between devices), but it’s clearer and clearer that we’re rapidly approaching a point where password authentication is functionally useless and teetering on the brink of obsolescence.

Multifactor authentication (either MFA or 2FA) is another decent stopgap; pairing something you know (a password) with something you own (a code generated by an app or an SMS message) or – better yet – something you are (a biometric authenticator like FaceID or your fingerprint) is a reasonable level of protection, but not a foolproof one. In a world where your phone can be cloned, or unlocked and stolen, or man-in-the-middle attacks are a possibility then there are ways to subvert that kind of protection or – with a good social engineering approach – simply find ways to get you to hand over everything just by deceiving you into thinking you’re doing the right thing.

All the above sounds terrible – and it is – but realistically your chances of having your password stolen/appropriated/hacked are statistically pretty low. Hurtful as it may be to say, very few people are worth the kind of complicated, detailed and well-planned attack that get the headlines in The Alarmist Weekly And Perilous Threat Gazette. Very, very few, in fact – but not none; it’s easy to tell yourself you’re successfully playing the odds, but as someone who has received a panicky phone call in the middle of the night from someone who needed to buy crypto so that his company could pay off their ransomware attacker after a hapless, well-intentioned employee inadvertently handed over their password I am here to tell you that nobody thinks this can happen to them until it does.

And this is where we get to Passkeys.

Passkeys work through Public Key Encryption, which is something I have repeatedly droned on at great length about to crowds of people in mid-priced hotel conference rooms throughout the continental United States. As the audiences who sat arrayed before me – usually checking their email but hopefully paying attention – were chiefly composed of very smart people who know a lot about these things (and, more particularly, as those people didn’t throw anything at me or boo) then I’m guessing that my opinions on the subject may not be entirely moot. Public Key Encryption is one of those things that’s hard to explain simply because describing the process of how it works is akin to telling someone – over a crackling landline – who’s never seen someone juggle before how to toss three chainsaws in sequence in front of a crowd of hemophobes, but the simplest way of putting it is probably this:

• The web browser and Passwords.app applications on my computer make a pair of nightmarishly strong, complex cryptographic keys that only talk to each other.

• One of those keys (the “Public” key) goes to the entity I’m dealing with. Let’s say it’s Amazon.com, shall we? Okay. Glad we agree on that.

• My computer keeps the other key (the “Private” key) and stores that in an encrypted form, and – as I’m using a Mac and sharing my passkeys through iCloud – synchronizes that with my other iCloud devices.

• The entity I’m logging in to only has the Public key. It’s a nightmarishly long cryptographic key that doesn’t actually have anything in it that clearly identifies me to anyone on its own. If someone were to go and grab that key, it would be useless junk data without the other half of the key that lives on my computer.

• Likewise, the Private key on my computer – if absconded with – doesn’t really point to anything about the intended target. Taken individually, each key is pretty much useless without the other.

• When I log on to Amazon to buy novelty cocktail napkins, my computer asks for biometric data (Touch or FaceID – or, if neither are available, my login password) and then it and Amazon communicate, pair their keys, and then allow me access.

…and that’s it!

Let’s walk through the process of setting up and using a Passkey. It is alarmingly simple.

1. Find something you want to create a Passkey for. There are lots of these, and you can find a good list of them here. I’m going to go with Github, so I browse to https://www.github.com, log in using my filthy, dirty, grubby, common-people password, then find the spot in my settings where I can add a passkey, thus:

2. I hit “Add a passkey,” and then my browser asks me if that’s really what I want to do. I tell it to Continue…

3. Now that I’ve told my browser – and by extension, Github – that I’d like to make a passkey, the ball passes to the Passwords app on my computer. As I already have an entry in the Passwords app for Github, it asks if I’d like to approve it going and getting those existing credentials and using them to continue making a Passkey:

4. And that, in a nutshell, is about it. When I want to sign into Github with my passkey, I’ll get to the regular sign-in window then hit “Sign in with a passkey”:

5. And, finally, will be prompted to sign in with either my computer password or – if available – my TouchID:

So! Passkeys are easy to use, conceptually not the most horrendous thing in the world, and we’re all living in a bright, clean future where passwords are a thing go the past and we’re all served breakfast by our household robots under a new and better sky. Right?

No. Sadly, that’s not the case; the thing is that passwords aren’t going anywhere anytime soon. As an authentication method it’s something that’s so massively widespread and that there’s such gargantuan infrastructure around that replacing it overnight simply isn’t reasonable or tenable. My Github account? I can log into it using either a password or a passkey, and realistically unless Github declares one day that it will no longer accept passwords then the real value that using a passkey brings to the table will be one of convenience – that a simple, easy passkey approval is quicker, simpler and safer than entering a username, password and optionally MFA code into a web site.

Still, there’s increasing support for passkey-only authentication. Some banks have removed passwords in favor of passkeys, along with a handful of utility companies and some tech companies – notably Microsoft, which now offers a passwordless method, and Google, who have gone passwordless for some of their services. More are likely to follow; after all, if I were a cynical man – and, let’s face it, I am – I’d say that the adoption of Passkeys as a technology is something heavily pushed by businesses simply because it vastly reduces their exposure to security issues. Who amongst us hasn’t received some invitation to join a class action lawsuit after the company we buy novelty cocktail umbrellas through has inadvertently leaked our usernames, passwords and credit card data to malicious entities? Not I, dear friends. Not I.

Ultimately, this is a sea-change in authentication (which is absolutely up there in the list of the Most Nerdy Tech Things I Have Ever Written), and it’s people who will drive that change. Yes, I know, I said that people ruin everything – and they do – but the only way that we’ll move wholly to this new approach is by taking a deep breath and embracing this new change and – hopefully – one day worrying about forgetting or losing your password will be a thing of the past…

Look, there’s no way of dressing this one up with a snappy title. Believe me; I’ve tried. No matter how I spin this, this is literally just a post about how to add a signature to your email in the macOS Mail.app. That’s it. Nothing more.

And yes, I know; it’s outwardly self-evident. You can go and open the Mail.app on your Mac, choose “Settings” from the “Mail” menu, choose the “Signatures” tab, then the “+” sign and enter any kind of lie you prefer into the field on the right so that you can attach said fiction to your emails, like so:

You can drag images in there, too – just grab the photo you want and drop it into that pane on the right, thus, so that anyone viewing that signature will know what you look like drinking coffee and eating quiche:

These are not difficult tasks to perform, and nor are they particularly controversial. No, dear reader, I’m talking about adding Proper Signatures™ to macOS Mail. Signatures that don’t show up as attachments to the recipient. Signatures that can incorporate more complex designs, and – more to the point – signatures that you can change after the fact.

That last one is something that maybe involves a little explanation, because on the immediate face of things you might not see the value in being able to change your email signature long after you’ve sent the email out and someone has read the thing. It’s okay; I get that, but there are times when this might be a valuable thing to be able to do. Consider the following:

1. You have recently moved your physical business address to a new location. Your old address was contained in your email signature, and to avoid confusion, it would be great if anyone who you’d sent an email to in the past could just look at that old email and magically have your address change in the signature of that old email to accommodate the new changes.
2. You’ve changed your company logo, because the old one was a ghastly shade of blue, and warmer tones are the thing these days. Also, the old one was hard to read and generally ugly, because you are an IT professional and not a graphic designer. And you lack taste and compunction. You’d like to expunge that dreadful old logo from everyone’s email, so that they’ll forget your regrettable choices, you frightful rube, you.
3. You’ve added new certifications that you’d like to crow about, and want everyone you’ve ever sent an email to to see those new certifications so that they know precisely what a clever, clever boy you are.
4. The gigantic industrial titan you’ve tied the entire existence of your business to has subtly shifted the branding guidelines that you – as a partner – are required to use, and if you don’t make changes sharpish then they are likely to get… tetchy. Best not have the old branding out there, old boy. Their lawyers shoot to kill, and they never miss.

…and the list goes on. You changed your phone number! Your social media links! Or, in a more fun example, it’s a national holiday and you think it would be fun to have a giant heart, box of candy, turkey, or festive tree in your signature! Honestly, there are – if not countless – a lot of reasons to want to be able to make those changes.

Handily, there’s a way to do all of the above in a way that requires, okay, a little tinkering, but isn’t wildly difficult. It does, however, require you to have a little ability with writing html, and a text editor. And even if you have neither of those to hand, figuring out the intricacies of the thing are not totally insurmountable.

When you create a signature in macOS’s Mail.app, the application writes that information into a .mailsignature file that is – to all intents and purposes – a tiny little web page. The reason it does this is that most email applications in the world are capable of rendering web data into email messages (see: every piece of junk mail you’ve probably ever received that includes an image), and rather than use some exotic formatting that everyone in the world who isn’t using Apple’s Mail application can’t see, churning out something that everyone in the world who isn’t using Apple’s Mail application can see seems kind of a logical gimme. You, of course, don’t get to see the formatting of that tiny little web page because good grief, a wall of code isn’t something that most people get very excited about – but it’s there, nonetheless, hiding on your computer in your ~/Library/Mail/V10/MailData/Signatures folder.

Note: If you want to open that location without a lot of tiresome clicking and peering at folders, just choose “Go To Folder” from the “Go” menu in the Finder, copy/paste this into the field that pops up, and hit Return: ~/Library/Mail/V10/MailData/Signatures

Inside that folder you’ll see – depending on how many signatures you have – a collection of .mailsignature files with creative and memorable names, like, ooh, 8B455FC0-3043-4B60-9846-4DA43442CC5B.mailsignature. You can open them with any text editor, including the built-in TextEdit application (although I like to use CodeRunner because it’s just super cool, and so am I). Opening the quiche-eating signature I made earlier will give you something like this to look at:

…which, to the untrained eye, looks moderately terrifying, admittedly. Still, it follows the conventional html formatting standards – except for the handful of lines at the top that tell the recipient’s email that this is an emailed signature and should be treated as such:

So, this is all well and good, but how do you turn any of this into something functionally useful?

I’m glad you asked. Websites, as I’m sure have noticed by now, have a lot of stuff in them. Lots of formatting, tons of text. Images, videos, what-have-you – but, a website can be super simple. It can literally just be one image. You can, in point of fact, just have a tiny little web page that contains a single table that in turn contains a link to an image that you host on your website – and if you change that image, then every time someone looks at your signature, your signature goes out to the linked address in the tiny little web page and pulls in whatever image is there.

Let’s put it this way: if I decided to finally stop doing IT consulting and instead switch careers and embrace what I’m assuming is my true calling – i.e., taking naps and eating breakfast at every meal – then I could start a business that opens a series of breakfast restaurants that – let’s face it – will inevitably collapse and ruin me utterly.

I’d call it, say, “Breakfast Creations, Incorporated, LLC”, and rather than go and start a whole new company every time one of my terrible breakfast institutions fails horribly, I can keep the same over-arching company and just go onto my web hosting platform of choice, then find and switch out the signature logo I have hosted there with the logo for whichever new, bright idea I’ve had in the breakfast space. That way, anybody who looks at my old emails will always be presented with the logo for my current doomed breakfast endeavor in the hope that this will drive at least a little business to my flailing, sinking abortive breakfast empire.

All I’d have to do is create an email signature like this:

…and switch out a new .jpeg file called "Logo.jpg", replacing the prior "Logo.jpg" with that new one, and thus, simply by changing a single file on a single web server, every email that I had ever sent from that domain would automatically open to show the latest .jpg file, thus:

(The above are actual screenshots, where the only thing that changed was that a different copy of the "Logo.jpg" file got uploaded to the web server that hosted the domain. No photoshop legerdemain or general-purpose trickery was involved in this exercise)

The general procedure is simple enough.

Firstly, you’ll need a website – or at least, a place where you can store things on the internet that is going to be accessible by the world at large. It doesn’t have to be a website, but yeah, let’s face it, it’s probably going to be a website.

Secondly, you have to have the .mailsignature file written and configured, which is something that involves a few steps. To whit:

1. Open Mail.app. Go to “Settings” from the “Mail” menu, choose “Signatures”, then create a new signature.
2. Quit Mail.app. This is an important step – if Mail.app is open while you’re moving and editing signatures then it will probably write over the things you’re doing and ruin all your good work.
3. Open ~/Library/Mail/V10/MailData/Signatures, and locate the .mailsignature file you just made.
4. Open that with your Text Editor of choice.
5. Make the changes that you want to make to the thing, leaving the top section of the file unchanged (Content-Type, Message-Id and Mime-Version). You can use my example above, although if you have the services of someone who is more competent with html to hand (and let’s face it, I’m a muddler at best), then have them do that.
6. Save the file.
7. Lock the file. Click on it in the Finder, Get Info on it, then check the “Locked” button. This is another important step that – if overlooked – can overwrite your changes.
8. Open the Mail.app and test your new signature.

Third, and finally, remember that as what you’re emailing out to people as your signature is – at root – a tiny web page that goes and looks at the internet every time someone looks at it, it’s important to remember that if you ever change your web host then you should pay particular attention to where your new web host puts your files. You can, after all, change your website at any time you like – but you can’t change the tiny little web page that you’ve sent everyone you’ve ever emailed…

Oof. Been a minute, hasn’t it? Still, what’s eighteen months between blog posts, eh? I mean, yeah, it’s eighteen months, but then again I have friends and family that I like to put on a two-to-fifteen-year face-to-face rotational, so the fact that I’ve let this thing slide for the better end of a year and half is both probably on me and also not bad by my personal, very lax standards.

Still, I only seem to have time to work on things like this when I have gaps in Actual Client Work™ that I am actually doing for Actual Clients™, and there’s been a lot of that of late which – let’s face it – for the freewheeling independent IT consultant can only be a good thing. Once in a while, though, I come up for air, look at this thing, and try and think of something useful or interesting to jot down, and this is one of those times.

Today, Gentles all, I am going to write about how to spend a lot of time in order to save a little time and not a lot of space. I am going to talk about archiving.

Businesses bloom, and business expand, and then now and again, businesses wither away. Often by design; after, say, designing reticulating sprockets for forty years, a reticulating sprocket-designer has had enough and wishes to jack it all in and go and sit on a beach and never think about flanges or fittings again, and this is a fine and noble state of being. Still, the market for things that attach to other things and also turn around continues apace, so businesses or clients are sold as assets, taking with them all the assorted data and debris that those clients have accumulated over the years, which takes me to my current discussion of What To Do With All That Data.

Some data is relatively small. If you added up forty years of Mac text files – going all the way from the initial version of WordPerfect back in the 80’s to land somewhere in the recent Office365 incarnation of putting-words-on-a-screen, you might reasonably expect to have a healthy handful of gigabytes – but probably not more. Text files are, by-and-large, small and uncomplicated things. Large CAD or design files, however, can cheerfully run into the healthy-handful-of-gigabytes range, and forty years of that kind of stuff gets… pretty huge. If you’re talking about a couple of dozen client directories with that kind of amount of data then you’re talking about some serious numbers in the multiple-terabyte range.

“So?” I hear you scoff. “Modern hard drives can handily accommodate that scope of data.” You are, of course, right about that, but the waters get muddier when you start to consider that due to the sensitive (cough, secret, cough) nature of some of these client files, there are some requirements for compressing and encrypting that data before storing it.

Enter my favorite place on the Mac: the relatively obscure toybox of /System/Library/CoreServices, with a special shout-out to its attendant subdirectory – Applications. Let’s take a look at that, shall we?

Truly a treasure trove of delights. This folder is a place where the OS dumps applications that it needs to break out now and again, but that don’t necessarily warrant a spot inside the regular Applications or Utilities folder. Some of them used to live in the regular Applications or Utilities folders, but have recently been shunted to this sort of dusty shelf full of lost toys (I’m looking at you, Keychain Access. I know, I know, you didn’t deserve this). Some are just there because they’re so rarely used that putting them under people’s noses would just be annoying. After all, how often do you want to fire up the Expansion Slot Utility if you don’t have a computer with Expansion Slots? And while the Ticket Viewer is handy for working with Kerberos, the vast majority of Mac users have never heard of a Ticket Granting Ticket (or Kerberos) and are – quite frankly – all the better off for that.

Still, a couple of those things are absolutely worth knowing about, and while I can wax on for another handful of paragraphs about the splendor that is Directory Utility, let’s stick to the task in hand, which is archiving, and thus handily addressed with the appropriately-named Archive Utility. Here, drink the icon in, in all it’s glory:

The Archive Utility is separate and distinct from the Finder when it comes to making archives. Oh, you can just right-click on a folder or file in the OS and choose “Compress”, and that’ll make you a nice, neat .zip file after a little while, which is all well and good – but it won’t do much more. And it’s sloooow.

Here’s an example – a relatively small 22GB folder containing a mixture of text documents and executables, compressed using the Finder as a regular .zip file. The CPU Usage chart is shown to demonstrate that the CPU itself is barely ticking over – the six bars on the left represent the six Efficiency cores in my M3 Pro MacBook Pro (the dual “Pro” name is ridiculous, I know), and the six bars on the right show the Performance cores.

As the Finder’s approach to running this compression is to use what appears to be a single-core process, it doesn’t leverage the full potential of the CPU, and this takes a… long time. Five minutes and forty-four seconds, to be precise. It’s also not encrypted, which isn’t ideal. Happily, Archive Utility has some ideas about that.

When fired up, Archive Utility doesn’t give you much to look at, but if you choose “Settings” from the “Archive Utility” menu, you get this tasty little snippet:

I will draw your attention to “Apple Encrypted Archive”, because that’s what we’re going to play with. Select that, then hit Command-K or choose “Create Archive…” from the File menu, select your directory, and it’ll pop up a window with a pre-filled Password key and an option to store that password in the Keychain. I advise you to this – or at least note that password – as it doesn’t appear to be editable. Apple’s attitude in this department seems to be that they’re doing all the work here, so if you don’t like their passwords then you’re perfectly welcome to not use them, so… there. Anyway:

Hit “Encrypt” and then – if you’re me writing this – frantically move things around to take a screenshot because the Archive Utility isn’t restricted by the ridiculous concept that you might want your computer to use one (1) of it’s cores to run this task, when you can use all twelve (12), and you have a limited amount of time to get said screenshot because this entire operation takes nine seconds.

Nine seconds. Nine. As opposed to Three hundred and forty-four. That’s, what, thirty-eight times faster? Give or take?

“Now,” I’m sure you’re saying to yourself, “that’s great, but does that really warrant a whole blog piece?” I’m going to argue yes – because this test folder was twenty-two gigabytes. The Actual Client’s™ file folders? There are upwards of two hundred of them, and the smallest one is a hair over six hundred gigabytes – which Archive Utility was able to handle in four minutes and fifty-two seconds. Compressing this using the Finder? Two hours, eighteen minutes and eleven seconds.

Thankfully, I am not required to be the person sitting at the desk, packaging up and compressing and encrypting those files. Well, okay, sure, that wouldn’t be the worst thing in the world because for this kind of thing I’d charge by the hour and that new Rivian looks cool, but you get my point. With the volume of data we’re talking about, using Archive Utility allowed the client to have someone sat at a desk with a Mac Studio and get the entire job done in two full work days. Extrapolated out, using the regular Finder utility would have eaten up somewhere around fifty-eight work days. Fifty-eight.

I don’t know about you, but that seems like a tool that should be taken down from the shelf, dusted off, and put back into your regular rotation…

(PS: See you all in another eighteen months. Maybe.)

A few years ago a friend and colleague of mine passed away. This isn’t surprising because he was around my age and, well, I’m hanging on to forty-nine by a margin of mere days, and the further you creep away from the middle-point of your allotted three-score-years-and-ten the more intimate your relationship becomes with the actuarial tables and the inescapable fact of your own, ultimate demise. I mean, I don’t want to be a downer here, but as William Shatner pointed out in 2004, you’re gonna die, and there’s no sense in getting all bent out of shape about it.

Still, that’s not to say that the prudent course of action is to embrace the futility of existence and go gallivanting off toward the great hereafter with an affect of gloom and futility. After all, you may be dead – sure – but there are a few things you can do to make the whole unpleasant business of your departure from this tawdry earthen firmament easier and simpler for you and yours. My wife is an attorney who does a good amount of estate planning work – chiefly laying out the dispersal and disposal of physical goods and financial instruments once the offending party has joined the choir eternal etc. That’s important work in my book, and my side of the street (chiefly composed of the dispersal and disposal of ones and zeroes) kind of pales in comparison.

Still, how said dispersal/disposal can be executed isn’t as cut and dried as we’d like it to be. There’s no simple, one-size-fits-all approach to neatly wrapping up a digital identity. Sometimes that can be dealt with quickly and easily, but other times? Yeah. Not so much.

This is all a roundabout way of getting to the thing that’s annoying me today, to whit: that Twitter keeps trying to tell me that I should check out what my dead friend is up to these days, and it’s low-key upsetting to have this reminder pop up on what is now becoming a semi-regular basis. I mean, I went to the man’s funeral and wore a suit and made awkward conversation with colleagues, and thus I’m pretty confident that I know what he’s up to (i.e., not much). Of course, Twitter doesn’t know that (and is currently tip-toeing around its own mortality), and because my friend’s family don’t have any of his passwords or access to his digital credentials there’s really no easy way of persuading Twitter to quietly put that account on ice, remove it, or generally stop rubbing his now-prolonged lack-of-existence in everyone’s faces.

Last year another friend of mine died in a car wreck, leaving behind a broken iPhone (wiped by having the wrong passcode entered too many times by person or persons unknown), a locked PC, an Android tablet, and an unknown AppleID password. I was able to help his family recover most of his data (including passwords), although the process was best described as fiendish and torturous – a teetering edifice of linked accounts and two-factor codes assembled in the right order to get to a point where his Apple ID could be unlocked, read, his data exported and then finally wound up. Apple was less than helpful – while they have procedures in place to dissolve Apple IDs and iCloud accounts those procedures involve sending them proof of death in the form of a death certificate, power of attorney, and possibly letters testamentary, as well as many weeks of waiting.

Meanwhile, emails go unanswered, bills go unpaid, services get shut off. In my dearly departed chum’s case, he had a thriving seasonal business with a lot of customers who had no idea what had happened to him or their money, resulting in an ever-growing snowball of angry phone calls that went to inaccessible voicemail and stern notes from attorneys along the lines of we’ll-see-you-in-court – which, considering his physical and metaphysical disposition at the time, would have been really quite an achievement.

The thing is that there are few if any widely-established and accepted methodologies that are recommended and deployed for dealing with what happens to a person’s data after they die. The people themselves? There’s religion and the legal system for that, but their data? That’s trickier. In the past I’ve suggested to clients that a viable option is to write a letter; leave a note for your loved one(s), laying out your accounts, passwords, and optionally printing out two-factor recovery codes for services that offer that as an option. It’s an approach that’s not without serious issues – for one thing, you have to keep that letter updated every time you change a password, and for another there’s an inherent security issue in writing down the keys to your entire digital life on a piece of paper and leaving that lying around your house. It can get damaged, or fall into the wrong hands, or just plain be overlooked. If you have the means and the inclination, you can put that letter into a safe deposit box – and I know a few folks who’ve done this. The caveat to that is that your bank or financial institution of choice is probably only going to give your heirs or survivors access to that after probate has been all tied up (which can take… a while), so you should make sure that at least one other person is authorized to open that box.

Tech companies traditionally do not care particularly about these kinds of problems. Dead users are, after all, still users – that six months you spend trying to cancel your loved ones’ account? That’s six months of income requiring zero work or expenditure of resources on their part. Look, I get it; it’s an ugly and cynical thing to have to write that, but it’s nevertheless the truth of the matter. We’re used to tech being aspirational and enlightening, but at the end of the day these are commercial enterprises that talk a good line about Not Being Evil or Thinking Different but don’t necessarily take that kind of thing as a mission statement. There’s no point getting bent out of shape about that, but it’s important to remember that ultimately most large tech companies regard their users as a monetized commodity – and that’s okay, because to cut a long story short That Is How We Can Have Nice Things.

Apple at least has a tool to streamline the process of unwinding the affairs of the departed, allowing you to create what they’re calling a Digital Legacy; a way for your surviving nearest and dearest to unlock your Apple ID provided that you – the dearly departed – have allowed specific people access to your Apple ID and that they have a copy of your death certificate. With that in hand, they’ll be able to recover pretty much everything except keychain data and payment information. Further, Activation Lock will be disabled for your devices.

None of this is terribly exciting. Not compared to some other tentpole features of Apple’s products. Digital Legacy isn’t what you’d call glamorous or cool – and it’s nothing new; it’s more a streamlining of an existing process, designed to make something frustrating and annoying a little easier at a time when people have reduced bandwidth for frustrations and annoyances. Further, it doesn’t give access to password or keychain data, which – if you’re a hardcore keychain fan – might cause some headaches.

The problem with being a person who professionally handles disasters is that folks in my field skew toward the worst-case scenario (after all, shockingly few people call IT consultants for a chat because everything is running perfectly). In an age where so much of our lives ends up being insubstantial data we become – in effect – custodians of our own and other peoples’ legacies. The tools we have at hand for that kind of purpose are imperfect at best, and just to be clear, I don’t think that something like Digital Legacy is a perfect tool. It is, however, a huge improvement over anything else currently extant and also probably good enough for a lot of people.

After all, the things we leave behind that are of the most value aren’t passwords and numbers and credentials. Sure, those are handy to have if you’re tidying up your loved ones’ affairs, but the absence of that kind of information is mostly just annoying and inconvenient. Digital Legacy doesn’t service that kind of need, but where it excels is in allowing you access to personal data, which is the kind of data that your loved ones really want access to – photos, documents and email.

I have never really had a lot of time for Social Media.

A long, long time ago when I worked at Command Prompt my partner and I created all the things that you’re supposed to create in order to hit all the commonly-accepted business touchstones of the modern age; a company Facebook page, Twitter accounts, a few other bits and pieces of assorted nonsense. I tried to get into it – I really did – but at the end of the day it was a toolbox that I had no interest in. I could rant at length about my specific beefs with the whole enterprise, but while I’d very much enjoy indulging in that I’m also keenly aware that this sort of behavior falls into the general bucket of Old Man Complaining About These Kids Today, and honestly, nobody needs another tirade in that general vein. I’ll merely confine myself to saying that Social Media is all about connecting people with other people, and that pretty much all people are just ghastly and generally awful, and probably shouldn’t be connected with each other any more that is absolutely necessary, and even then we should probably cut back on that as much as possible, you filthy, filthy animals.

(Not you, gentle reader. You’re great. No, really.)

When Command Prompt later dropped most of its Social Media presence I was enormously relieved. Even later, when I jumped ship leaving the whole shebang in the possibly-far-more-competent hands of my cohort, I tried to delete my Facebook account without a lot of success, and have mostly just decided that ignoring it and losing the password for it is the most prudent and sensible course of action. I kept a Twitter account going because in a global pandemic it was a useful thing to have access to (so that I could find out where to find toilet paper and peruse new and creative things to make with gin and the dwindling contents of my fridge), but now that Twitter seems to be lurching drunkenly to an uncertain terminus I – and apparently a lot of other people – have started wondering whether Mastodon might not be a credible alternative.

Mastodon seems to have garnered a reputation for being intensely complex, but I’m not sure that’s a well-deserved criticism. Unlike monolithic… well, monoliths like Twitter or Facebook or Instagram or what have you, Mastodon instances exist as a network of smaller servers that can be run and administered fairly simply by individuals or small groups. If Twitter is some doomed cruise ship going down in stormy waters, then Mastodon instances are a vast flotilla of small fishing vessels, rafts, lifeboats and yachts that folks can jump onto.

Actually, as metaphors go that’s pretty apt; the experience of using Mastodon is a broadly similar conceptual experience to using Twitter but with small differences, compromises and inconveniences that can be worked around if you’re willing to be reasonable about the whole business. If you’re being rescued from your burning, sinking cruise ship (a large, metal contraption that floats and travels on the water and allows you to store some of your stuff) then jumping onto a fishing boat is going to be a broadly similar experience (a smaller, wooden contraption that floats and travels on the water and allows you to store some of your stuff). If you’re content with those basic qualities then you’ll be fine, but if you’re expecting shuffleboard, a buffet table and wet bar in your room then you’re in for a rude awakening. Also? Fish.

Setting up your own Mastodon instance is moderately complicated, but not unrealistically so. You’ll need the following:

• A domain name – so that the world at large can find your Mastodon instance.

• A Virtual Private Server (VPS) – so that you can have a virtual server that can hold and execute the code required to operate your instance.

• An Object Storage provider – something AWS storage-compatible seems to be the ideal solution so that you can have a place to store media, images, and data that you and your users might upload to the instance.

• Some kind of SMTP service – so that you can send email notifications to users. (Note: you can use your existing SMTP servers, but that’s a bad idea for lots and lots of reasons. Fortunately a brisk and concise googling can probably find you other options in the SMTP provider space.)

So, four things. The domain name is simple enough – simply sign up for something apt and pithy with the domain name registrar of your choice (provided that they offer some kind of basic DNS configuration, that is). The SMTP service can be dealt with inexpensively by Postmark (my personal favorite), and while there are many options for VPS and Object Storage I’d counsel looking at Digital Ocean because they’re price and feature competitive and offer a simple, one-click Mastodon install.

I’m going assume that you went with Digital Ocean – because that’s what I use for my VPS stuff – and because they offer a blow-by-blow, easy-to-follow setup procedure that you can work through while drinking your Lapsang Souchong and humming happily to yourself, content with the world as you ponder your career as a Burgeoning Social Media Pioneer™. Congratulations!

Except, no. No, no, no. A thousand times no, you poor, muddle-headed nincompoop.

What were you thinking? Didn’t you read the title – you know, the thing in big letters at the top of the screen, about how setting up a Mastodon instance was a – and I quote directly – “terrible idea“? No. No you didn’t. And now you’re doomed and probably going to prison for a hundred years. Maybe longer. Probably longer.

You see, the thing about being a Burgeoning Social Media Pioneer™ is that there are responsibilities and considerations that are easily glossed over or just plain missed. I mean, Twitter is like an iceberg; two-thirds of the enterprise are under the water and doing things you don’t see (and now that – as of the date of writing this – Twitter has disposed of most of those people that particular iceberg is looking pretty shaky). That’s the stuff that keeps the thing afloat, and unless you know what you’re getting into, you too might sink. Don’t believe me? Okay, let’s see…

Firstly, you’re going to have to start thinking about the Digital Millennium Copyright Act (DMCA) and how that’s going to impact you. I mentioned up top that Social Media users are ghastly and awful, and yes, that might have been a little presumptuous, but there are definitely bad folks out there. Let’s say – purely for the sake of argument – that @joeschmo@mastodon.mycoolserver posts a link to a pirated stream of Marvel’s next big movie. That’s bad, but you’re protected from liability for any copyright violations that your end users might carry out provided that you’re registered with the U.S Copyright Office, and that you’re provided them with a Designation of Agent to Receive Notifications of Claimed Infringement. Oh, and if you’re checking those notifications and don’t dawdle about pulling copyrighted content off your instance as close to immediately as is humanly possible.

That’ll cost you less than ten bucks a year, which, okay, it isn’t bad. What might edge it into bad territory is that details of said Designated Agent are publicly available, so unless you’re cool with your name and home address being out there for all to see, then you might want to consider a P.O. Box, which will be… well, it’ll be more than ten bucks a year, that’s for sure.

Of course, the smart move would be to incorporate as an LLC so that you have a legal entity between you and the roiling, lawless barbarians of humanity as they try to ruin you with the fruits of their sheer petty-minded greed, moronic tribalism and general dreadfulness. I can’t speak for other states, but in California that’ll set you back eight hundred dollars a year, with additional filing fees. Make sure you pay the bill on time, too; while everyone I’ve ever talked to at the California Franchise Tax Board has been genuinely pleasant and understanding, the FTB is not renowned for its institutional mercy or sense of humor. Oh, and you’ll probably need a discreet taxpayer ID too (which you can get from the IRS, and it’s really saying something that getting a thing from the IRS is the simplest, easiest and most enjoyable of the remedies you’re going to have to slog through).

Once you’ve got that out of the way then you should take a long look at your liability. If your LLC name is on your instance (which, y’know, it should be) then you’re going to have to think long and hard about liability insurance. Apple makes its Consultants carry a couple of million dollars’ worth of insurance, and you’ll probably be in for the same. You’re probably looking at about a thousand dollars a year, give or take. Make sure any legal fees are covered by your policy. Still, that’s all you have to do.

Oh, wait, it isn’t. You should also register with the National Center for Missing & Exploited Children because while you really, really hope that nobody on your instance is posting CSAM then playing catch-up with your duty to report post-fact is a deeply, potentially life-changingly and ruinously problematic place to be. Oh, and if you or any of your users are operating in the EU then you should probably have a handle on your GDPR responsibilities and obligations. If you’re operating in other, non-EU countries then I would strongly recommend consulting qualified legal professionals to check up on the laundry list of additional items you’ll need to work your way through.

Here’s the thing about Social Media; it’s a bad, bad thing. It elevates every level of discourse – good and evil – and puts a megaphone in the hands of every unhinged do-gooder or psychotic crank, ensuring that they’re always a little louder than the regular user who only cares about cute cat videos. But there’s a difference between something like Twitter and something like Mastodon; the former is a platform, and the latter is a protocol. Starting your own Mastodon instance seems like starting, say, a Slack channel, or (for those of us old enough to remember) a BBS or newsgroup, but the practical reality of the thing is that Mastodon is just the means to the end of creating a platform – and isn’t a platform unto itself.

At the end of the day, there are responsibilities inherent in owning that platform – and they’re responsibilities that are severe and inflexible. If you know what you’re getting into, and if you’re willing to take those responsibilities on? Good luck to you.

If you’re not, then… well. Good luck.

Look, I don’t mean to brag. I really don’t. I’ve been doing this weird job for a very, very long time now, and the point at which getting professional accreditation was something to crow from the rooftops evaporated a couple of decades ago. Honestly, being able to show the word at large that I’ve passed this year’s Apple IT Professional exam seems sort of akin to making a big deal about my birthday or something. I mean, both come around once a year, both are occasions that calls for a rueful smile, and both are things that are baseline expectations that can’t be avoided and that I’d far rather not draw any attention to.

Still, here you go. Now I have this weird-looking badge to put on my website, and a link that I’m supposed to post so I can show how clever I am. Feast your eyes upon it while I go put together a hasty ticker-tape parade:

I’m back. Wasn’t that something?

If they’d actually sent me a real badge that I could look at and lose in a drawer somewhere then that’d be something else, but no – a .jpg is all you get. And you do rather have to jump through hoops to get one of these, which is really the meat of my thesis today.

Back when I was a lad and the world was dewy with promise, Apple would make professional certification a prerequisite for enrolling in the Apple Consultants Network program. Which made a lot of sense – after all, me and mine go into homes and businesses as sort-of-brand-ambassadors, and if we’re clueless, ham-fisted brutes and break things then that makes Apple look bad (and Apple really, really does not like looking bad). These certifications were designed and written in-house by Apple, and they were pretty challenging material, by and large. You’d go and read a heavy, interminable, thousand-page book and sit down for a test with a real-life proctor who’d glare at you for two hours while you did your own tech support because the test-taking computer was broken, and you’d pay a few hundred bucks for the privilege. It was like being back in college, but only in all of the worst ways.

Every time Apple came out with a new OS you’d go and repeat this procedure, which resulted in a lot of people of my age and stature (metaphorical grey-bearded, tangibly rotund) accruing impressive-looking bookshelves stuffed with impressive-looking volumes that were always fun to leave lying around so that visitors would be constantly reminded how clever you were. Which is, let’s face it, the point of books in general.

A few years ago Apple started to shift that model; wanting to bring more people into the fold they deprecated the old, Apple-oriented qualifications and instead took on a raft of well-respected third-party qualifications – which made sense because while all those impressive tomes were stuffed to the gills with the interminable things about Mac OS X Kernel Extensions they didn’t talk a lot about some practical things like network design or general IT best practices. The Apple qualifications waned, but now they’re back, and getting one is a demanding procedure. Not because the material is unusually horrendous (although, again, I’ve been doing this for a long time and most of it is pretty burned in by now), but because actually taking the test represents a feat of strength and character that beggars belief.

The exams themselves are run and hosted by PearsonVue, who are doubtless well-intentioned but probably over-stretched and infrastructurally-challenged. Out of the last four exams I’ve taken with them, three of them have crashed. Three. Out of four. As in… I’ve been sitting there for the better part of an hour, am rounding the post toward the end of the test, and all of a sudden everything locks up and I’m either dumped out of the testing software (which takes over your entire computer), or forced to sit there while the timer counts down to zero and ends the test with me, gnashing my teeth and howling.

One time I managed to talk to a proctor, who told me that the test crashed because I was cheating, and insisted on my picking up my laptop and carrying it around the room until I’d proven to his satisfaction that no, I didn’t have someone there feeding me the answers and no, I didn’t have any of those thick-and-impressive looking books lying around, and no, I didn’t have the manual page for the assetcachemanagerutil command tattooed on my arm. Further, I could kind of understand the accusation if the proctor – who watches you through your laptop camera the whole time to see if you’re stealthily looking over at your phone – thought that any mischief was afoot – the crucial difference here was that his opinion was that the exam had seen me chewing my lip and muttering and then decided that something was awry, and that the appropriate action was to promptly and autonomously Put A Stop To All That Nonsense, Thank You.

Another time they told me that I’d been staring so long at the screen that the exam had assumed that the camera had crashed and so had ended the exam early. Which, okay, rude, but on the other hand yeah, I do tend to look off into space when I’m reading a question that simply says “Where can password?”. I mean, that thing is missing at least one verb, so I figure PearsonVue and I should probably split the blame on that. Actually, the hell with that; what kind of software takes a look at someone and decides that they’ve been still too long and that means it should quit? After all, I could have been in medical distress. I could have been dead! They could have at least… I don’t know. Coughed discreetly or something?

The last time it crashed I spent the better part of an hour on hold in order to talk to a very nice young lady, who made a case number for me and referred me to a department that didn’t exist. When I called her back the next day she – bless her – told me in the kind of voice that has caps in it that She Was Not At Liberty To Tell Me My Test Results, and then indulged in a lot of meaningful coughing and hint dropping to the effect that she could see that even though the test had croaked before I’d reached the end, I’d comfortably passed the thing. Which was rather nice of her, if I’m honest.

So, huzzah? Let’s go with that. Huzzah. I have new professional certifications and can prove to the world at large that I’m not an utter imbecile, and there’s a full three-hundred-and-sixty-four days until I have to do this all over again. Maybe the badge will be a different color next time.

Yeah. That’ll make the whole rigmarole worth while.

That’s it. I know we’re only a couple of months in, but I’m going to call it: Ladies and Gentlemen – 2022 sucks.

It’s not a controversial position that the twenties have demonstrably shown themselves deficient in almost every single aspect – but rather than enumerate a list of woes (that we’re probably all deeply familiar with anyway) I’m proposing we take positive, proactive steps to improve our general lot. I urge you – yes, you – to join me on a ride on the Nostalgia Express to a carefree, innocent time where life was simple and you could go out in public dressed like a toddler and people would nod approvingly and commit to the general consensus that you looked just super-rad.

Hell, let’s go back to a time where you could unironically use the word “rad” in a sentence, which narrows the field down considerably to the greatest time to be alive that has ever existed, which is, of course, the mid-nineties.

There are, I’m sad to say, people who subscribe to the notion that the sixties or seventies were pretty great, and if you number amongst that throng then I’m sorry, but you’re terribly, terribly wrong. I wasn’t around in the sixties, but by all accounts it was a decade with deeply problematic social issues and a lot of people standing around naked in the mud, scarfing down military-grade pharmaceuticals while in possession of questionable hairstyles. I was around for the seventies (albeit as an infant), and chief amongst my recollections were disco, plaid, chain-smoking, lead gasoline and a lot of people wearing clothes that looked like someone had inexpertly gutted and skinned a couch or set of curtains and then everyone else in the world looked at that fashion statement, looked at each other, remembered how dreadful the sixties had been vis-a-vis standing around high and naked in the mud, and sort of shrugged and decided that velour jumpsuits had to be some kind of improvement on that, so the hell with it, why not?

No, the nineties was where it was at. Don’t take my word for it – ask Brian Durkin:

I mean, come on. I’m not even kidding, here – I was never and will never be as cool as Brian. Look at him!

Brian is the study of a man living his best life, here. He’s about twenty, rides a cool skateboard, has great shoes, looks like he was either shrunk down overnight or all his clothes magically expanded, and is holding what I’m assuming (because it’s 1996) is a PowerBook 150 – the last of the classic 68k PowerBooks. The reason he’s doing all that is because he’s part of Apple’s “What’s on your Powerbook” print advertising campaign, which featured movers and shakers and cool people (like Brian) holding up their computers and listing off all the cool, mover-and-shakery things that they were doing with those computers. There were fashion correspondents, movie executives, business people, Todd Rundgren (in an amazing banana-yellow power suit), all showcasing the amazing things that people you might admire or aspire to be (again, like Brian) were doing with their PowerBooks. We like to assume that Apple set the high bar with it’s famous “1984” commercial and then capped that off with the “Think Different” and “I’m a Mac” adverts, but I think that this campaign was brilliant.

Sadly, the “PowerBook” moniker is gone and replaced with the somewhat saccharine “MacBook” appellation, but the question still crops up in a far less interesting and far more frustrating permutation in that it involves people fretting over data and not looking cool on a skateboard. You see, instead of publishing a bunch of adverts in a bunch of probably-now-defunct periodicals, Apple has helpfully rolled that into a convenient and only slightly frustrating graphic built-in to the operating system, thus:

It would be fun if you could actually see a list of the specific items you have on your computer, but on the other hand the PowerBook 150 topped off at about a hundred and twenty megabytes of storage, compared with my MacBook Air’s two terabytes (which is, for those of you who don’t want to go and find the calculator app, about 1.65 million times more space). The list would be… well, let’s just agree it would be a considerably longer list, and not nearly as punchy.

Still, it’s handy to have a top-level idea of how much stuff of what kind is on your computer and have that stuff broken down into common-sense categories. I have (Yellow) an enormous Photo library and (Blue) an equally huge amount of media files on mine, as well as smaller swathes of what rapidly becomes less and less specific as the bands of colors progress. Magenta is “Music” which, okay, is fair enough, and then Red is “Apps” which also makes sense, but then Green is the moderately mysterious “Documents” and Purple is “Mail and Others” which tells me that whoever was in charge of putting those categories may have been going through some things (probably because of the whole 2022 thing) and just lost interest in going further down this particular rabbit hole.

Finally, right at the end there, we have “System Data”, which is what this has all been leading up to; grey-hued and monolithic, enigmatic, remarkably unhelpful and a frequent cause of head-scratching and questions; chiefly questions like “What the hell is “System Data” and why do I have so much of it?” or “How can I free up some space and get rid of “System Data“?

System Data is, well, it’s everything else on your computer that Apple doesn’t have a convenient label for in that bar graph. Typically it’s a collection of options from this menu of data:

• macOS system/browser/user caches

• Disk images (.img, .iso, .zip, .dmg)

• installer packages

• macOS temporary (or log) files

• iOS device backups

Prior to macOS Monterey all of this was labeled as “Other” instead of “System Data”, which is even less helpful and resulted in even more head-scratching. I mean, yeah, “System Data” is pretty vague, but “Other” just seems like the person responsible not only lost interest in their work but also knocked off early to go down the pub – which highly-focussed career-minded go-getters like me and (presumably) Brian Durkin find simultaneously understandable and deeply disappointing.

Fortunately there’s an easy way to manage the data on your Mac without rolling up your sleeves, blocking out your afternoon, and then sitting down to rifle through every folder on the thing searching for cruft and sifting through digital debris. Simple hit the “Manage” button next to the bar graph, and you’ll see the Storage Management window of the System Information app, thus:

I tend to encourage people to ignore the initial recommendations. “Store in iCloud” turns on iCloud Drive and pushes your Desktop and Documents to the cloud, which… well, I admittedly don’t see a lot of computers because people are thrilled how happy they are and want to show off, but this option seems to the root of a lot more heartache than it’s worth for most people. I avoid “Optimize Storage” – removing TV shows and movies I’ve already watched annoys me because maybe I want to put Gigli on loop while I write so I can laugh at Ben Affleck and make cruel comments about his acting. “Empty Trash Automatically” is fine, but then again I also know a lot of people who tend to put things in the trash can as a sort of temporary filing purgatory, and who are justifiably upset when the trash empties itself. Finally, “Reduce Clutter” just does the equivalent of clicking on the “Documents” item in the left column of that window, which is rather redundant.

Whoever took over after the person who lost interest in categories a couple of paragraph ago did a pretty good job with the list on the left of that window. Each option brings up the appropriate list of data and allows you to selectively sort that data by size, kind and data accessed – and then allows you to delete that data without digging around in your computer to actually find the wretched files. The exception is Mail, which tells you how much Mail you have on your computer (even though that figure is listed in the column on the left):

…and Photos, which tells you how much space you’re using for Photos on your computer (even though that figure is also listed in the column on the left), but which also gives you a big, tempting button to click that will remove full-quality photos on your Mac and replace them with smaller “optimized” versions, which will save you a lot of space but removes full-quality photos on your Mac without making it explicitly clear that this is what it is doing to your data:

So, in summary, where does that leave us? Well, as I’m the one throwing around rhetorical questions I suppose I’m the one who has to answer them, so here goes:

• Oversized brown-on-orange shirts are a fierce choice,

• Being aware of the built-in tools for data management in macOS gives you a solid understanding of methods for effectively managing and securing your data,

• Recognizing the limits of those tools is equally important, as ultimately your data is something you have sole responsibility for, and you should get to choose what should and should not happen to that data. It’s all about what’s on your Powerbook, after all.

Spoiler: there’s no actual subterranean exploration or cavern filled with toothsome denizens of the deep in this one. “Extracting file types and appending them to file names” would, admittedly, be a more accurate description, but not nearly as much fun.

About a week ago a very nice lady handed me a very large folder full of data. I cannot – for a variety of reasons – divulge the identity of the lady (or the source, type and dispensation of the data), but you should rest assured that the lady was nice, and the folder was… large. I’m not betraying any confidences or violating any laws when I tell you that the folder contained four thousand and ninety-six subdirectories, and that the entire sum of the files came to a hair shy of fifty-thousand files which in turn added up to many gigabytes. Almost all of the gigabytes, actually.

Now, that’s a lot of files, but in the grand scheme of things not what you’d call a remarkable; no, what was remarkable was that they were files referenced as attachments from a large, hopelessly damaged and now-defunct MySQL database, and that they had names like:

2b82e7672d8cfb84d47fdcad0cdab4a66a27b247a689e429cc67d83499976c88

And that’s it. No suffix, no identifying file information at all. What, you might ask yourself, is that thing? Is it a PDF? A Word Doc? A GIF of a dog playing a piano? Well, I’d tell you while interrupting your internal monologue, there’s no way of knowing because that file lacks something useful like “.pdf” on the end of the thing. If you tried to open that file then your computer would cough discreetly and put up a helpful message to ask you what the hell you were doing, and would you please stop?

Fortunately, macOS contains within it a panoply of tools both common and obscure that can be used to root around inside these kinds of files, and with a little elementary scripting it’s not terribly difficult to put together a shell script that will make this whole process simple and transparent. Behold then, The Thing That I Wrote:

A word of explanation might not go amiss.

First, I needed a place to pull the files from and a place to put them when they were finished processing. I called these places “Attachments” and “Attachments-converted” respectively. Let’s put a pin in that for a couple of paragraphs, as there’s more to explore with that.

Secondly, I used a for loop to go through each item in the folder, and set suffixName as a variable that would pull the file type from the document. I used file -b to query the file type (the -b flag trims the file name and path from the front of the result) which returned something like this: PDF document, version 1.3, 1 pages.

So? Great! It’s a PDF, and – just like this example – every file returns something similar (i.e., the file type in all-caps followed by version information and size). The next move was to pipe that over to grep -Eo '[A-Z]+' which went into that result and pulled out anything that matched all-caps strings, and then sent that over to head -1 which trimmed everything except the first match from that string. The net effect of that series of operations was that as far as the script was concerned “PDF document, version 1.3, 1 pages” had been whittled down to just plain old “PDF“.

I could have let that be, but giant all-caps file suffixes are ugly and seem like they’re shouting all the time, so I piped that over to the translate (tr) command which turned the upper-case text into lower-case and thus turned PDF into pdf.

Finally, I used the mv command to move each file into the “Attachments-converted” directory, renaming it as the original filename (“$f“) followed by a period and the suffixName variable, which turned:

2b82e7672d8cfb84d47fdcad0cdab4a66a27b247a689e429cc67d83499976c88

into:

2b82e7672d8cfb84d47fdcad0cdab4a66a27b247a689e429cc67d83499976c88.pdf

This is probably the point to pull the pin out of the bit I mentioned earlier – notably, how to extract fifty thousand files from four thousand and ninety-six directories. There is, a wiser and more knowledgeable friend of mine, informs me, a very easy and simple way of doing all of this with Ruby, but I’m terrible at Ruby and his solution – while elegant – was far beyond my miserable skill set.

Note: If you do not have a genius-level programming savant as a close personal friend then I strongly recommend you remedy that error as soon as possible. They’re essential tools, and all you have to do is put gin in one end and wait around for complex solutions to appear.

So, I may know next to nothing about Ruby, but I do know a fair deal about Shortcuts and Automator, and Automator excels at this kind of arbitrary donkey work, thus:

The speed at which this entire operation was conducted was borderline remarkable. Automator sorted and moved each file in around ten seconds, and the shell script I threw together had everything examined, renamed and sorted inside about thirty more seconds. The most difficult part of the procedure was trying to work out how to stick it all together – which chiefly involved me staring out of the window with my customary vacant expression – but it’s pretty impressive how the tools that are built in to macOS can be fit together to accomplish some complex solutions to otherwise frustrating problems…

Every year or so Apple churns out another operating system upgrade. This has, of late, become an immutable fact of modern life. The world may be on fire and war, famine and pestilence may be actively stalking the land, but as long as Apple releases an operating system with a cutesy name some time in the fall of each year then we can rest easy in the knowledge that order is preserved, and that the Great Wheel Of The Heavens will continue to turn and drag us all along for the ride whether we like it or not.

Actually, if we’re being turn-the-chair-around-and-sit-down-to-rap-with-the-kids real, it’s not really a new operating system as much as it’s an upgrade to the existing operating system. Yes, of late they’ve incrementally increased the number associated with the thing (we’re up to macOS 12 after lingering on macOS X for nigh on a couple of decades), but the fundamentals of the thing remain essentially the same. Windows and menus and conventions like the Dock reliable persist. There’s still a mouse and folders and files and such, and there’s still a menu bar at the top of the screen.

It’s the menu bar that caught my attention this time round. Honestly, macOS 12 is pretty much the same as the old macOSes save that a) there are many, many new bells and whistles that will be widely ignored by the vast bulk of regular users, b) you can click the little “I’ve-replied-to-this-message” arrow in the built-in Mail app and it will open the relevant sent missive (finally), and c) you can now get a new menu item that you can fill full of your own little bits of code that you can write yourself without much trouble, and actually do something useful with your computer for a change.

This made me happy because I like to do a lot of useful little things with my computer and I do not have a lot of patience with trying to remember how to write code (because I am rapidly aging and don’t sleep enough or drink enough water.) When the shell of your mortal trappings is degrading by the moment you can’t be bothered to write a lot of shell scripts and so forth. A lot of new things get introduced, linger a year or two, and then disappear forever, and the risk/reward of getting intimate with things that are probably doomed tends to make me cynical.

However, this new thing is actually sort of brilliant. Apple took a long, hard look at scripting on their platforms a few years back – effectively sunsetting AppleScript and rolling a lot of that functionality into Automator on the Mac, and cooking up Shortcuts on iOS with a lot of the same DNA. iOS Shortcuts were easy to write and allowed you to do an astonishing amount of useful stuff, and now with the advent of macOS Monterey/macOS 12/what have you, they’ve brought Shortcuts to the Mac and allowed it to run shell scripts. Trust me – this is good news.

I like to block out time every week to work on my stuff. It’s an old habit, and I think it’s a good one; make sure that the software tools I use all day are patched and up-to-date, look at log files and test backups, spend a little time doing the same list of checks and maintenance that I’d do on a client machine. A bad workman blames his tools, and I like not having that excuse available. One of the things that I do as part of that is to update homebrew, and then back up my brewfile and my zsh .zprofile. These aren’t exactly the most intimidating chores, but I’ve often thought it would be nice to have a simple, one-click way to do this that wouldn’t involve manually executing a bash script or relying on launchd or cron to do it for me. Shortcuts for the Mac turned out to make this a terribly, terribly simple operation.

First, I needed a script to update homebrew, then go dump my brewfile to a location where it could be backed up before then copying my .zprofile to that remote location too. Said remote location is my Dropbox folder – I loathe the Dropbox app with a fiery hatred, and instead use Maestral to access Dropbox. Maestral is an open-source alternative Dropbox client that does all the things that Dropbox used to do (i.e., synchronizes your files between computers) and none of the stuff that Dropbox currently does (tries to be Google Workspace, Google Photos, some kind of terrible backup solution, treats you with a profound lack of respect, generally takes over your computer and eats all your memory and CPU). I have a Maestral folder in my home directory, which is then synchronized via Dropbox’s back end.

My work machine is a 2021 M1 MacBook Air (“Razorback” because I like The Expanse and the idea that my laptop is tiny and fast), and the behemoth I currently have toiling away in my office is a 2009 Mac Pro running Monterey via the miracle of OpenCore and SurPlus (“Rocinante”, because I like The Expanse and trend sentimental about aging machinery that can still throw down with the best of them when required). When you create a Shortcuts app on macOS and you’re signed into multiple machines with the same iCloud account then your Shortcuts get pushed to each machine – which is great, unless you want to push a file to Maestral from each machine, as then the brewfile you send from your MacBook Air will cheerfully overwrite the brewfile you’ve already pushed up from your Mac Pro. To get around this I mined ioreg to pull out the hardware serial number from each machine, then used hostname to grab the hostname of each machine, and finally rolled those two variables into the script so that each file that gets pushed up is labeled with the serial number and hostname of the machine that generated the file, thus:

#!/bin/zsh

# First, let's run a brew upgrade because that's just a good idea

brew upgrade

# Next, create a variable called SerialNumber that will pull the hardware serial number from ioreg

SerialNumber=$(ioreg -c "IOPlatformExpertDevice" | awk -F '"' '/IOPlatformSerialNumber/ {print $4}') ;

# ...and a variable called hName so we can grab the hostname of the machine

hName=$(hostname);

# Next we run brew bundle dump to push a brewfile to the Maestral folder

brew bundle dump --file=~/Maestral/"$SerialNumber"_"$hName"_brewfile;

# And then we'll do the same for the ZSH profile

cp ~/.zprofile ~/Maestral/"$SerialNumber"_"$hName"_zprofile

Next, open up Shortcuts (assuming you’re running macOS Monterey), which can be found in the Applications folder and which looks like this:

Open it, select “New Shortcut” from the “File” menu, then type “shell script” into the search bar and click on “Run Shell Script” from the list that auto-populates below, like so:

You can type your own shell script in there, or just copy/paste my homework in if you’d like. It’s okay. I won’t tell the teacher. Next, go to the “File” menu and choose “Preferences”, then make sure that you have “iCloud Sync” and “Allow Running Scripts” enabled (if, that is, you want to have the thing synchronize via iCloud and also, well, work.)

You might also want to tap the icon for the script at the top of the window and choose a different emoji, and to give it a pithy name. Mine’s called “Upgrade Homebrew”, because I lack imagination. Go wild, though.

Finally, close the window for your newly minted Shortcut, and you’ll find yourself back at the default “All Shortcuts” browser window. Locate your shortcut and drag it to the “Menu Bar” icon, thus:

Finally, you should be able to activate your new Shortcut by choosing it from the Shortcuts menu item that now appears on the right hand side of your macOS menu bar:

…and that’s about it.

Upgrading homebrew can – depending on how frequently you do it – take a while, and there’s no feedback from the Shortcut to let you know if it runs into an error (so it’s good to test your script out using something like CodeRunner before implementing it). The proof, however is in the pudding. And by that I mean the proof is in my Dropbox folder:

This whole exercise is just a bauble – Shortcuts is an extraordinarily powerful and incredibly flexible ecosystem for generating what promises to be a pretty amazing spectrum of solid utility applications. I think people are going to come up with some remarkable uses for it, and I can’t wait to see what they cook up…