Removing privacy censorship from the log

The Unified log presents two major problems, which at first might appear contradictory:

  • it contains far too many entries,
  • too many of its entries have important content censored for privacy.

While many of my articles have been devoted to techniques you can use to tackle the first of those, from excluding entries using log preferences to predicates and filters, I haven’t addressed the problem of censorship for a couple of years now. This article corrects that, and provides a configuration profile that you can use in all versions of macOS from Catalina to Ventura to uncensor the log.

Removing <private>

I’m a great believer in privacy, and in Apple’s exemplary protection of it in the Unified log, but there are times when we need to know what the log normally censors using <private>.

If you’re running macOS 10.12 to 10.14, you can disable this censorship using the command
sudo log config --mode 'private_data:on'
sudo log config --mode 'private_data:off'
turns it back on again.

This changed with Catalina. Provided that you’re running 10.15.3 or later, privacy can be removed by installing a configuration profile first provided by George Garside. Because his signature on that profile has long expired, I’ve taken the liberty of revamping the profile gently, and signing it using my Developer ID Application certificate, which doesn’t expire until 1 February 2027. This new configuration profile is here: enablelogprivatedata and I will add it to the Ulbow distribution archive in future updates.

Install the profile

Unzip the archive into a convenient folder and double-click it. You’ll be informed by a notification that you need to review the profile to install it.


Open System Settings > Privacy & Security > Profiles, and select the new profile there. If you prefer, you could start off by opening this setting and clicking on the + tool to add the profile directly.


To accept it, double-click it.


You’ll then be shown information about the profile and its signature. Click on the Install… button, you’ll then see a reminder about removing the profile as soon as you no longer require it, and you’ll be invited to authenticate to complete the installation.


The Unified log doesn’t start storing uncensored data until the profile has been installed and takes effect. The profile can’t retrospectively unmask previously censored entries, as the private data simply doesn’t exist until the profile has been applied. Give it a couple of minutes, then open Ulbow and obtain some log extracts for periods since the profile has taken effect. Search them for tell-tale <private> content, and you should find those only in networking entries, and not more generally.

All the time that this profile is installed, uncensored private information will be written into the log. That only stops when you remove the profile using the – tool in Profiles settings. Censorship isn’t retrospective, though: those entries containing private information remain in the log until they are weeded out.

I strongly recommend that you only leave this profile active for as long as you need log entries to be uncensored, and immediately remove it when that’s no longer required. Don’t forget!

When you have removed the profile, it makes good sense to check a few minutes later that fresh log entries have returned to censoring private data as before. If they haven’t, restart your Mac and check the profile has been removed properly, and censorship is being applied.

Network diagnostic logging

You’ll have noticed that the Unified log doesn’t contain much information about network traffic. If you want to look at that, Apple recommends using CFNetwork diagnostic logging, and details how to do that in your own code. This is particularly valuable, as it can contain decrypted TLS data, but as described that’s only available within code you control.

It was the prolific Jeff Johnson who described how to use that same diagnostic logging in macOS. To enable it, enter the following command in Terminal:
sudo launchctl setenv CFNETWORK_DIAGNOSTICS 3
then authenticate. Existing processes won’t provide diagnostic information, though. If you need one to do so, stop it in Activity Monitor, and when macOS restarts it, diagnostic logging should then be enabled. He has used this to observe traffic from syspolicyd, for example.

When you’ve finished, use the command
sudo launchctl setenv CFNETWORK_DIAGNOSTICS 0
to restore normal logging.

Logging profiles

System-level profiles vary widely across different subsystems, and you can modify those to your advantage to adjust the detail shown in the log. For example, to see current settings for log entries for the subsystem, use the command
sudo log config --status --subsystem
and you should see the response
meaning that log entries are made at a debug level, the most comprehensive, and that all log entries, even at a debug level, are retained in the Persist tracev3 files rather than being stored ephemerally in memory.

You can change those system settings using commands of the form
sudo log config --mode "level:debug" --subsystem
and by installing your own property lists, as explained here.


To test the effectiveness of the profile and CFNETWORK_DIAGNOSTICS setting, I removed censorship and enabled network diagnostic information as described above, then launched a copy of LockRattler. This enabled full log entries such as
2.299527 LockRattler Network [C1 111EA42A-A793-4C95-86AD-195D27E78206 tcp, url hash: dcfe7d55, tls, definite, attribution: developer, context:{44F8F23F-61D0-42B7-A7A2-C56544302732}{(null)}{Y}{2} (private), proc: 19EF9570-D92A-3016-9DE7-457EE823FAC2] start
2.299534 LockRattler Network nw_endpoint_handler_start [C1 initial parent-flow ((null))]

which look good to me, and a great improvement on defaults.


  • Remove privacy censorship in the log using the configuration profile provided.
  • Gain detailed network diagnostic information using the CFNETWORK_DIAGNOSTICS setting.
  • Adjust logging profiles as necessary, to include Debug entries.
  • Remember to remove the profile and return CFNETWORK_DIAGNOSTICS to default as soon as possible.
  • Changing those settings leaves private data in the log until those entries are removed in routine housekeeping.