I hope you enjoyed Saturday’s Mac Riddles, episode 361. Here are my solutions to them.

1: This second was actually the sixth and bumped up by 20.

2: Its A5 followed the A4, without any one, and a third thinner.

3: First with a 750 followed the 604, but there was neither 1 nor 2.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: This second was actually the sixth and bumped up by 20.

2: Its A5 followed the A4, without any one, and a third thinner.

3: First with a 750 followed the 604, but there was neither 1 nor 2.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

I hope you enjoyed Saturday’s Mac Riddles, episode 360. Here are my solutions to them.

1: With parents born in 1984 and 1989, it was born a server and raised with aqua.

2: First with Face ID and no Home to go to in 2017.

3: It shocked without MIDI in 2009, and ten years later went solo.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: With parents born in 1984 and 1989, it was born a server and raised with aqua.

2: First with Face ID and no Home to go to in 2017.

3: It shocked without MIDI in 2009, and ten years later went solo.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

I hope you enjoyed Saturday’s Mac Riddles, episode 359. Here are my solutions to them.

1: Could in theory be 995 or unreal apparatus for running old macOS.

2: More than a superlative manager at the heart of 1.

3: Unreal input and output from Rusty Russell for 1.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Could in theory be 995 or unreal apparatus for running old macOS.

2: More than a superlative manager at the heart of 1.

3: Unreal input and output from Rusty Russell for 1.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

I hope you enjoyed Saturday’s Mac Riddles, episode 358. Here are my solutions to them.

1: Thinly dispersed line of people could save lots of space.

2: Identical copy of rasp when duplicated.

3: Steadfast 7.92 inch two-way volume connector.

The common factor

I look forward to your putting alternative cases.

In the past, getting audio reliably from virtualised macOS running on Apple silicon Macs has been something of a puzzle. Audio input seems to need some way to route it from the host to the guest, and I confess I’ve not had the patience yet to pursue that and any privacy settings required to permit it. But audio output has also been a bit hit-or-miss.

In code, this should all be straightforward by creating a VirtIO sound device configuration, with input and output streams, and assigning that to the audio devices of the VM. That should work from macOS 12 onwards. Although my virtualisers have been doing that ever since, the results haven’t been as consistent as I’d expect.

Most recently users have expressed interest in the audio processing and output capabilities of macOS VMs, so I have been assessing those, and discovered problems in synchronising audio with video.

Running all VMs on a Mac mini M4 Pro host with macOS 26.4.1, all versions of virtual macOS up to and including Tahoe 26.4.1 suffer syncing problems. Those affect all tested output in Ventura 13.7.6, but are slightly more limited in more recent guest macOS, but they still suffer marked delay in audio relative to video output. This isn’t a matter of milliseconds, but appears to be of the order of two seconds in GarageBand, at least.

So far my tests have included:

• QuickLook previews of video,
• QuickTime Player, playing video,
• TV, playing video,
• GarageBand, both in its instructional videos and synchronisation of audio output when playing tracks.

The only exception, where syncing is correct, occurs in limited circumstance in Sonoma 14.8.5 and later. To demonstrate this, select a video clip with synced audio and press the Space bar to play it in a preview. Then click on the button at the top right of that preview window to Open with QuickTime Player, and play the video there instead. That should result in correct lip-syncing, although opening the video clip directly in QuickTime Player doesn’t.

Apart from that, macOS VMs appear perfectly capable of normal audio output, at least when running on a Tahoe host.

If you have any experience of using video and/or audio in a macOS VM running on an Apple silicon Mac, I’d be interested to know whether you have encountered the same or other problems, please, in the hope that I can file a Feedback.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Thinly dispersed line of people could save lots of space.

2: Identical copy of rasp when duplicated.

3: Steadfast 7.92 inch two-way volume connector.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

I hope you enjoyed Saturday’s Mac Riddles, episode 357. Here are my solutions to them.

1: John’s afterword was dropped in 13.

2: Painted people who merged with Scots, from QuickDraw to Catalina.

3: Brisk march for panoramas was lost from X in 2009.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: John’s afterword was dropped in 13.

2: Painted people who merged with Scots, from QuickDraw to Catalina.

3: Brisk march for panoramas was lost from X in 2009.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

I hope you enjoyed Saturday’s Mac Riddles, episode 356. Here are my solutions to them.

1: Lowing and barking as you’d expect to hear from Clarus.

2: Alert heard in the battle between two Apples was replaced in Big Sur.

3: Arpeggio or shattering glass heard with a Sad Mac.

The common factor

I look forward to your putting alternative cases.

Ten days ago, I drew attention to anomalies in privacy protection of locations that could mislead, in that Privacy & Security settings could claim an app didn’t have access to a protected folder when it did. This article proposes an explanation, and provides further details of protected locations and their behaviour. This is based on my test app Insent version 1.2, which you can use to explore these behaviours in the comfort of your own Mac.

Procedures

For the avoidance of any doubt, Insent is a simple macOS app that doesn’t run in an App Sandbox, doesn’t have any entitlements, but is notarized. Its two features of greatest interest here are Open by consent, and Open from folder buttons:

• Open by consent constructs a folder path as a string without involving user action in an Open and Save Panel, then calls FileManager.default.contentsOfDirectory() to list files within that folder. If that’s successful, it randomly selects a text file from those, opens it, and displays the opening part of the text contents. This is opening that file by consent, as the app is given access to that folder by user consent through TCC’s privacy controls, by consenting to the standard dialog.
• Open from folder displays an Open and Save Panel (NSOpenPanel) asking the user to select a folder. The URL returned from that is then used to call FileManager.default.contentsOfDirectory() to list files within that folder. If that’s successful, it randomly selects a text file from those, opens it, and displays the opening part of the text contents. This is opening that file by user intent, as the user has chosen that folder to be used. As a result, this doesn’t invoke TCC’s privacy controls.

Consent

The mechanism used to list the contents of a protected folder and open a file from among those is the more obvious, and better documented. Even though the app itself isn’t running in an App Sandbox, the call is intercepted by sandboxd and passed to TCC for it to check whether current privacy policy for that app should allow the request. TCC first checks whether kTCCServiceSystemPolicyAllFiles applies, with the app being given Full Disk Access. If it does, then sandboxd is advised and the call to list the directory proceeds.

If kTCCServiceSystemPolicyAllFiles doesn’t apply, TCC checks for the location-specific service, including

• kTCCServiceSystemPolicyDesktopFolder
• kTCCServiceSystemPolicyDocumentsFolder
• kTCCServiceSystemPolicyDownloadsFolder
• kTCCServiceSystemPolicyRemovableVolumes
• kTCCServiceSystemPolicyNetworkVolumes
• kTCCServiceFileProviderDomain.

If that has been given, sandboxd is advised and the call proceeds.

If neither of those applies, then a standard consent dialog will be displayed. If the user allows that, then the location-specific service is granted, and sandboxd advised to proceed. As these steps are all documented in detail in the log, there’s no difficulty in following them there, and diagnosing their problems.

