Macs have developed their own mythology, and this week I unintentionally came across a myth that developed over a year ago. Like so many it was born from a chance observation, this time of a new background process that appeared on 25 October 2023 in macOS Sonoma 14.1, and was reported in 9to5Mac on 3 November 2023.

Discovery

The process in question is liquiddetectiond, and as 9to5Mac’s headline claimed, it meant that “Macs can now inform Apple if any liquids have been detected in the USB-C ports”. That article argued that “it seems more likely that the data collected by this daemon will be used for technicians to determine whether a Mac is eligible for free repair.” “Putting a digital liquid detector on USB-C ports is just another way to ensure that technicians are right about claiming that a Mac has been exposed to liquids.”

That, and a couple of linked reports elsewhere, brought a small flurry of comments about how typical this was of Apple, then all went quiet until 9to5Mac’s article was picked up by Hacker News on 9 January 2024 and generated 340 comments. Predictably, most either castigated Apple’s behaviour or disappeared down rabbit holes about unrelated topics. Among them, though, was one precious insight: “It prevents the device from applying/draining power from any pin in such a state, mainly to reduce corrosion of the contacts and increase longevity.”

By the middle of January last year, the story had gone cold, and everyone must have gone away with their worst fears confirmed. You couldn’t even get a USB-C port damp in your Mac any more, as Apple would use that as an excuse to void your Mac’s warranty.

Documentation

Apple’s first word on the subject seems to have been in a support note published on 23 November 2024, which passed largely unnoticed. This announced liquid detection as a feature new to macOS Sequoia when running on only the following models:

• MacBook Air M3 and later
• MacBook Pro with M3 Pro or Max
• MacBook Pro with M4 base, Pro or Max

none of which had been released at the time of 9to5Mac’s report, although the second were released four days later, on 7 November 2023.

If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, this new sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry.

This is in addition to, and separate from, what Apple terms Liquid Contact Indicators (LCI), that have long been fitted to laptop Macs and some Apple wired and wireless keyboards “to help determine if these products have been exposed to liquid,” according to this support note.

Was Apple just making excuses, or was this new liquiddetectiond service intended to benefit the user?

Evidence

I stumbled into this innocently last week when I was looking at Accessory Security, a feature confined to laptop Apple silicon models. By chance, the laptop I was using was a MacBook Pro M3 Pro, one of the few in which liquid detection works. There, on several occasions in its log, after connecting a Thunderbolt cable, its liquid detection system checked that the USB-C port was dry, in a series of log entries like:
0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
(Times given in seconds elapsed.)

But on my more recent Mac mini M4 Pro running Sequoia, all I saw was that LDCM is not supported on this device.

Attempts to connect over the network are obvious in the log, and on not one of the occasions that liquid detection was performed did that MacBook Pro try to connect to any remote site. Maybe its reports could have been embedded in other analytics data passed to Apple later, but there was absolutely no evidence that the results of liquiddetectiond went beyond the confines of my Mac.

This demonstrates the importance of testing out hypotheses, and of reading the log. Even without the benefit of Apple’s recent support note, it should have been easy to demonstrate this behaviour, yet no one seems to have attempted to.

Explanation

Claims made of the role of liquid detection in USB-C ports also don’t make sense. As with most laptop manufacturers, Apple already builds Liquid Contact Indicators into components of laptop Macs within their case. These are most frequently affected by spillage of drinks on a laptop’s keyboard, resulting in any of a wide range of water-based liquids from coffee to cognac entering the case. That often results in extensive damage to the logic board and other components, that are expensive to replace.

But a damp USB-C port is quite a different matter. It could occur in a laptop that had been out in the cold and was then brought into a warm and more humid environment, the same sort of conditions that steam up your spectacles. Over time, that could lead to corrosion of the contacts in the USB-C ports, and unreliable connections.

Because each release of macOS is identical across all models of Mac, although only a few of the most recent models feature liquid detection sensors in their USB-C ports, the liquiddetectiond service runs in the background of all Macs running Sequoia. It’s to be found inside /System/Library/CoreServices/liquiddetectiond.app, which isn’t even a bundle, just its Mach-O binary and an image of the warning sign displayed. It’s run through its LaunchDaemon com.apple.liquiddetectiond.plist, which you’ll also find in the SSV of every Mac.

