For the first 15 years of Classic Mac OS, right up to Mac OS 9 in 1999, Macs remained fundamentally single-user, and privacy wasn’t an issue of much concern. In those halcyon years of desktop publishing and HyperCard, users were more excited by opening information up than keeping it private, and the internet was in its infancy. It was Mac OS 9 that first integrated multiple user accounts and started to secure information using keychains.

Mac OS X brought the first full multi-user operating system to the Mac, but as internet connections became increasingly common and lasting, little attention was paid to privacy. By 2011, the Privacy tab in Security & Privacy, then in System Preferences, contained just three items: Location Services, Contacts, and Diagnostics & Usage. While privacy features developed elsewhere, for the sake of simplicity I’ll here focus on that pane in System Preferences, and its successor in System Settings.

Four years later, in OS X 10.10 Yosemite (2015) and still in 10.12 Sierra (2017), those three items had grown to eight, with the addition of Calendars, Reminders, Accessibility, and two social media platforms, Twitter and Facebook.

Then at WWDC in 2018, Apple revealed its new privacy architecture, putting it at the forefront in macOS 10.14 Mojave, and eventually reversing the order to Privacy & Security.

Mojave protected information in the following 15 categories:

• Location Services,
• Contacts (address books),
• Calendars,
• Reminders,
• Photos (Photos libraries),
• Mail,
• Messages,
• Safari browsing history,
• HTTP cookies,
• Call history (iOS),
• Time Machine backups,
• iTunes backups,
• camera input,
• audio input through the built-in microphone,
• automation (AppleScript and others).

Its new protection system was dubbed TCC, for Transparency Consent and Control, and has since become prominent in the nightmares of developers, those who support Macs and many who use them. At its worst, it crashes apps that don’t comply with its rules, as shown in the diagram below for macOS 10.14.

Various classes of protected data are shown at the left, those in red being covered explicitly in Privacy controls. The first step was to determine whether the app trying to access protected data was signed by Apple: if it was, access was determined by private controls, and sometimes regular controls as well.

Apps developed by third parties were checked to see whether they already had access to that particular class of protected data according to Privacy settings. If they had, access was then granted without further dialogs. Note that the effect of adding an app to the Full Disk Access list was to give it access to all protected data, but not services or hardware, without any further consent being sought.

If they hadn’t already been given access, the next check was to see which version of the SDK they were built against. If they were built against 10.13 or earlier, then Mojave didn’t expect them to have support such as usage information, so it should have displayed a dialog inviting consent to the requested access. That would normally only contain the standard text information.

If consent was given, then that app was added to the appropriate class in Privacy settings; if it was declined, then it was denied access, but wasn’t put on any blacklist, so consent could still be given on another occasion.

If the app was built against the 10.14 SDK, then stricter rules were applied. It was then required to have a usage statement for the class of data it was trying to access, where that was in the class-specific list at the top, or a protected device or service. If the app didn’t provide the appropriate usage statement, TCC considered the request to access protected data was unintended, and crashed the app as an ‘unexpected quit’.

If the app did contain a usage statement appropriate for that class of protected data, then Mojave displayed the consent dialog, this time containing the text from that usage statement as well. If consent was then given, the app would be added to the list in Privacy.

Since Mojave, TCC has been a fertile source of vulnerabilities for third-party researchers to discover, and the malicious to exploit. Three were reported shortly after the initial release of 10.14. Two, discovered by Patrick Wardle and Jeff Johnson, weren’t disclosed, to allow Apple to address them, and the third, in ssh, wasn’t so much a vulnerability as a feature that could be exploited.

Each successive major version of macOS has added further to that list from Mojave. Catalina (10.15, 2019) added new locations that required user intent or consent to access, including:

• ~/Desktop, widely used for active documents
• ~/Documents, main document storage
• ~/Downloads, the default location for downloaded files
• iCloud Drive, now widely used for shared working documents
• third-party cloud storage, if used
• removable volumes
• network volumes.

This is one of the late Security & Privacy panes from macOS Catalina in 2019.