Intent

Although the log contains details of the use of the Open and Save Panel to select a folder, when a protected folder is listed by intent, there are no informative log entries at all. For example,
0.812549 Insent sendAction:
0.812607 Insent: trying to list files in /Users/hoakley/Desktop
0.813297 Insent: trying to look in /Users/hoakley/Desktop for text files
0.813373 Insent: trying to read from: /Users/hoakley/Desktop/00vlutest1pm.text
1.173727 Insent: read from: /Users/hoakley/Desktop/00vlutest1pm.text
where the first four are written consecutively in the log.

To understand what’s going on here we have to consider how sandbox behaviour might apply. This has been explained clearly for the App Sandbox by Mark Rowe, and the most relevant section there is about Mandatory Access Control in the kernel, towards the end: “The macOS kernel (XNU) provides a Mandatory Access Control Framework (MACF) that exposes around 300 policy hooks that can be used to approve or deny specific operations at a fine-grained level. Most of the policy hooks correspond to specific system calls or operations on the kernel’s file system abstraction (VFS). As the name implies, these policy hooks are mandatory and are applied to all clients that use the system calls or perform file system operations.”

So when Insent calls FileManager.default.contentsOfDirectory() to list files within a folder, its corresponding policy hook is called with a context including the directory and the caller.

This is where the next component comes into play: any com.apple.macl extended attribute saved to that directory. We still know remarkably little about those xattrs, despite them being so common. Here I turn to Adam Chester’s early account of how they’re used for protection by user intent. These Mandatory Access Control Lists (MACL) enable the sandbox to determine whether the request to list the contents of the directory should be approved. Because this all takes place within the kernel and its sandbox extension, no entries appear in the log.

The only evidence of this happening is the MACL xattr saved to the protected directory, and making sense of that isn’t easy. Each MACL is 72 bytes, and multiple MACLs can be concatenated into a single xattr as necessary. They’re protected by SIP, so can’t be stripped in place while that’s enabled.

Because this mechanism remains within the kernel and sandbox, it’s invisible to TCC, and to its controls in Privacy & Security. If an app has gained access to a protected location by intent, then that takes precedent over TCC’s controls, and results in the contradiction seen in Files & Folders, whereby access is disabled but still takes place. This isn’t a bug, but a feature of access by intent.

Mechanisms

The following diagram summarises how I think these two mechanisms operate.

For the sake of simplicity, I have omitted the final step between access being granted/denied by the sandbox, and the app, where of course it’s the kernel that either permits the app’s request for the operation, or blocks it and returns an error. (I’m grateful to Csaba Fitzl for drawing my attention to that.)

This explains why Apple has been so reluctant to document any of this, and why MACLs are so opaque. If an app were capable of creating its own functional MACLs, they would enable it to bypass TCC’s controls and gain access to any protected location. Unfortunately, the side effect is that TCC isn’t allowed insight into what the sandbox is up to, and there’s no transparency for the user.

Overview

Even using a known and simple app like Insent, behaviours aren’t always consistent, and are susceptible to order effects and maybe even cosmic rays! There are also subtle differences between protected locations that can make generalisation unreliable. However, after extensive checks with Insent the following table gives an overview of protected locations in macOS 26.4.

The three common local folders ~/Desktop, ~/Documents and ~/Downloads are most consistent, with controlled read access, GUI controls in Files & Folders, and can be overridden by intent using MACL xattrs. Network volumes also appear to protect write access.

External volumes that are mounted automatically during startup don’t appear to count as being removable, but any that are mounted later have similar protection for both read and write, and can be overridden by intent using MACLs.

iCloud Drive and third-party cloud storage using the FileProvider API are more difficult to investigate, as I’ve still been unable to find any GUI control. It also doesn’t appear to be overridden by intent using MACLs, although its directories can still have com.apple.macl xattrs attached to them.

In addition to using any controls in Files & Folders, all TCC controls can be reset using tccutil, for example in
tccutil reset All co.eclecticlight.Insent
and that takes immediate effect, without a restart.

Restarting may be the best and perhaps only way (without disabling SIP) to reset MACLs. Although they can appear to persist at times, and the xattrs themselves don’t change, Adam Chester points out that tokens used by the sandbox are invalidated on rebooting, so maybe existing MACLs may not remain effective following a restart.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Lowing and barking as you’d expect to hear from Clarus.

2: Alert heard in the battle between two Apples was replaced in Big Sur.

3: Arpeggio or shattering glass heard with a Sad Mac.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Obtaining a definitive list of locations that are subject to privacy protection in macOS Tahoe 26.4 hasn’t been easy, and I’ve previously relied on information given piecemeal in WWDC sessions. This article reports the results of formal testing using a new version of my test app Insent, and brings some surprises.

Insent version 1.2 now allows you to set the path to the folder to be used for its Save and Open by consent buttons, using a Combo box. That’s a combination of a popup menu including the three most popular locations, Desktop, Documents and Downloads, and an editable text box into which you can enter a custom folder path.

Save and Open by consent are actions in which the user doesn’t express their intent to write to or read from the protected location, for example in an Open and Save Panel, but the app’s code determines the path and file. Thus, to ensure the app’s access doesn’t compromise the user’s privacy, those actions may be blocked unless the user gives their consent in a dialog presented for TCC, the privacy manager.

In the Save by consent code, all Insent does is construct a URL to a new text file in that folder path, then tries writing a String to that URL using String.write() non-atomically. To open a text file from that folder path, it attempts to enumerate the contents of the directory at that URL using FileManager.default.contentsOfDirectory(), then iterates through the contents until it finds a text file to open. If it does, it tries to read that file using String(contentsOf: url), and displays the start of that String.

Only three locations conform to the standard control:

• ~/Desktop
• ~/Documents
• ~/Downloads

In each case, there is no control over writing to the location, but any attempt to list the contents of that folder elicits a request for consent, and results in an entry for Insent in the Files & Folders list in Privacy & Security settings.

For iCloud Drive, and presumably third-party cloud services with equivalent privacy protection, there is no control over writing to the location, and listing folder contents requires consent, but no entry appears in the Files & Folders list, and I have been unable to discover any equivalent control elsewhere. Thus, once consent has been given, it appears to remain indefinitely, as the user doesn’t have a control to disable that access.

Removable Volumes and Network Volumes differ again, in that both Save and Open by consent require user consent, although giving consent to one action also grants it for the other. However, not all removable volumes are treated as protected. A Time Machine backup drive that is mounted automatically during startup, and has an additional volume not used for backups, wasn’t given any protection, while an SSD connected and mounted well after login was treated as a Removable Volume.

Although often listed as being subject to privacy protection, read access by consent was blocked for Time Machine backups, and they’re read only anyway.

One strange behaviour discovered during testing was the automatic addition of Insent to the Full Disk Access list, rather than individual Files & Folders. However, Full Disk Access hadn’t been granted, and when Insent was removed from that list, individual Files & Folders were shown instead.