As is so often the case, the truth behind the myth is more prosaic, and doesn’t involve Apple secretly capturing data from your Mac, nor conspiring to dodge warranty repairs. In fact, if you look at the warranty terms of pretty well every other laptop manufacturer, they too exclude damage caused by liquid ingress, as demonstrated by their Liquid Contact Indicators. And some are also starting to fit similar liquid detection sensors in their USB-C ports. But don’t let those get in the way of a good myth.

If you have a laptop Apple silicon Mac, you’ll no doubt have discovered one of its novel features: connect a USB or Thunderbolt peripheral to one of its USB-C ports, and you could be asked whether to allow it to connect, as a result of its Accessory Security. This isn’t available in desktop models, though. This article explores how it works and how it’s associated with liquid detection.

Accessory Security setting

At the foot of the Privacy & Security section of System Settings in capable Macs is an extra control Allow accessories to connect. In macOS Sequoia this has four options:

• Ask Every Time, which prompts you to approve every time you connect a peripheral to a USB-C port.
• Ask for New Accessories, which only prompts you to approve devices that it hasn’t connected previously. However, if your Mac is locked for three days or more, it may ‘forget’ devices that it approved previously, and require you to approve each again.
• Automatically When Unlocked, which connects all devices without prompting, so long as that’s done when that Mac is unlocked.
• Always, which will never prompt you to approve a device.

This novel security mechanism is intended to prevent laptop Macs from being attacked using plug-in USB or Thunderbolt devices intended to breach their security. Apple considers laptop models to be most at risk, but surprisingly still hasn’t offered this as an option in any of its desktop models.

Approval

When you connect a USB or Thunderbolt device to one of your Mac’s USB-C ports, there will be a momentary delay and, if your approval is required, an alert will be displayed.

To approve or refuse that invitation, you’ll first need to unlock your Mac if it’s locked. Peripherals such as hubs and docks that can charge your Mac will still be able to do that even if you don’t allow them to connect, but all other features will be blocked until you click on Allow.

How it works

To examine how Accessory Security works, I connected a Thunderbolt 4 hub to a USB-C port on a MacBook Pro M3 Pro, which supports this feature, and a Mac mini M4 Pro, which doesn’t. The setting for the laptop was to Ask Every Time. I then captured their logs using LogUI and compared the contents of each.

Port activation

This consisted of a long sequence of entries from IOAccessoryManager detailing port activation and initial configuration. Here are some waymarks among those, with elapsed time given in seconds:
0.883 IOAccessoryManager IOPortTransportState::setActive(): [Port-USB-C@2: CC] active: YES (transportType: 1 [CC])
0.883 IOAccessoryManager IOServiceNotificationManager::handleServiceReregistration(): [Port-USB-C@2/CC] Re-registering service...
0.883 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB3... (transportType: 3)
0.884 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB2... (transportType: 2)
0.884 IOAccessoryManager IOPort::_updateConnectionActive_block_invoke(): [Port-USB-C@2] m_connectionActive: YES, m_connectionCount: 1, m_connectionUUID: F53E1B0B-8347-4528-B77C-FC79E8A657C5
The last entry there records the connection’s UUID.

Is it authorised?

Next, authorisation was assessed:
0.885 IOAccessoryManager IOPort::_updateAuthorizationState(): [Port-USB-C@2] Updating authorization state...
0.885 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: NO -> YES, authorizationPending: NO -> NO, userAuthorizationPending: NO -> NO, supervisedTransportActive: NO -> NO
Those will still appear in the log of a desktop Mac, but will say NO throughout.

There are repeated updates of the port’s pin configuration:
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPinConfiguration(): Updating pin configuration...
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setCableActive(): activeCable: NO
0.885 IOAccessoryManager 1605 IOAccessoryManagerUSBC::setCableOptical(): opticalCable: NO
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setDisplayPortPinAssignment(): dpPinAssignment: 0
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPlugOrientation(): plugOrientation: 2
0.885 IOAccessoryManager IOPortTransportStateUSB::setDataRole(): [@: IOPortTransportStateUSB3] Setting data role... (dataRole: 2 [Host])