By the time that macOS 13 Ventura was released in 2022, its shiny new Privacy & Security section in System Settings listed 20 categories. Some, like Full Disk Access and Files and Folders, overlapped, while others like Accessibility appeared to have been misnamed. Controls provided varied between different categories, and many users dreaded having to tinker with them.

At this rate of growth, Privacy will soon have its own app alongside System Settings.

Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.

Startup

Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.

A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.

The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.

User Data

Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.

Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.

Run Apps

With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.

When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.

Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.

There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.

macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.

Private Data

Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.

Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.

No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.

There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.

Downloaded Apps

While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.

Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.

Bad Links

Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.

Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.

Summary

That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.

Work and play safely!

Apple has made great play over the privacy provided in its new AI tools. If you’ve just updated your Apple silicon Mac to Sequoia 15.1 and are wondering how you can check on this for Writing Tools, this article explains how.

When running on a capable Mac, with an M-series chip, macOS captures details of all AI use in its Apple Intelligence Report (AIR). Control and access that from its new entry in Privacy & Security settings, where you’ll find it towards the end, just above the final Security section. Open that, and you’ll see you can set the Report Duration to 15 minutes, 7 days, or turn it off altogether. As report sizes can grow quickly with a little use of Writing Tools, I suggest you start off with 15 minutes, or you might get overwhelmed.

When you want to browse a report, simply click on the button to Export Activity, and save the AIR report.

Apple Intelligence Reports are written out to JSON files that can be viewed using a text editor if you don’t have a specialist JSON editor. They’re usually bulky, and much of their content may be encoded binary that’s of little meaningful use. However, at the start you’ll see a series of modelRequests.

Each modelRequest begins with the timestamp of the request, given in decimal seconds since 1970. That’s followed by a UUID, information on the prompt template used, and shortly after that is the text that was extracted and used by Writing Tools. For longer passages of text, you may see that it’s divided up into a series of shorter sections that match the paragraphs given in a summary.

After that input text, the language localisation is given, currently en_US as other variants and languages won’t be available until macOS 15.2 later this year. Next, the response is provided, as inserted into the Writing Tools or text window. That section ends with:

• model, the name of the AI model used, such as com.apple.fm.language.instruct_server_v1.text_summarizer, and the version.
• clientIdentifier, such as com.apple.WritingTools.xpc.WritingToolsViewService for normal use of Writing Tools in an app.
• executionEnvironment, currently expected to be PrivateCloudCompute, which tells you where the AI processing took place.

After the list of modelRequests, you’ll probably see a long series of privateCloudComputeRequests full of incomprehensible data for sepAttestations and provisioningCertificateChains, part of the validation information for use of PrivateCloudCompute. If this all seems a little long-winded, try looking in the logs when Writing Tools are in use!

I’m very grateful to Tim, who has drawn my attention to these reports, and points out that use of PrivateCloudCompute appears confined to macOS at the moment. A similar report is also available for iOS 18.1, but iPhones don’t appear to rely on PrivateCloudCompute in the same way.

We must remember that, while Apple considers Writing Tools now ready for general use, it’s still officially a beta-release, and over the coming months is likely to undergo significant change. This poses the question of whether Writing Tools will run on-device in the future, something only Apple can answer. What appears to happen at present is that the only local processing that takes place is tokenisation of text to prepare it for remote processing using Apple’s PrivateCloudCompute service, which actually performs the heavy lifting before returning its results to the Mac. However, macOS also appears to wake up the slumbering Neural Engine (ANE) for most Writing Tools services. Why that happens remains a mystery.

If you want to watch progress as AI features develop in macOS, you may find Apple Intelligence Reports a useful way to track that. If you do come across entries that seem to have used on-device services instead of PrivateCloudCompute, please let us know.

Early this coming week those fortunate enough to have an Apple silicon Mac will be able to update Sequoia to version 15.1 and try out Writing Tools at last. I’ve been testing and using them since the first beta of 15.1 back when the daylight lasted well into the night. I’ve been surprised at how lukewarm some have been at their arrival, particularly as most of those comments have come from those who make a living from their writing.

Perhaps the best way to show what Writing Tools can do is with an example, using the text from yesterday’s article A brief history of Mac firmware, a little over a thousand fairly technical words. I concentrate here on Writing Tools’ summary modes rather than its rewriting features, although they’re also thoroughly sound and useful in the right context.