There was no evidence of any other special locations among other standard folders in the user’s Home folder, although there are separate controls covering Photos access, and that to app databases, as listed in Privacy & Security settings.

The following table summarises privacy protection for special locations in macOS 26.4.

Insent version 1.2 is now available from here: insent12
Have fun trying to make sense of this protection.

Mosaics, composed of small fragments of coloured stone, glass or ceramic in a matrix of plaster or mortar, have ancient origins in the civilisations of the Fertile Crescent in the Middle East. Although widely viewed as being decorative, some of the best examples transcend that to become fine art.

This breathtaking mosaic in the vault of the chapel of San Zeno, in Santa Prassede, Rome, created in 817-824 CE, goes well beyond mere ceiling decoration.

At the end of 1903, Gustav Klimt visited one of the major collocations of mosaics in Ravenna, Italy, where he saw and was deeply impressed by the spectacular Byzantine mosaics of Justinian I and the Empress Theodora in the Basilica of San Vitale. They inspired a portrait he completed four years later.

His first Portrait of Adele Bloch-Bauer (1907) is the most extreme and startling work from Klimt’s Golden Phase. Apart from her bust and arms, which are painted in oils, the rest of his canvas is, like the mosaic of the Empress Theodora, encrusted with gold and silver. Its decorative patterns include symbols of eyes, flowers, whorls, ellipses divided into halves, and rich textures worked into the gold leaf.

A few accomplished painters also created mosaics, usually later in their career.

Between about 1890-1910, the French Naturalist painter Luc-Olivier Merson created this extraordinary mosaic of Christ in Majesty in the apse of the Basilica of the Sacred Heart (Sacré-Cœur) of Paris in Montmartre. This is thought to be one of the largest mosaics in the world.

At about the same time, the American painter Elihu Vedder was creating a mosaic in the central arched panel leading to the Visitor’s Gallery of the Library of Congress, in Washington, DC.

His Minerva of Peace (1897) shows this Roman goddess of wisdom, the guardian of civilisation, and sponsor of arts, trade, and strategy. Vedder stresses that this was attained by warfare, and shows a miniature statue of Nike, the Greek winged goddess of victory, known to the Romans as Victoria. Nike holds the palm frond of peace and the laurel of victory.

Minerva’s helmet and shield rest on the ground, but she remains ever-vigilant in holding a spear in her right hand. Her left hand holds a scroll listing the fields of learning, from Agriculture to Zoology and Finance. These reveal her association with wisdom and knowledge. To the left of Minerva’s right knee is an owl, symbolising wisdom.

The inscription below, Nil invita Minerva, quae monumentum aere perennius exegit, means Not unwilling, Minerva raises a monument more lasting than bronze, and is quoted from Horace’s Ars Poetica.

Other artists painted in the style of mosaics.

In The Hutsul Madonna from 1909, Kazimierz Sichulski used a combination of tempera and pastel to create passages that appear to be mosaics, while others look more like stained glass, in a luminous Art Nouveau style.

Above is the left panel, and below is its centre panel.

Some of the Divisionists, notably Paul Signac, applied their paint in small rectangular patches termed tesserae, the same word for the coloured pieces used to compose mosaics.

Signac adopted these by 1905, and continued to use them for the rest of his career. They’re shown above in his painting of The Lighthouse at Groix from 1925, and in the detail below. These are oriented to help form each object.

Although these create a distinctive effect, they don’t follow Georges Seurat’s original intention of optical mixing of colours in fine dots, although they’re much quicker to apply, and refer back to the great Byzantine mosaics.

I hope you enjoyed Saturday’s Mac Riddles, episode 355. Here are my solutions to them.

1: Covid, smallpox, nVIR, but no more.

2: Wooden animal concealing Greeks like DubRobber.

3: A thief like Amos can arrive by clickfix.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Covid, smallpox, nVIR, but no more.

2: Wooden animal concealing Greeks like DubRobber.

3: A thief like Amos can arrive by clickfix.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Eating together with family and friends is one of the great social events, and became a popular theme in nineteenth century painting. It was enthusiastically adopted by several of the leading Naturalist painters, as shown below.

Édouard Manet’s Le Déjeuner sur l’herbe from 1863 is one of the best-known if not infamous paintings of a social meal. Two couples are apparently disinterested in the token picnic of fruit and bread that has spilled out from its basket in the left foreground. As the two men talk, fully dressed, a conspicuously naked woman stares unnervingly at the viewer, and the other woman is washing herself in the river behind. This was rejected by the Salon of that year, ensuring its lasting fame and influence.

A far cry from Manet’s meal, Eugène Lepoittevin’s Picnic from 1866 captures a picnic’s distinctive combination of the planned and impromptu. This group has lugged crockery, soup and a folding stool for their simple meal sitting on the grass under some trees.

Renoir’s masterpiece Luncheon of the Boating Party (1880-81) is set on the Île de Chatou under the awning of the Restaurant Fournaise. Among his models are his partner and later wife Aline Charigot (left foreground, with affenpinscher dog), the actress Jeanne Samary (upper right), and fellow artist Gustave Caillebotte (seated, lower right). This meal seems all but over, the wineglasses near-empty as the party turns from eating to conversation.

In summer, breakfast became a favourite meal in your own garden. Just a year before his untimely death in 1884, the Italian peri-Impressionist Giuseppe De Nittis painted this startling Breakfast in the Garden, with its contrast between the detail of the glass soda syphon, covered bowl, glasses, and other reflective materials on the table, and its wonderfully sketchy garden background.

Laurits Andersen Ring was more pointed in his social message in A Boy and a Girl Eating Lunch, from 1884. Paupers’ children, they have a single bowl of broth between them, and there’s not even a hint of wine and fruit. The girl looks up in tears, hoping for a miracle to change their lives, and take them away from this bare wooden table and blackened walls.

Léon Frédéric’s Funeral Meal from 1886 shows a large group of mourners sitting outside in the summer sunshine to remember the deceased following their funeral. Their meal is simple if not frugal, and there are neither glasses of wine nor mugs of beer. This is the moment that grace, or perhaps a eulogy for the deceased, is being read.

Now almost forgotten is Émile Friant’s masterpiece The Meurthe Boating Party, also known as Reunion of the Meurthe Boating Party or The Oarsmen of the Meurthe, from 1887. This shows the artist’s watersporting friends eating lunch together on the river Meurthe in Nancy. This can be read as a broad message of well-being and conviviality: healthy, fit young men engaged in team sports; fraternity; and harmony across different classes within society. It was exhibited at the Salon in 1888, and as a result of its success was featured as a full page in the popular magazine Le Monde Illustré, bringing Friant instant fame.

That same year the 23-year-old Swedish painter Hanna Pauli made the meal table the centrepiece of her virtuoso painting of Breakfast-Time (1887). She uses it as a demonstration of her skills in depicting the reflective surfaces of silverware, porcelain and abundant glassware, but its table is now deserted.

The Belgian artist Émile Claus also painted The Picnic in 1887. It’s set in the French/Belgian countryside around the River Lys, in the area of Ypres, which was devastated during the First World War. The plain clothing worn indicates these are poor farmworkers rather than landowners.