Liquid detection

A little while later, in the laptop only, a hardware liquid detection sensor was checked, to see if there was any liquid present in the receptacle (port):
0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
On a desktop Mac running Sequoia, you’ll only see LDCM is not supported on this device.

Approval

Preparations are then made to display the approval dialog, and authorisation status is updated:
1.116 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: YES -> YES, authorizationPending: NO -> YES, userAuthorizationPending: NO -> YES, supervisedTransportActive: NO -> YES

As promised in Apple’s documentation, charging from the peripheral is enabled before approval:
2.639 IOAccessoryManager IOPortFeaturePower::_addPowerSource(): [Port-USB-C@2/Power In] Adding power source (powerSourceName: Brick ID)...
and the power chime may be sounded
2.718 gui/501/com.apple.powerchime xpcproxy spawned with pid 1677

Once approval is given in the dialog, this is recorded and the connection is then established fully:
4.709 IOUIAgent Received notification response! (userNotification: 0x620364480, .responseReceived: 1, .notificationCancelled: 0, .notificationDismissed: 0, userAuthorizationStatus: 2, port: <private>)
4.709 IOAccessoryManager IOPortUserClient::setUserAuthorizationStatus(): Setting user authorization status... (target: Port-USB-C@2, newUserAuthorizationStatus: 2 [Authorized])

Authorisation

Although Accessory Security settings are in Privacy & Security, much of which is concerned with controls implemented by TCC, protection and authorisation is here controlled by IOAccessoryManager. Its list of previously approved devices isn’t exposed to the user, and the only control is its single setting.

Liquid detection

The surprise feature is liquid detection, in the liquiddetectiond service and LDCM. This is a new feature in macOS Sequoia, and the following models:

• MacBook Air M3 and later
• MacBook Pro with M3 Pro or Max
• MacBook Pro with M4 base, Pro or Max.

If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, a sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry. Full details are given in this support note, dated 23 November 2024.

Previously, reports of this feature claimed that it was intended for use by Apple to determine whether a laptop Mac had been damaged by liquid ingress. Like all laptops, internal components of MacBook Air and Pro models contain several liquid sensors already intended to reveal whether ingress has occurred. Sensors in the USB-C receptacles are clearly different, and are being used to prevent damage by corrosion inside the receptacle, rather than limit warranty or AppleCare+ repairs.

Summary

• Accessory Security is available in all laptop Apple silicon Macs, and intended to prevent attack by malicious devices.
• A single control in Privacy & Security settings determines when approval will be required for devices to be connected to a USB-C port.
• This is controlled by IOAccessoryManager, which manages the initialisation and preparation of USB-C ports. TCC is not involved.
• Some laptop M3 and M4 models have liquid detectors in each USB-C port. These will alert you if liquid is found when connecting to a USB-C port. This is intended to prevent corrosion occurring inside the receptacle, not to detect damage caused by liquid ingress.

Working with older colour displays, particularly bulky and heavy CRT models, wasn’t easy. Colour calibration was all-important if you wanted what you saw on screen to look anything like what appeared from the printer. Apple’s newer displays, including the Studio, Pro Display XDR, and the high-end XDR screens in MacBook Pro models, are intended to be much less demanding in use while still producing faithful colour. Unless you’re a professional colour-grading video or achieving perfection in your photos, you should never need to calibrate these displays. This article explains how this works, and how you can tweak those displays to your own liking.

As I explained in my brief history of ColorSync last weekend, each device including displays has a limited range of colours it can reproduce, its gamut. To ensure consistency in the use of colour throughout macOS, each device has its own colour profile that’s used by ColorSync, the colour management system. In the past, those who cared about colour used a colour measurement device for display calibration, the production of a colour profile for ColorSync. For CRT displays this could be a lengthy procedure, as the display had to warm up fully before calibration could start, and the procedure had to be repeated periodically to ensure the profile matched the display as it aged.

Apple Studio, Apple Pro Display XDR, and MacBook Pro XDR internal displays are intended to have stable and standard calibrations over long periods. For example, the Studio display incorporates an A13 Bionic iPhone chip running a cut-down version of iOS 17 that is most likely involved. These displays are manufactured to meet a standard calibration supplied as a preset in macOS. The only option for display recalibration is to a ‘factory’ standard using high-end instruments, thus not something for most users to attempt. All you can do is tweak the presets provided, perhaps with the aid of a colorimeter to measure white point and luminance.