Summary

Producing a succinct single paragraph summary is a challenge for even the most literate of humans. I’m impressed with Writing Tools’ 62 word offering of:
Mac firmware has undergone significant changes, from the Macintosh ROM in Classic Macs to Open Firmware in PowerPC models and EFI in Intel Macs. EFI, later evolving to UEFI, provides hardware access and boot services, while Apple silicon Macs employ a verified chain of trust for enhanced security. Firmware updates are now integrated into macOS installers and updaters, ensuring security and accessibility.

Key points

With so much information in the original, a key point summary should provide a better reflection of my original thousand words. Rather than reproducing the full 250 words generated by Writing Tools, here’s an excerpt covering one of the more challenging sections:

• Firmware Security Issue: Researchers demonstrated proof-of-concept attacks on Mac firmware, highlighting potential vulnerabilities.
• Firmware Update Policy Change: Apple transitioned from separate firmware updates to delivering them through system upgrades and updates.
• Firmware Security Concern: In 2017, Duo Labs researchers discovered many Macs running outdated firmware, raising security concerns.
• Apple’s Response: Apple hired security researchers and developed eficheck, a tool to check and report firmware versions to Apple.

I don’t think I could better that.

List

The third type of summary suitable for that article is a detailed list. This strips everything else out to leave terse factual sentences. For the whole text, it reduces to 833 words, a reflection on its already dense information. You’re unlikely to want to use this with longer passages, but here’s the same section given as key points above:

• In March 2015, two security researchers from LegbaCore demonstrated proof-of-concept attacks on the BIOS of several computers.
• The attacks could have been used to implant malicious code.
• Later that year, Kovah and Trammell Hudson turned their attention to Macs.
• They demonstrated a firmware worm named Thunderstrike 2.
• For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X.
• In 2015, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates.
• Although older separate firmware updates are still available, those were the last.
• In 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware.
• Their concern was about the security risk posed by outdated firmware.
• Apple had already been busy hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August.
• They developed a new tool eficheck, released in High Sierra on 25 September 2017.
• eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Table

The fourth summary option is to generate a table. Unfortunately, my example wouldn’t produce a useful table without substantial additional knowledge. However, I’ve found this useful on long passages from fiction, where it can summarise relationships between different characters, and similar tasks.

On device and on target

Once Sequoia 15.1 has been released and I’ve had a chance to explore the internals of Writing Tools further, I’ll look at its processing and energy costs. Two important features distinguish it from other contemporary AI tools: all data remains on-device throughout, and it’s primarily using your text rather than a large language model built from vast quantities of text garnered from around the internet.

Privacy doesn’t generally worry me particularly, as much of what I write on Macs is destined in some way or another to be published, whether it’s in an article here, one in the magazines that I write for, or source code that will be built into apps. However, I do take exception to others making money out of my labours without my express consent, so I’ll generally be only too happy to keep my AI on-device.

I also think it’s important to draw a clear distinction between what Writing Tools offers, and the likes of ChatGPT. Now that I’m testing Sequoia 15.2 beta, I have been looking at that contrast. While you can’t ask Writing Tools questions (why would you want to when you have the whole text and its summaries?), I thought I’d see how ChatGPT answered one of my stock test questions for AI: what is the SSV?

At my first asking, ChatGPT didn’t have sufficient context, and told me that it’s a side-by-side vehicle, so I refined my question to what is the SSV in macOS?

Although much of its answer was correct and informative, the second sentence stated with complete confidence that the SSV was introduced in macOS Catalina, which is of course completely incorrect, as Catalina has a read-only System volume but not a Signed System Volume as was introduced in Big Sur. But you’d only spot that serious factual error if you already knew the answer.

Give me Writing Tools and my own fact-checking, thank you.

Apple provided developers with two Release Candidates of macOS Sequoia 15.1 this week. Provided there are no serious problems that come to light in the second of those, it’s likely that 15.1 will be released early next week, probably on Monday 28th. This article looks at what that brings, whether it’s safe to upgrade to Sequoia yet, and what comes next.