In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.

Although it appears you can achieve this using several ordinary apps, to make things simpler and clearer I’ve written a little app for this purpose, Insent, available from here: insent11

I’m working in macOS Tahoe 26.4, but I suspect you should see much the same in any version from macOS 13.5 onwards, as supported by Insent.

For this magic demo, I’m only going to use two of Insent’s six buttons:

• Open by consent, which results in Insent choosing a random text file from the top level of your Documents folder, and displaying its name and the start of its contents below. As it does this without involving the user in the process, the macOS privacy system TCC requires it to obtain the user’s consent to list and access the contents of that protected folder.
• Open from folder, which opens an Open and Save Panel where you select a folder. Insent then picks a random text file from the top level of that folder, and displays its name and the start of its contents below. Because you expressed your intent to access that protected folder, TCC considers that is good enough to give access without requiring any consent.

Demonstration

Once you have downloaded Insent, extracted it from its archive, and dragged the app from that folder into one of your Applications folders, follow this sequence of actions:

1. Open Insent, click on Open by consent, and consent to the prompt to allow it to access your Documents folder. Shortly afterwards, Insent will display the opening of one of the text files in Documents. Quit Insent.



2. Open Privacy & Security settings, select Files & Folders, and confirm that Insent has been given access to Documents.



3. Open Insent, click on Open by consent, and confirm it now gains access to a text file without asking for consent. Quit Insent.
4. Open Privacy & Security settings, select Files & Folders, and disable Documents access in Insent’s entry there using the toggle.
5. Open Insent, click on Open by consent, and confirm that it can no longer open a text file, but displays [Couldn't get contents of Documents folder].
6. Click on Open from folder and select your Documents folder there. Confirm that works as expected and displays the name and contents of one of the text files in Documents.
7. Click on Open by consent, and confirm that now works again.
8. Confirm that Documents access for Insent is still disabled in Files & Folders.
9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.

Indeed, the only way you can protect your Documents folder from access by Insent is to run the following command in Terminal:
tccutil reset All co.eclecticlight.Insent
then restart your Mac. That should set Insent’s privacy settings back to their default.

You can also demonstrate that this behaviour is specific to one protected folder at a time. If you select a different protected folder like Desktop or Downloads using the Open from folder button, then Insent still won’t be able to list the contents of the Documents folder, as its TCC settings will function as expected.

How does this work?

Insent is an ordinary notarised app, and doesn’t run in a sandbox or pull any clever tricks. When System Integrity Protection (SIP) is enabled some of its operations are sandboxed, though, including attempts to list or access the contents of locations that are protected by TCC.

When you click on its Open by consent button, sandboxd intercepts the File Manager call to list the contents of Documents, as a protected folder. It then requests approval for that from TCC, as seen in the following log entries:
1.204592 Insent sendAction:
1.205160 Insent: trying to list files in ~/Documents
1.205828 sandboxd request approval
1.205919 sandboxd tcc_send_request_authorization() IPC

TCC doesn’t have authorisation for that access by Insent, either by Full Disk Access or specific access to Documents, so it prompts the user for their consent. If that’s given, the following log entries show that being passed back to the sandbox, and the change being notified to com.apple.chrono, followed by Insent actioning the original request:
3.798770 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
3.802225 com.apple.chrono appAuth:co.eclecticlight.Insent] tcc authorization(s) changed
3.809558 Insent: trying to look in ~/Documents for text files
3.809691 Insent: trying to read from: /Users/hoakley/Documents/asHelp.text
3.842101 Insent: read from: /Users/hoakley/Documents/asHelp.text

If you then disable Insent’s access to Documents in Privacy & Security settings, TCC denies access to Documents, and Insent can’t get the list of its contents:
1.093533 com.apple.TCC AUTHREQ_RESULT: msgID=440.109, authValue=0, authReason=4, authVersion=1, desired_auth=0, error=(null),
1.093669 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder denied by TCC for Insent
1.094007 Insent: couldn't get contents of ~/Documents

If you then access Documents by intent through the Open and Save Panel, sandboxd no longer intercepts the request, and TCC therefore doesn’t grant or deny access:
0.897244 Insent sendAction:
0.897318 Insent: trying to list files in ~/Documents
0.900828 Insent: trying to look in ~/Documents for text files
0.901112 Insent: trying to read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text
0.904101 Insent: read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text

Thus, access to a protected folder by user intent, such as through the Open and Save Panel, changes the sandboxing applied to the caller by removing its constraint to that specific protected folder. As the sandboxing isn’t controlled by or reflected in Privacy & Security settings, that allows TCC, in Files & Folders, to continue showing access restrictions that aren’t applied because the sandbox isn’t applied.

Conclusion

Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.

Is this likely to occur?

Most apps that want access to protected folders like Documents appear to seek that during their initialisation, and before any user interaction that could result in intent overriding the need for consent. However, many users report that apps appear to have access to Documents but aren’t listed in Files & Folders, suggesting that at some time that sequence of events does occur.

To be effectively exploited this would need careful sequencing, and for the user to select the protected folder in an Open and Save Panel, so drawing attention to the manoeuvre.

Most concerning is the apparent permanence of the access granted, requiring an arcane command in Terminal and a restart in order to reset the app’s privacy settings. It’s hard to believe that this was intended to trap the user into surrendering control over access to protected locations. But it can do.

I’m very grateful to Richard for drawing my attention to this.

Given the technical challenge of painting optically faithful reflections on water, the painstaking and protracted work required for Divisionist techniques resulted in the omission of reflections, or only notional depictions. This article gathers some examples of Divisionist paintings that were taken the extra mile, and tried to do better.

Seurat’s first and greatest masterpiece, generally known as La Grande Jatte, uses the technique of optical mixing of colour. Rather than blending pigments on the canvas, it’s constructed of tiny high chroma dots to allow for optical mixing. Recognising the difficulty of recreating reflections when he was laboriously applying those dots to the large canvas for his finished painting, Seurat developed them in smaller studies such as that above.

Those are seen quoted in the finished work, which took him almost eighteen months to paint in three stages between 1884-86.

The Seine at Rouen, the Île Lacroix, Effect of Fog from 1888 is one of Camille Pissarro’s best-known Divisionist paintings, and one of the few to depict reflections in detail. This was based on studies he had made during a visit to the city back in 1883, five years before he started work on this finished painting.

Paul Signac also made use of sketches made in front of the motif, such as this of Les Andelys. Le Quai from 1886, which contains extensive passages of reflections.

His finished view of Les Andelys. Côte d’aval, completed the same year, completely omits reflections, though.

A different view of the same village, Les Andelys. La Berge, from the same year, includes extensive reflections that appear fairly accurate.

Signac’s Sunset, Herblay, painted in September 1889, is a good attempt but has small disparities. For example, reflected images of the trees seen on the bank at the left don’t tally with their originals in either vertical or horizontal dimension.