Presets are accessed in Displays settings, and include the master, named Apple Display (P3-600 nits), Apple XDR Display (P3-1600 nits) or similar. Below that is a list of variants for specific purposes. If you were to select Calibrate Display… at this point, all you could do would be to perform a full ‘factory’ calibration if you happened to have the right instruments to hand.

Instead, select the Customise Presets… command.

With the master preset selected, clicking the + tool to add a custom preset will create a copy of that, where you can mix your own preset. For this you can select:

• a colour gamut, default P3, with options including sRGB, PAL and NTSC;
• a white point, default D65, with options including D50, DCI and custom;
• an SDR transfer function, default Pure Power, with options of sRGB and others;
• whether to boost the system gamma;
• a maximum luminance, defaulting to 600 for SDR or 1,600 nits for HDR;
• whether to limit luminance to that achievable over the whole display.

When a custom preset (not the master) is selected, the Calibrate Display… menu command should offer you two fine-tune options as well as a full calibration.

Fine-Tune Calibration is intended for use with a colorimeter or other instrument that can measure white point and luminance.

You can then enter the measured values and those that you want from the display, through this fine-tuning.

The other option is to perform a Visual Fine-Tune, for which no measuring instrument is used.

All this does is allow you to select a custom white point from this matrix of colours.

For the great majority of users, those should be all you need to achieve faithful reproduction of colour on your display. If you feel that you need to be able to do more, then you’d probably be better looking at Eizo ColorEdge or similar products that offer more traditional calibration.

Good news: almost exactly three years after I reported that you couldn’t control what an Apple silicon MacBook Pro or Air does when you open its lid, Apple has addressed this.

Intel models

Since about 2016, Intel MacBook Air and Pro models may have an ‘auto boot’ feature, and either start up or wake from sleep when you open their lid. This behaviour is controlled by the AutoBoot setting in their NVRAM. If you want to disable auto boot startup, then open Terminal, type in the command
sudo nvram AutoBoot=%00
and authenticate with your admin password. When you next open the lid, that Mac won’t start up until you tell it to.

To disable that, and restore auto boot, enter the Terminal command
sudo nvram AutoBoot=%03
and authenticate again. It will also be restored if you reset NVRAM.

Apple silicon models

The procedure for Intel Macs doesn’t work in Apple silicon models, and the NVRAM setting that looked as if it might work, auto-boot, mustn’t be used as it can cause boot problems. Leave it well alone unless you fancy performing a full restore in DFU mode.

According to Apple’s recent support note, it’s now possible to change auto boot behaviour in MacBook Air and Pro models with Apple silicon chips using the BootPreference setting, when they’re running macOS Sequoia.

To disable auto boot when opening the lid or connecting to power, enter the Terminal command
sudo nvram BootPreference=%00
To disable auto boot when opening the lid, but for it still to work when connecting to power, enter the Terminal command
sudo nvram BootPreference=%01
To disable auto boot when connecting to power, but for it still to work when opening the lid, enter the Terminal command
sudo nvram BootPreference=%02

To restore normal auto boot behaviour, enter the Terminal command
sudo nvram -d BootPreference
to delete that setting in the NVRAM.

You can also list the contents of NVRAM with the command
nvram -p
which is helpful when you’re not sure what the setting is, or whether it has been removed from NVRAM altogether to return that Mac to its default behaviour.

Be particularly careful when making any changes to the NVRAM in an Apple silicon Mac: if you make a mistake there’s no easy way to reset the NVRAM, and your Mac could be taking a trip to DFU mode before it will work properly again.

Cleaning keys or trackpad

Auto boot only determines start up behaviour on opening the lid or connecting power. When the lid is open, pressing any key or using the touchpad will still cause the Mac to start up, so limiting use for cleaning its keys or touchpad. Apple recommends using compressed air, which shouldn’t start the Mac up, but if you prefer to use a dry cloth or isopropyl alcohol on a cloth (but never a water-based cleaner), then you may find it helpful to use KeyboardCleanTool to block key entry during cleaning.