All supported Macs

Traditionally, the x.1 update is scheduled to be released about a month after the initial upgrade to a new major version of macOS, and brings with it the first wave of bug fixes, and a few features that weren’t quite ready in time.

Although there are reports of some other bugs in Sequoia, by far the most disruptive have been those affecting networking. Apple fixed the most serious of those in 15.0.1, released on 4 October, but some have continued to experience problems. Opinion from those testing betas of 15.1 are that it does resolve all those, and for the great majority should be ready for general use, provided that third-party apps are compatible. So if you normally wait for the x.1 version to be released before considering upgrading, this should fit the bill.

Apple does provide a list of fixes for developers, although as there’s no mention of any networking problems there, I suspect this isn’t of much help to users.

Apple silicon Macs

For those whose Macs run an M-series chip, the main interest in 15.1 is the first batch of Apple Intelligence features. Over the coming months, these should include:

• Writing Tools, a suite of mainly on-device features for summarising and rewriting text.
• Image Playground, producing synthetic images such as Genmoji, again using on-device methods.
• Siri and related enhancements for user assistance, using on-device methods.
• ChatGPT access, for more general AI features using text.
• App-specific enhancement to Photos, including Clean Up, and others.

Of those, 15.1 brings Writing Tools and some other enhancements, but doesn’t bring Image Playground or ChatGPT. Although some have claimed that makes 15.1 little better, that understates the value and quality of Writing Tools for many.

Writing Tools should be accessible to pretty well any recent app that displays significant amounts of text. Although I haven’t intended the lower text view in SilentKnight to support them, Writing Tools are available there from the contextual menu (Control-click). They work great with all the text editors I have tested, including TextEdit, BBEdit, CotEditor, Pages, my Rich Text editor DelightEd, and even in my PDF viewer Podofyllin.

The initial release of Writing Tools in 15.1 does have language and regional limitations. It requires that your Mac’s primary language, as set in Language & Region settings, is set to English (US), although you can still switch to a secondary language such as English (UK) if you prefer. The other key control is in the new Apple Intelligence & Siri settings, where Siri’s language needs to be English (United States). As I don’t like Siri’s spoken interface, I have disabled that by setting the Listen for control to Off, and instead enabled a Keyboard shortcut to open Siri’s interactive window.

Apple has announced future support for non-US variants of English, and next year for other primary languages. However, Writing Tools still work excellently on British English, even that of Charles Dickens, with the settings described above.

When you have updated or upgraded to Sequoia 15.1, I suggest you download text versions of books by your favourite author(s) from Project Gutenberg and explore features in Writing Tools using those as prose sources.

Future Sequoia updates

Apple has this week released the first beta-test of Sequoia 15.2, with most if not all of the other Apple Intelligence features, including Image Playground and ChatGPT. Assuming testing proceeds well and there are no serious problems, this is likely to be released in the first couple of weeks in December. Although not confirmed yet, this should open supported languages to include most major regional variants of English.

Slated for next year is the extension of Apple Intelligence to cover French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, and others. However, these features aren’t likely to appear in the countries of the EU this year, and Apple hasn’t yet indicated when that’s expected.

For those concerned about on- and off-device AI and privacy, all the standard features of Writing Tools and Image Playground involve on-device processing, and don’t send your data to remote servers. If you choose to enable ChatGPT access, then that is handled off-device, but is opt-in, and requires a separate sign-in process to access either an anonymised free account or an existing ChatGPT account. You can also require confirmation of any Siri requests handled with ChatGPT before sending any information off-device.

Apple has already published a list of fixes in the first beta of 15.2, although it remains to be seen what it does for users.

M4 Macs

Apple has also signalled that it will be releasing new Macs next week, widely rumoured to be the first to use the M4 chip.

Summary

• Sequoia 15.1 early next week, probably on 28 October, with Writing Tools in US English, and remaining networking bug fixes.
• Sequoia 15.2 already in beta, probably for release in early December, with Image Playground, ChatGPT, and the remainder of this first wave of AI tools, including most other English variants.
• Try Writing Tools out: I think they’re wonderful.