Evening Calm, Concarneau, Opus 220 (Allegro Maestoso) from 1891 must have been a major challenge that Signac carries off with aplomb. Again there are some small discrepancies: the most prominent boat in the foreground is heeling slightly to the left, but the left side of its reflection if anything leans slightly to the right.

Reflections are even more complex in Signac’s Tartanes pavoisées, or Fishing Boats Dressed Overall, from 1893. To get its triangular composition right, and inform his rendering of the reflections, he painted three studies for this. Despite that, two years later he traded this painting for a bicycle, but in 1910 it became his first painting to enter a public collection, in Wuppertal, Germany.

Another challenging view of The Port of Saint-Tropez from 1901-2 is less precise, but uses reflections to great effect.

Signac’s later Giudecca Anchorage from 1904 uses coarser tiles of colour, giving him more leeway.

Of all the Neo-Impressionist and Divisionist paintings of reflections, the undisputed champion must be Théo van Rysselberghe’s Canal in Flanders from 1894. This too was preceded by a study, but that almost completely excluded any reflections. The artist then moved his viewpoint to the right, and must have spent months getting its reflections right.

This uniquely combines radical perspective projection, intense rhythm and meticulous reflections. The artist painted few further views with reflections afterwards.

Alongside RunningBoard, TCC and privacy protection are among the greatest contributors to the Unified log, although they’ve been a little less loquacious more recently. This article sheds light on what they do when an app tries to access the contents of a protected folder. Log extracts were obtained from Insent 1.1 running in macOS 26.4 on a Mac mini M4 Pro, and concentrate on what happens when Insent tries to ‘open by consent’, first listing the contents of ~/Documents, then picking a text file at random and displaying some of its contents.

Relevant entries from the log are given in the Appendix at the end of this article.

Accessing ~/Documents by consent

When the Open by consent button is clicked, Insent first tries to obtain a listing of the Documents folder. That request is considered to be sandboxed, so the sandbox service requests authorisation to proceed from TCC.

When it receives that request from sandboxd, TCC first checks whether the requesting app has been granted Full Disk Access, formally the kTCCServiceSystemPolicyAllFiles service. An early step in that sequence is to establish the attribution chain, so TCC can check the correct process, in this case Insent’s executable code.

A second check is then started, to determine whether the requesting app has been granted the more restricted service of kTCCServiceSystemPolicyDocumentsFolder. Those requests are followed by many validation checks on the Insent executable.

The simplest outcome is that Insent has kTCCServiceSystemPolicyAllFiles, in which case access is granted to the sandbox, and the Documents folder is listed as requested.

If Insent doesn’t have that, TCC considers kTCCServiceSystemPolicyDocumentsFolder:

• if that has already been granted, TCC tells the sandbox to grant access;
• if that has neither been granted nor denied, TCC displays the dialog requesting user consent, and acts accordingly;
• if that had been granted but has been disabled (denied) in Privacy & Security, TCC denies access without seeking any consent.

This demonstrates an important difference in the behaviour of Full Disk Access (kTCCServiceSystemPolicyAllFiles) and locations protected by Files & Folders (here kTCCServiceSystemPolicyDocumentsFolder). Disabling Full Disk Access doesn’t deny access, it just doesn’t enable it. Disabling a specific protected location in Files & Folders will deny that app access to that location.

If you want to return an app’s Files & Folders settings to the default, so you will be prompted to consent for access, you therefore need to remove that app’s entry from Files & Folders, and might also need to log out and back in, or restart, to ensure that’s put into effect.

These are summarised in the diagram above. For the sake of simplicity, access granted under SystemPolicyAllFiles isn’t shown separately, but merged with that under SystemPolicyDocumentsFolder.

Interactions between Full Disk Access and individual access in Files & Folders can appear complicated, even random at times, but are actually the result of logical decisions. They are also reflected faithfully in Privacy & Security settings. For example:

• Remove all settings for Insent from both Files & Folders and Full Disk Access.
• Open Insent, click on Open by consent, and agree to add the app to Files & Folders with Documents access.
• Quit Insent, and disable its Documents access in Files & Folders but don’t remove it. Then add Insent to the Full Disk Access list.
• Confirm that Open by consent still functions correctly, because its Full Disk Access setting overrides Files & Folders, as shown in the latter settings. Quit Insent.
• Remove Insent from the Full Disk Access list, and it will be listed in Files & Folders with access to Documents disabled once again.

Summary

• If the app at the head of the attribution chain has been given Full Disk Access, access to list and read files will be given.
• If not, then location-specific access in Files & Folders will be applied.
• If there’s no setting for that app and location, the user is asked for consent.
• If that app has already been given consent for that location, access to list and read files will be given.
• If that app has consent denied or disabled, access to list and read files will be denied.
• None of these controls apply to access by user intent in a File Open dialog, or to writing files.

Open and Save Panel access

As I have made clear, when a user expresses their intent to open a file by selecting it using the Open and Save Panel, that doesn’t trigger the same system of access rules. However, the request is still considered by TCC, this time using the Attribution Chain to examine the app rather than that panel service.

When looking briefly at log entries for that sequence, I noticed something odd: instead of the TCC access request being made for a location-related policy such as SystemPolicyDocumentsFolder, it’s recorded as kTCCServiceScreenCapture. Whether that’s a bug or intended behaviour, the request was authorised, and access proceeded.

The first time I saw that, I was so surprised that I repeated the test using Insent to confirm that I wasn’t misunderstanding the log entries. Exactly the same happened a second time, despite Insent having nothing whatsoever to do with making screenshots.

Previously

Consent, intent and privacy
Privacy: protected folders

Appendix: Log Extracts

Each entry is prefaced with the clock time in seconds.

Request, dialog and approval:

In this case, Insent hadn’t made any prior request to access the Documents folder in that session, so had no entry in Privacy & Security settings. When its access dialog was displayed, consent was granted, allowing access to proceed. As with other extracts, this starts with the event marking the button click in Insent.

1.204592 Insent sendAction:
1.205160 Insent: trying to list files in ~/Documents
1.205828 sandboxd request approval
1.205919 sandboxd tcc_send_request_authorization() IPC
1.206291 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.94, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
1.207414 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2232, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
1.235893 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.95, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,
[TCC then makes various checks on Insent]
1.261591 com.apple.TCC AUTHREQ_PROMPTING: msgID=440.95, service=kTCCServiceSystemPolicyDocumentsFolder, subject=Sub:{co.eclecticlight.Insent}Resp:{TCCDProcess: identifier=co.eclecticlight.Insent, pid=2232, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent},
1.265001 com.apple.TCC No usage string found (key:NSDocumentsFolderUsageDescription) for client[2232] in bundle:[private]
1.265006 com.apple.TCC display_prompt: called for [private] for service kTCCServiceSystemPolicyDocumentsFolder
[The access dialog is displayed, and consent given]
3.798770 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
3.802225 com.apple.chrono appAuth:co.eclecticlight.Insent] tcc authorization(s) changed
3.809558 Insent: trying to look in ~/Documents for text files
3.809691 Insent: trying to read from: /Users/hoakley/Documents/asHelp.text
3.842101 Insent: read from: /Users/hoakley/Documents/asHelp.text