Whatever you do, don’t let any water=based liquid near your Mac’s keyboard or other areas that could allow its ingress. Even small amounts of water can cause serious damage that can require expensive repairs. Like all laptops, MacBook Air and Pro models contain multiple water sensors, making that damage easy to detect. Water damage is included in AppleCare+, but will still cost you $299, and may not be covered by other insurance policies.

Many Mac notebooks lead a busy life. Although they might get a decent sleep, they’re seldom left idle when on mains power. This article looks at some of the tasks that can’t normally be run when a Mac is running on battery power, and may get left undone if it’s too busy when recharging.

Sparse bundles

The only user task among these might catch you by surprise. Sparse bundles (the disk images that store files inside a bundle folder rather than in a single file) may need to be compacted occasionally to ensure they don’t grow larger than they need. Because compaction can take a long time and can’t be interrupted without risking the whole sparse bundle’s contents, by default it won’t be performed when a Mac is running on battery power. That can be overridden in some utilities like my own Spundle, and in the hdiutil command.

Daemons and agents

Although I can’t find them documented anywhere, there are two keys used in the property lists used for LaunchDaemons and LaunchAgents that determine whether their activities and background services will be run when a Mac is running on battery power. AllowBattery is set to true when the service can be run on battery, or to false when it can’t. You will also come across the opposite, RequiresExternalPower, set to true when it can’t be run on battery, or to false when it can. Be careful interpreting their meaning.

Spotlight

Spotlight’s in-app service Core Spotlight consists of many services, some of which aren’t allowed when on battery. Those include:

• com.apple.corespotlightd.updateContacts in corespotlightd, which presumably updates information for Contacts’ database;
• several parts of com.apple.spotlightknowledged, which is concerned with ‘knowledge’ additions to Spotlight features. These include com.apple.corespotlight.knowledge and its subtasks for inference, journals, and updates;
• two parts of com.apple.photoanalysisd, used to analyse media content, in two parts backgroundanalysis and (surprisingly!) music;
• several debug services in com.apple.corespotlight.knowledge, which shouldn’t have any user impact.

XProtect Remediator

As we’ve recently realised, regular scans performed by XProtect Remediator (XPR) to detect and remove known malicious software can busy a whole E core for well over half an hour. Because of that, some of its services will only be run when a Mac is powered by mains (AC). There is a ‘fast scan’ that can still take place when on battery, but that doesn’t appear to work through the specialist scanning modules for known malware, and doesn’t record similar entries in the log.

You can observe this yourself after starting your Mac up for the day. If it’s running on mains power and left alone for 10-15 minutes, XPR will usually start scanning with each of its modules. However, if you start your Mac up on battery and leave it for a couple of hours, there’s no sign of those scans starting. This is the result of the AllowBattery key of both com.apple.XProtect.PluginService.agent.scan and com.apple.XProtect.PluginService.agent.slow.scan being set to false in XPR.

Consequences

Most of these services will normally run when a Mac is awake, but not in heavy use. If your Mac spends little time in that state with mains power connected, then they may not be run for many days. When they do get a chance, then you may see long periods during which these services take a significant % CPU in Activity Monitor. If you open its CPU History window on an Apple silicon Mac, you should see them running almost exclusively on the E cores. This ensures that they don’t affect what you’re doing, but they do need the time to do their work uninterrupted, when possible.

For XProtect Remediator, this means that its full scans to detect and remove malicious software won’t take place. While you can run them manually, for example using my free XProCheck, that only runs one set of the two that are normally performed when XPR is run automatically.

Lunch breaks

Many humans take a break at lunch, when they stop their normal work and engage in maintenance. Although some take the opportunity to catch up with their sleep, in most cases folk stay awake.

That’s a model that could allow your MacBook Pro or Air to catch up with some of these background tasks that it needs to have mains power for. Rather than closing its lid to force it to sleep, why not leave it open, awake, running without the load you normally impose on it, and catching up on its Spotlight services and, most important of all, running XProtect Remediator scans? That needn’t necessarily be every day, but a couple of lunch breaks each week could be beneficial for both of you.

I’m grateful to Michele for inspiring this from his own experience.