The government said the proposal would protect online privacy. Critics said it could further concentrate government control over the internet.

Using a virtual machine (VM) might seem an ideal platform for private computing. With all its data locked away in a VM that can’t otherwise be accessed from your Mac, it’s thoroughly safe from Spotlight indexing, access to old versions of documents, QuickLook previews, and everything else on your Mac’s Data volume that could give unintended access to its contents. But how secure could you make it? Prior to Sequoia, only as secure as the volume it’s stored on, it seems, which doesn’t make it so private after all.

In addition to Sequoia VMs on Apple silicon Macs being able to use services such as iCloud using Apple ID, they now appear able to support full-strength FileVault when Apple ID is activated. This contrasts with FileVault supported by previous macOS guests, which appears comparable to that provided by Intel Macs without T2 chips, or on external disks of any Mac, in that the Secure Enclave isn’t involved in protecting their encryption keys, as explained in Apple’s Platform Security Guide. Thus an attacker who has access to an older VM could copy that and attempt to gain access by brute force.

Apple hasn’t explained what is required for Sequoia VMs to support Apple ID, but it involves configuring “an identity for the VM that it derives from security information in the host’s Secure Enclave”. Support requires changes in macOS, both in the host and the guest, as its use requires the combination of Sequoia developer beta 3 or later running on both. It’s also significant that it can’t be used on VMs that have been upgraded from earlier versions of macOS, although thankfully it doesn’t require that of the host. This appears to be because Apple ID support requires structural change in the VM that can’t be achieved by a macOS updated inside it, and can only be performed when creating a new VM from scratch.

The best that a VM has been able to offer before Sequoia is relative privacy, but little more protection than already available on the host’s internal SSD. That assumes you store your VMs on the internal Data volume, which isn’t good practice in terms of snapshots and backups, as those will be significantly larger as a result. Storing VMs externally benefits from encrypted APFS, but that’s not as robust as full-strength FileVault.

If you want to set up a private VM using lightweight virtualisation on Apple silicon:

• Upgrade the host to macOS Sequoia.
• Build a new VM using macOS Sequoia.
• Create the VM on the host’s Data volume on its internal SSD, with FileVault enabled.
• Add that item to Time Machine’s list of exclusions from backups, only backing it up when necessary to an encrypted APFS volume. Bear in mind, though, that the VM will still appear in local snapshots.
• During VM configuration, sign in with your Apple ID and enable FileVault for the VM.
• For the VM’s primary admin account, use a different name and a different and robust password.
• In the VM, disable all unnecessary iCloud and iCloud Drive access, and don’t enable network file sharing.

Remember that access to shared folders is only available from inside the VM. It’s currently not possible for the host or processes running on the host to access the contents of the VM unless enabled by network file sharing or through iCloud.

Backups, indexing for search, and cloud storage are each very useful when and where you want them. But there are occasions when you want to exclude folders and files from their reach. This article is a short reference to how you can exclude items from being backed up, indexed and searched, and stored in iCloud Drive.

Time Machine backups

Time Machine has several mechanisms for excluding items from its backups. The first of those used to be its Standard Exclusions list, at /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist, but that has long since disappeared from there. Currently the best way to inspect that list is by viewing the hidden file .exclusions.plist at the top level of any backup.

This lists several categories of exclusions, of which the first are apiExclusionPaths, added by individual third-party apps. The equivalent of what used to appear in StdExclusions.plist is now given under the standardExclusionPaths key, containing:

• .DocumentRevisions-V100 – the version database on each volume, added in Big Sur,
• .Spotlight-V100 – Spotlight metadata,
• .Trashes – contents of Trash folders,
• .fseventsd – the File System Events database,
• /Library/Logs – traditional text log files,
• /Users/Guest – guest user files,
• /private/var (partial) – various transient files,

among many other ephemeral items.

Of those, only one results in any significant loss of data, the version database. Although this was dutifully copied by Time Machine into backups for several years, the current structure of that database appears to make it impossible to restore successfully, even when restoring a complete volume. By the middle of the Catalina cycle, it had become a frequent cause of Time Machine choking, so was added to the standardExclusionPaths for Big Sur. As far as I’m aware this was never fixed in Catalina.

Following those are stickyExclusionPaths, excluding various Photos Library contents. The key systemFilesExcluded is set to true to ensure that the whole System volume is always excluded, following which are any userExclusionPaths you have set using tmutil or in Time Machine settings, using the Options… button.

By default, volumes on external storage are automatically added to this exclusion list; if you want an external volume to be backed up by Time Machine then you will need to remove it from the exclusion list manually.

In addition to the rules given in the Standard Exclusion list, any file or folder can have an extended attribute of type com.apple.metadata:com_apple_backup_excludeItem attached to it as a ‘sticky’ exclusion, which should add it to the stickyExclusionPaths list and prevent it from being backed up by Time Machine. If you then remove that extended attribute, it should be backed up normally again.

Mike Bombich gives a thorough and detailed account of what CCC doesn’t copy on this page. Other backup utilities should also provide full lists on their support site.

Note that no folders or files can be excluded from APFS snapshots, whether made by Time Machine, CCC or any other app, as snapshots always capture the entire volume.

Spotlight search

There have been three general methods of excluding folders from Spotlight’s indexing and search, although only two of them still work reliably:

• appending the extension .noindex to the folder name (this previously worked using .no_index instead);
• making the folder invisible to the Finder by prefixing a dot ‘.’ to its name;
• putting an empty file named .metadata_never_index inside the folder; that no longer works in recent macOS.

System Settings offers Spotlight Privacy settings in two sections. Search results won’t normally prevent indexing of those items, but does block them from appearing in search results. Spotlight’s indexing exclusion list is accessed from the Spotlight Privacy… button, where you can add items that you don’t want indexed.

iCloud Drive storage

This works primarily by inclusion, in that you copy or move items to the iCloud Drive folder when you want them to be copied up to iCloud Drive. There are occasions, though, when you want to exclude specific folders and files that need to be in a folder in iCloud Drive, but you don’t want those items to be stored in the cloud. iCloud won’t sync items with the extensions .nosync or .tmp, so putting files inside folders whose name ends in either of those extensions will ensure that they’re not stored in iCloud Drive.

Other items intended for local housekeeping and similar purposes that are excluded from syncing include:

• .DS_Store files
• files whose name starts (A Document Being Saved
• .ubd files
• items with names containing .weakpkg
• desktop.ini files
• items with names starting with ~$
• items named $RECYCLE.BIN, which are trash folders
• items named icon\r, which are custom folder icons.

Files and folders with purposes that make iCloud syncing inappropriate include those:

• named iPhoto Library, and presumably now Photos Library too
• named Dropbox, .dropbox, or .dropbox.attr
• with the extension .photoslibrary, .photolibrary, .aplibrary, .migratedaplibrary, .migratedphotolibrary, or .migratedaperturelibrary
• named Microsoft User Data
• named ~ with an extension of 3 or more characters.

The only setting in System Settings gives control over Desktop & Documents folders, and those of individual apps; there’s no exclusion list available.

Simple reference to folder controls

• Time Machine: add to settings with the Options… button, or using tmutil;
• Spotlight indexing: add to settings with the Spotlight Privacy… button, or append the extension .noindex to the folder name;
• iCloud Drive: append the extension .nosync or .tmp to the folder name.