Request after approval:

In this case, Insent had already been granted consent to access the Documents folder, as recorded in Privacy & Security settings.

0.911529 Insent sendAction:
0.912220 Insent: trying to list files in ~/Documents
0.913379 sandboxd request approval
0.913482 sandboxd tcc_send_request_authorization() IPC
0.913953 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.100, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
0.915394 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
0.949736 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.101, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,
[TCC then makes various checks on Insent]
0.970955 com.apple.TCC AUTHREQ_RESULT: msgID=440.101, authValue=2, authReason=2, authVersion=1, desired_auth=0, error=(null),
0.971072 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
0.973350 Insent: trying to look in ~/Documents for text files
0.973532 Insent: trying to read from: /Users/hoakley/Documents/piklisting.text
1.035508 Insent: read from: /Users/hoakley/Documents/piklisting.text

Request denied:

In this case, Insent had previously been given access to the Documents folder, but that was then disabled.

1.033344 Insent sendAction:
1.034069 Insent: trying to list files in ~/Documents
1.035189 sandboxd request approval
1.035299 sandboxd tcc_send_request_authorization() IPC
1.035820 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.108, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
1.037404 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2303, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
1.071652 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.109, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,
[TCC then makes various checks on Insent]
1.093533 com.apple.TCC AUTHREQ_RESULT: msgID=440.109, authValue=0, authReason=4, authVersion=1, desired_auth=0, error=(null),
1.093669 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder denied by TCC for Insent
1.094007 Insent: couldn't get contents of ~/Documents

Open and Save Panel Oddity:

In this case, the Open from folder button in Insent was used to select the Documents folder, ready to allow the app access by intent. This extract shows what happened after the button in the Open and Save Panel was clicked.

8.800555 com.apple.appkit.xpc.openAndSavePanelService trackMouse send action on mouseUp
8.802062 com.apple.appkit.xpc.openAndSavePanelService tcc_send_request_authorization() IPC
8.802140 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=2259.2, function=TCCAccessRequest, service=kTCCServiceScreenCapture,
8.802469 com.apple.TCC AttributionChain: responsible={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, responsible_path=/Applications/Insent.app/Contents/MacOS/Insent, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.appkit.xpc.openAndSavePanelService, pid=2259, auid=501, euid=501, binary_path=/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/com.apple.appkit.xpc.openAndSavePanelService.xpc/Contents/MacOS/com.apple.appkit.xpc.openAndSavePanelService},
8.809596 com.apple.TCC Handling access request to kTCCServiceScreenCapture, from Sub:{co.eclecticlight.Insent}Resp:{TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, responsible_path=/Applications/Insent.app/Contents/MacOS/Insent, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, ReqResult(Auth Right: Unknown (None), promptType: 1,DB Action:None, UpdateVerifierData)
8.809609 com.apple.TCC AUTHREQ_RESULT: msgID=2259.2, authValue=1, authReason=5, authVersion=1, desired_auth=0, error=(null),

On Sunday I introduced some of the principles involved in the protection of folders, to preserve your privacy, and provided a small test app, Insent. This article follows on with additional concepts, details, and a new version of Insent that writes diagnostic information to the log. This article refers to privacy protection as implemented in macOS Tahoe 26.4.

The macOS privacy system is more formally known as Transparency, Consent and Control (TCC), and is built around its manager tccd, working alongside the security system and the sandbox service sandboxd. The last might surprise those who thought that sandboxing was only required for apps provided in the App Store, but this sandbox is different.

How it works

When an app makes certain types of request of the file system, including those seeking a list of files (e.g. with FileManager’s contentsOfDirectory() method), or opening a file for read access, that request is passed to sandboxd for approval. That in turn queries TCC to discover whether that app should be authorised for that access. Depending on the path to be accessed, TCC checks in its database of policy approvals, runs various safety checks on the app’s signature and other properties, then tells sandboxd whether the request should be approved or denied.

As I revealed in the previous article, TCC’s controls over folders only apply to reading their directory and file contents. If an app wants to write a file to one of those protected locations, privacy restrictions don’t apply, only conventional Posix permissions. This is easily verified using the Save buttons on the left side of Insent’s window, which can write test files wherever you as a user have sufficient privileges. This is an important distinction, and a consequence of TCC’s purposes.

Reading directory listings and file contents is also different when it’s a user intent. This is most characteristically performed using the File Open dialog, where only the user gets to see the lists of files, and has complete control over which file is opened. This is handled by a separate XPC process, the Open and Save Panel Service, which has automatic approval. The same mechanism applies to the Open Recent command, drag-and-drop, double-clicking the document, and using the Finder’s Open command.

Attribution

The Open and Save Panel Service is also an example of another fundamental concept in macOS privacy protection, that of the attribution chain.

This is often encountered when considering how privacy protection can be applied to command tools that lack a GUI that could support TCC’s dialogs. Ultimately, each process has a GUI app responsible for it, and it’s that app which TCC uses as the front-end. In the case of most command tools that are run from Terminal, the attribution chain ends in Terminal.

If you want your command tools to have Full Disk Access, you thus add the Terminal app to the list in Privacy & Security settings. The disadvantage of this design is that it gives Full Disk Access to all command tools run in Terminal’s shell, and could get you into trouble if one turns out to be flawed or malicious. This can be exploited by ClickFix attackers, which trick you into pasting malicious commands into Terminal, and is a good reason for not leaving Terminal with Full Disk Access any longer than is necessary.

Daemons or services, whose name normally ends in d, are seldom run from Terminal, and when they require Full Disk Access can be added as individual binaries, although they can’t normally be given access to individual Files & Folders.

Protected folders

I’ve been unable to discover a comprehensive and up-to-date official list of protected folders and locations, but the following appear to be those most frequently used:

• ~/Documents
• ~/Downloads
• ~/Desktop
• removable volumes
• iCloud Drive
• third-party cloud storage
• network volumes
• Time Machine backups.

The first three are by far the most common in most Macs, with Removable Volumes close behind. Others are more dependent on your hardware configuration, for example whether you use network shares or third-party cloud services.

Purpose

The overriding principle in privacy protection is to minimise access given to potentially sensitive files.

Apps that are intended to access files anywhere or everywhere, such as backup apps and those used to detect duplicate files, should normally be given Full Disk Access, as should be advised in their documentation. That requires you to put trust in them not to abuse their privilege, and in their supplier to ensure they aren’t the victim of a supply-chain attack. If you have any doubts whatsoever, don’t install that app, and certainly don’t give it Full Disk Access.

Other apps should only be given access to Files & Folders when you’re invited to give your consent in one of TCC’s dialogs, and then only if you consider the app has a sufficiently good reason to be given that access, and can be trusted not to abuse it. All this should be explained in the app’s documentation, and better apps cover it in their onboarding sequence.

The Files & Folders list is different from Full Disk Access. You pick and choose which apps to give Full Disk Access to, and can leave an app listed there but with access disabled, to ensure it will remain blocked. TCC decides which apps are offered for inclusion in the Files & Folders list on the strength of their making a request of the file system that triggers sandboxd to ask TCC if it has been approved for such access. You can’t add apps of your choice, but you can disable an access that has already been granted, and remove that app from the list.

In the next article I’ll show what happens in the log when sandboxd and TCC are in action. This has been made much easier in a new version of Insent which writes detailed entries in the log. If you want to study those, Insent 1.1 is now available from here: insent11
For those who don’t want to dive that deep, version 1.0 is the same in all other respects, and is available from here: insent10

I hope you enjoyed Saturday’s Mac Riddles, episode 354. Here are my solutions to them.

1: In favour of a Scot who was mostly the biggest for almost 20 years until last month.

2: Waterproof novel with a magnetic latch until 2019.

3: Opening shot for unknown number like a pizza box in a rack.

The common factor

I look forward to your putting alternative cases.

Privacy protection changed radically in macOS Mojave and Catalina, but in the last couple of weeks I have realised how seven years later it’s still commonly misunderstood. While most can see how it protects access to hardware resources like the camera, and app data such as calendars, when it comes to Files & Folders and Full Disk Access, many remain hopelessly lost. This compromises our privacy, as all too often we end up giving an app Full Disk Access when it doesn’t need it.

Much of this confusion is the result of inadequate explanation, or to be more blunt, total absence of information. Apple’s otherwise commendable account of privacy controls barely mentions Macs and concentrates almost exclusively on iPhones, which don’t have Full Disk Access, and whose Files & Folders control is primitive by comparison. The Platform Security Guide also has remarkably little of relevance to say. Perhaps the closest we have to a conceptual account is that given by Kelly Yancey in his section of the Advances in macOS Security presentation at WWDC19.

Perhaps the most prevalent mystery is why a user’s Documents folder should be protected, and why so many apps need to ask for access to that folder? Before answering that, we need to understand two underlying concepts, of consent and intent.

It’s precisely because the Documents folder is so popular for our documents that it needs protection. A rogue app with uncontrolled access might be able to acquire tax and financial details, as well as having access to much of your personal information. So we need control over which apps can access which files there.

When we want to open a document, we express our intent to access its contents when we open that document in a File Open dialog, using Open Recent or a similar command, or by double-clicking the document. We choose the app we trust with the document’s contents, and the document, in our intent.

When an app wants to open a document without our direct involvement there’s the danger that, no matter what the file’s permissions might say, we don’t want a page layout app looking through our tax returns. For those apps we trust to have direct access to files in our Documents folder we thus give our consent to that action. If the app asks for access and we don’t trust it, then we refuse our consent, and the app is locked out.

Thus, the only ways that an app can open documents in the Documents folder are by our intent, or by giving our consent, and those involve different processes.

To help understand this more clearly, I’ve put together a little app Insent, a portmanteau of the words intent and consent. I also thought you might appreciate the Hallowe’en pumpkin in its icon.

Here I’ll use just two of its six buttons to draw the distinction between intent and consent. Once you’ve unarchived Insent’s folder, drag the app from there to one of your Applications folders, or somewhere similar, to run it. Open the app, click through its standard notarisation dialog, and you’ll see its main window.

Insent can read and write text files with the extensions .txt or .text. Confirm that it can open one in a protected location like your Desktop or Downloads folder by clicking on its Open by intent… button at the top right. You’ll see a standard File Open dialog in which you can select and open that file, and its filename and the opening characters of that file will be shown in the text boxes below. There will be no request to give access to that protected folder (consent) as you have expressed your intent to open that file.

Next, ensure that your Documents folder has at least one text file accessible at its top level. Then click on the Open by consent button. Instead of asking you which file to open, Insent now chooses that by itself, picking a text file at random from inside your Documents folder.

You should now see this dialog requesting your consent to allow that access to go ahead. Click on the Allow button, and the filename and text will then be displayed in those two text boxes, confirming Insent was given access.

You’ll also see Insent has been added to the Files & Folders section in Privacy & Security settings, with access specifically to the Documents folder.

Confirm that control does what it claims by quitting Insent, turning access to the Documents folder off, opening Insent, and clicking on Open by consent again. Now instead of seeing the filename, you’ll see the message that Insent [Couldn't get contents of Documents folder], because you withdrew your consent.

With that privacy control still disabled, try clicking on the Save by consent… button. This writes a brief text file whose name starts with Insent followed by a UUID into your Documents folder – the same folder you’ve withdrawn consent from, and where it can’t read a text file. But if you click on Open by intent… and select that same file there, so expressing your intent to open it, it should still open normally.

These few minutes have shown:

• Folders including ~/Documents are protected to restrict reading not writing files.
• Apps retain the ability to read files in protected folders by user intent, when explicitly opening the file.
• Apps themselves can only open files in protected folders with express user consent.
• Each consent in Folders & Files is limited to the app and the protected folder.
• Consent will be sought automatically when an app tries to access a protected folder.
• When consent has been given and is then disabled, the app will be denied access to files in that protected folder.

So the next time you’re invited to give an app access to a protected folder, you’ll know that it’s trying to access its contents. If you don’t think that app should have free access to the files in that folder, deny that request, and don’t whatever you do be persuaded to give the app Full Disk Access just to have a quieter time, or because Support recommends it.

Insent version 1.0 for macOS 13.5 or later is available from here: insent10
and I’ll be returning to it later next week.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: In favour of a Scot who was mostly the biggest for almost 20 years until last month.

2: Waterproof novel with a magnetic latch until 2019.

3: Opening shot for unknown number like a pizza box in a rack.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Easter eggs are part of the tradition of this time of year, and the term applied to concealed features in computer hardware or software. It seems to have originated in early video games, although the first record is in the command make love on DEC PDP-10 mainframes in 1967-68. Macs have had their fair share over the years, although Steve Jobs seems to have disliked them, and is reported to have banned them. Here are a few that I’ve come across in more recent years.

Clarus the Dogcow

This mythical animal from the Mac bestiary has been tucked away as an Easter egg in the Emoji & Symbols viewer for many years. Type the letters clarus or moof (the sound it makes) into the search box of that viewer to see the two emoji figures of a dog and a cow, although neither of them resembles Clarus in appearance, as shown in the Page Setup window in recent macOS.

Marijuana leaves

More inaccessible, but apparently present for even longer, is a PNG image showing marijuana leaves embedded inside the Chess app. To see these, select Chess.app, and Show Package Contents. Work through the Contents, Resources and Styles folders and you’ll see two styles Fur and Grass, neither of which is offered in the app’s Settings. In the Grass folder, select Border.png to see a pattern of marijuana leaves.

I’ve been unable to find a way of accessing these as a style for the app, though. Chess also has a unique About window that not only contains the full GNU licence for the app, but offers a button to download the app’s source from Apple’s Open Source Releases page. Perhaps the intention is that you can build your own version of the app giving access to the Grass and Fur styles, making it the most convoluted Easter egg.

MAC wallpaper

According to a recent report in MacWorld, the colour-matched wallpapers provided for MacBook Neos spell out MAC.

Dont Steal Mac OS X

This is a kernel extension named Dont Steal Mac OS X.kext, found in /System/Library/Extensions, whose sole purpose is to contain Apple’s copyright statement, and in its own words “to protect Apple copyrighted materials from unauthorized copying and use.” Oddly, the current version claims copyright over the period 2006-2020 in its Info.plist, but 2006,2009 in its licence resource.

Minimise (defunct)

Until a few years ago, the yellow Minimise button in windows featured a set of Easter eggs that are claimed to have been a favourite of Steve Jobs. Clicking on that button with Control, Shift or Control and Shift keys held ran the animation at widely different speeds, and could be reversed when clicking on the minimised window in the Dock. These are described here, but have been removed since then.

RAM disk (defunct)

According to a relatively recent report in Tom’s Hardware, the ROM of Power Mac G3 models contains an Easter Egg of a hidden file when a RAM disk is created with the name secret ROM image.

I look forward to your sharing more.

Reference

Wikipedia

Macs are well known for their longevity, and are substantially cheaper when purchased used. This is a good time to consider buying a used Mac, as prices for Intel models are continuing to fall, and earlier Apple silicon models are becoming more widely available. However, buying any used computer is higher risk than buying new. This article explains how to reduce that risk.

Official refurbs

If you’re looking for discounted recent models, then the best place is Apple’s refurb store, in your local version of this page. These should be effectively as new, and include relatively recent models, but you’re unlikely to make big savings here. They’re ideal if you enjoy unboxing, as refurbs ship in their standard packaging.

Resellers

Most countries have retailers who specialise in preparing and selling used Macs. Among the best known are:

• MacSales, part of OWC, covering USA and Canada
• Hoxton Macs, in the UK
• MacFinder, in the UK.

These are staffed by Apple-trained technicians who check each Mac thoroughly. They offer a wider range of models, many of them at highly affordable prices. Most offer a return period, as well as a one-year warranty, and are subject to local consumer protection law.

Private vendors

My one and only golden rule is never to buy a used Mac without seeing it in the flesh beforehand. That bargain a thousand miles away could turn out to have been stolen, and even if it’s genuine you could still end up with a useless Mac. I’ve never heard of anyone buying a house or car without seeing it for themselves, and a Mac should be no different. I suppose it’s feasible to go through the following checks over FaceTime or Zoom, but there are so many skilled con artists around I wouldn’t risk it.

When you arrive and see the Mac you’re about to purchase, work systematically through the following.

Provenance

Your first and most important question is whether this Mac is the seller’s to start with. The best answer comes in the form of its original proof of purchase, giving its serial number. Check that matches the serial number in Hardware Overview in System Information. If it doesn’t, then thank them politely and leave as quickly as you can. While you’re looking in that section, if the Mac has a T2 or Apple silicon chip, at the foot of that information you’ll see its Activation Lock Status: if that’s enabled, make a careful note, as you’ll need to get that disabled before you take your new Mac away. Intel Macs without T2 chips don’t have that to worry about.

Establishing provenance gets more complicated if that Mac has had more than one previous owner, but the current owner should ideally have a chain of bills of sale to reassure you. If they don’t, then that Mac may well have a murky past that could catch up with you.

Condition

Once you have confidence that you’re dealing with the real owner of the Mac, check it out as thoroughly as you can, without rushing or stripping it down to its logic board. A careful and undistracted visual examination is important, and gives clues through its general cleanliness as to how well it has been cared for.

It would be comforting to run hardware diagnostics just in case, although that’s not a particularly sensitive check for incipient problems. In ideal circumstances you’d want to check wear and any errors on its internal SSD using DriveDx or another SMART utility, but you’re unlikely to get the chance. If you have a friend who is a hardware technician, they could be a real boon to take along, just as you should take a good mechanic when you check out a used car.

AppleCare

If the current owner has AppleCare cover on that Mac, they should in most cases be able to transfer that with its sale. This requires them to sign into My Support for the agreement number and details, and with the original sales receipt for that Mac, to contact Apple Support and give them your details as the new owner. Apple explains this here, with useful onward links.

Haggle

I wish you success in agreeing the best price.

Activation Lock (Intel T2, Apple silicon)

The last hurdle in a successful purchase is the one most often forgotten, and the cause of much buyer remorse. It’s all the fault of Activation Lock and Find My Mac. These ensure that the owner’s Apple ID and password are required before that Mac can be used, erased, or Find My Mac disabled. In effect they make that Mac useless to anyone else until Activation Lock has been disabled.

Macs with T2 or Apple silicon chips running Catalina or later, where the user has 2FA on their Apple ID, are likely to be protected by Activation Lock. There is an additional requirement, depending on their architecture:

• Apple silicon Macs must have their security policy set to Full Security;
• Intel T2 Macs must have startup security set to Secure Boot, with booting from external drives disallowed.

Activation Lock is most commonly enabled when Find My Mac is turned on, and turning that off also disables Activation Lock. That requires entry of the current user’s Apple ID password, so must be done by the seller before they part with their Mac.

There are other ways to disable it:

• It’s automatically disabled when the owner runs Erase All Content and Settings, only available on T2 and Apple silicon models anyway.
• Activation lock can be disabled in the owner’s account at www[.]iCloud[.]com/find by removing that Mac from the list of All Devices there.
• If you have proof of purchase, you can request Activation Lock to be removed by Apple support, but that’s a last measure and not something you should ever choose.

Apple’s guidance is here.

Never take possession of someone else’s Mac while its Activation Lock is active, as it will only cause you trouble and grief.

Handover

If everything is going well, you should be ready for the Mac to be handed over to your possession, accompanied by a written record of the sale. The conclusion is best seen as a mutual arrangement, as it gives the seller confidence that any data on that Mac is completely erased, and you the confidence that you’re about to gain a Mac you can use.

If it’s an Intel Mac, confirm with one another that it starts up without requiring a firmware password. If it has a T2 or Apple silicon chip, use its Erase All Content and Settings together to ensure that all its old files are made unreadable, and to be certain that Find My Mac and Activation Lock are disabled. Sadly, erasing older Intel Macs without T2 chips is a slower and more complicated process.

Checklist

• Inspect the Mac before handing over any money.
• Check proof of purchase and serial number, noting Activation Lock status.
• Visual examination, check SSD health if possible.
• Agree the price.
• Transfer AppleCare if available.
• Disable Activation Lock (in EACAS if available).
• Obtain written record of sale.
• Ensure no firmware password (Intel only).
• Erase, preferably using EACAS where available.

I hope you enjoyed Saturday’s Mac Riddles, episode 353. Here are my solutions to them.

1: The future was here 25 years ago when the fastest land animal arrived.

2: This atelier came with more than a marathon four years ago.

3: Wicked fast at 40 MHz, its special effects impressed 36 years ago.

The common factor

I look forward to your putting alternative cases.