{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-07-29-logging-privacy-shenanigans/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "![](https://steipete.me/assets/img/2025/logging-privacy-shenanigans/header.png)\n\n> **TL;DR** – Apple logs hide the juicy debugging bits as ``. Drop plist files into `/Library/Preferences/Logging/Subsystems/` for a simpler solution, or install a configuration profile as an alternative.\n\nIf you’ve ever tried debugging a macOS app using the unified logging system, you’ve probably encountered the dreaded `` redaction. Your carefully crafted log messages turn into cryptic puzzles where the most important debugging information is hidden. Let me show you what’s really going on and how to work around it.\n\n## The Privacy Problem\n\nWhen you log something like this in Swift:\n\n```swift\nlogger.info(\"User \\(username) connected to session \\(sessionId)\")\n```\n\nYou expect to see:\n\n```plaintext\nUser john.doe connected to session ABC-123-DEF\n```\n\nBut instead you get:\n\n```plaintext\nUser connected to session \n```\n\nNot very helpful when you’re trying to debug an issue, right?\n\n## What Actually Gets Redacted\n\nHere’s where it gets interesting. Through testing, I discovered that Apple’s redaction logic is **not** as straightforward as the documentation suggests:\n\n| What you log | Documentation says | Reality |\n| ------------------------------------- | ------------------ | --------------------- |\n| Simple strings (`\"user@example.com\"`) | Redacted | **Usually redacted!** |\n| File paths (`/Users/username`) | Redacted | ✓ Redacted |\n| UUIDs (`ABC-123-DEF`) | Redacted | ✓ Redacted |\n| Integers, booleans, floats | Public | ✓ Public |\n\nThe discrepancy comes from how Apple’s logging system is implemented. The os\\_log function requires format strings to be compile-time constants (C string literals) for performance optimization. When you use string interpolation with dynamic values, the compiler and logging library work together to mark these as runtime data that needs privacy protection.\n\nStatic strings embedded directly in your code are treated as part of the format string and assumed to be non-sensitive, while any runtime values (variables, computed properties, function returns) are automatically redacted to prevent accidental leakage of personal information.\n\n## Old Solutions That No Longer Work\n\nBefore we get to what works, let’s quickly cover what **doesn’t** work anymore:\n\n### ❌ The `private_data:on` flag (Dead since Catalina)\n\n```bash\n# This returns \"Invalid Modes 'private_data:on'\" on macOS 10.15+\nsudo log config --mode \"private_data:on\" --subsystem your.app.subsystem\n```\n\nThis was completely removed in macOS Catalina (10.15) and later.\n\n### ❌ sudo doesn’t reveal private data\n\nYou might think running with sudo would show everything:\n\n```bash\nsudo log show --predicate 'subsystem == \"your.app\"' --info\n```\n\nNope! The privacy redaction happens at **write time**, not read time. Once logged as ``, the actual data is gone forever.\n\n## The Plist Solution (Preferred Method)\n\nThanks to [Rasmus Sten](https://micro.blog/pajp/70072065) for pointing out this elegant solution! You don’t need to use `.mobileconfig` files – you can simply drop plist files directly into `/Library/Preferences/Logging/Subsystems/`. This is actually what happens when you install a configuration profile anyway.\n\n### Step 1: Create a Plist File\n\nCreate a file named after your subsystem (e.g., `com.mycompany.myapp.plist`) with this content:\n\n```xml\n\n\n\n\n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n\n\n```\n\n### Step 2: Install the Plist\n\n```bash\n# Create the directory if it doesn't exist\nsudo mkdir -p /Library/Preferences/Logging/Subsystems/\n\n# Copy your plist file\nsudo cp com.mycompany.myapp.plist /Library/Preferences/Logging/Subsystems/\n\n# Set proper permissions\nsudo chmod 644 /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n```\n\n> **Important Gotcha**: When writing these plist files programmatically, you **must write them atomically**. Write to a temporary file first, then use `mv` to move it into place. This ensures the logging subsystem sees a complete, valid plist file.\n\n### Step 3: Generate Fresh Logs\n\nThe configuration only affects **new** log entries. Run your app to generate fresh logs.\n\n### Step 4: Remove After Debugging\n\n```bash\nsudo rm /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n```\n\n### Why This Method is Better\n\n- **Scriptable**: Can be added/removed programmatically from shell scripts\n- **No UI interaction**: No need to navigate System Settings\n- **Granular control**: Enable/disable specific subsystems instantly\n- **CI/CD friendly**: Perfect for automated testing environments\n\n### Documentation\n\nThis approach is documented in:\n\n- Apple’s [`os_log(5)` man page](https://www.manpagez.com/man/5/os_log/) (run `man 5 os_log` in Terminal)\n- [Apple Developer Forums](https://developer.apple.com/forums/thread/114166) confirming the `/Library/Preferences/Logging/Subsystems/` directory usage\n- [Der Flounder’s detailed analysis](https://derflounder.wordpress.com/2025/05/05/accessing-subsystem-logging-configurations-used-by-the-macos-unified-logging-on-macos-sequoia/) of macOS Sequoia’s logging configuration\n\n## The Configuration Profile Solution (Alternative Method)\n\nIf you prefer a GUI approach or need to deploy settings across multiple machines, you can still use configuration profiles:\n\n**View Configuration Profile Template**\n\n```xml\n\n\n\n\n PayloadContent\n \n \n PayloadDisplayName\n ManagedClient logging\n PayloadEnabled\n \n PayloadIdentifier\n com.yourapp.logging.EnablePrivateData\n PayloadType\n com.apple.system.logging\n PayloadUUID\n GENERATE-UUID-1\n PayloadVersion\n 1\n System\n \n Enable-Private-Data\n \n \n Subsystems\n \n your.app.subsystem\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n \n \n \n PayloadDescription\n This profile enables logging of private data for debugging.\n PayloadDisplayName\n Your App Private Data Logging\n PayloadIdentifier\n com.yourapp.PrivateDataLogging\n PayloadOrganization\n Your Organization\n PayloadRemovalDisallowed\n \n PayloadType\n Configuration\n PayloadUUID\n GENERATE-UUID-2\n PayloadVersion\n 1\n\n\n```\n\n**Customizing the Profile**\n\n**Critical Components to Replace:**\n\n1. **UUIDs**: Two unique identifiers are required:\n\n - Replace `GENERATE-UUID-1` and `GENERATE-UUID-2` with actual UUIDs\n - Generate with: `uuidgen` (run twice for two different UUIDs)\n2. **Organization**: Replace `Your Organization` with your actual organization or app name\n\n3. **Subsystems**: The most critical part! Replace `your.app.subsystem` with your actual logging subsystem(s):\n\n ```swift\n let logger = Logger(subsystem: \"com.mycompany.myapp\", category: \"Network\")\n ```\n\n In this example, `\"com.mycompany.myapp\"` is the subsystem you need to add.\n\n4. **Multiple Subsystems**: To enable private data for multiple subsystems, duplicate the subsystem structure:\n\n ```xml\n Subsystems\n \n com.mycompany.myapp\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n com.mycompany.myframework\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n \n ```\n\n**Key Implementation Details:**\n\n- **PayloadType values**: The top-level PayloadType must be `Configuration`, while the inner PayloadType (in PayloadContent) must be `com.apple.system.logging`\n- **PayloadRemovalDisallowed**: Keep this as `false` so you can easily remove the profile after debugging\n- **System section**: Enables private data for system-level logs\n- **DEFAULT-OPTIONS**: Required wrapper for subsystem options\n\nSave the customized file as `EnablePrivateLogging.mobileconfig`.\n\n### Installing Configuration Profiles\n\n1. Double-click the `.mobileconfig` file\n2. Navigate to:\n - **macOS 15 (Sequoia) and later**: System Settings → General → Device Management\n - **macOS 14 (Sonoma) and earlier**: System Settings → Privacy & Security → Profiles\n3. Click “Install…” and authenticate\n4. Wait 1-2 minutes for the system to apply changes\n\n### Removing Configuration Profiles\n\nGo back to the Profiles/Device Management section and click the minus (-) button.\n\n## The Code-Level Solution\n\nFor production apps, mark specific non-sensitive values as public:\n\n```swift\n// This will always be visible\nlogger.info(\"Session: \\(sessionId, privacy: .public)\")\n\n// This remains private by default\nlogger.info(\"Token: \\(apiToken)\")\n```\n\nThis is the safest approach as you explicitly control what’s exposed.\n\n## Automating with Claude Code\n\nInstead of manually editing configuration files, just give Claude Code this blog post URL and ask it to create a customized plist or profile for your app. [Living in the future](https://steipete.me/posts/2025/claude-code-is-my-computer/) means your documentation can be both human-readable and agent-executable.\n\n## Summary\n\nApple’s log privacy is well-intentioned but can be frustrating during development. The plist approach is your best bet for debugging:\n\n1. Privacy redaction happens at write time\n2. sudo can’t recover what was never stored\n3. Direct plist files are simpler than configuration profiles\n4. Always remove debugging configurations when done\n\nFor more details on this topic, check out:\n\n- [Apple’s os\\_log(5) man page](https://www.manpagez.com/man/5/os_log/) – The authoritative source\n- [Howard Oakley’s excellent post](https://eclecticlight.co/2023/03/08/removing-privacy-censorship-from-the-log/) – Deep dive into log privacy\n- [Der Flounder’s Sequoia analysis](https://derflounder.wordpress.com/2025/05/05/accessing-subsystem-logging-configurations-used-by-the-macos-unified-logging-on-macos-sequoia/) – Latest macOS changes\n\nHappy debugging, and may your logs be forever unredacted (but only when you need them to be)!\n", "authors": [], "captured_at": "2026-09-27T19:29:15.293681927+00:00", "category": "programming", "content_html": "

$\"\"$

\n
TL;DR – Apple logs hide the juicy debugging bits as <private>. Drop plist files into /Library/Preferences/Logging/Subsystems/ for a simpler solution, or install a configuration profile as an alternative.
\n

If you’ve ever tried debugging a macOS app using the unified logging system, you’ve probably encountered the dreaded <private> redaction. Your carefully crafted log messages turn into cryptic puzzles where the most important debugging information is hidden. Let me show you what’s really going on and how to work around it.

The Privacy Problem

When you log something like this in Swift:

logger.info("User \\(username) connected to session \\(sessionId)")\n

You expect to see:

User john.doe connected to session ABC-123-DEF\n

But instead you get:

User <private> connected to session <private>\n

Not very helpful when you’re trying to debug an issue, right?

What Actually Gets Redacted

Here’s where it gets interesting. Through testing, I discovered that Apple’s redaction logic is not as straightforward as the documentation suggests:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

What you log	Documentation says	Reality
Simple strings (`"user@example.com"`)	Redacted	Usually redacted!
File paths (`/Users/username`)	Redacted	✓ Redacted
UUIDs (`ABC-123-DEF`)	Redacted	✓ Redacted
Integers, booleans, floats	Public	✓ Public

The discrepancy comes from how Apple’s logging system is implemented. The os_log function requires format strings to be compile-time constants (C string literals) for performance optimization. When you use string interpolation with dynamic values, the compiler and logging library work together to mark these as runtime data that needs privacy protection.

Static strings embedded directly in your code are treated as part of the format string and assumed to be non-sensitive, while any runtime values (variables, computed properties, function returns) are automatically redacted to prevent accidental leakage of personal information.

Old Solutions That No Longer Work

Before we get to what works, let’s quickly cover what doesn’t work anymore:

❌ The `private_data:on` flag (Dead since Catalina)

# This returns "Invalid Modes 'private_data:on'" on macOS 10.15+\nsudo log config --mode "private_data:on" --subsystem your.app.subsystem\n

This was completely removed in macOS Catalina (10.15) and later.

❌ sudo doesn’t reveal private data

You might think running with sudo would show everything:

sudo log show --predicate 'subsystem == "your.app"' --info\n

Nope! The privacy redaction happens at write time, not read time. Once logged as <private>, the actual data is gone forever.

The Plist Solution (Preferred Method)

Thanks to Rasmus Sten for pointing out this elegant solution! You don’t need to use .mobileconfig files – you can simply drop plist files directly into /Library/Preferences/Logging/Subsystems/. This is actually what happens when you install a configuration profile anyway.

Step 1: Create a Plist File

Create a file named after your subsystem (e.g., com.mycompany.myapp.plist) with this content:

<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n    <key>DEFAULT-OPTIONS</key>\n    <dict>\n        <key>Enable-Private-Data</key>\n        <true/>\n    </dict>\n</dict>\n</plist>\n

Step 2: Install the Plist

# Create the directory if it doesn't exist\nsudo mkdir -p /Library/Preferences/Logging/Subsystems/\n\n# Copy your plist file\nsudo cp com.mycompany.myapp.plist /Library/Preferences/Logging/Subsystems/\n\n# Set proper permissions\nsudo chmod 644 /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n

\n
Important Gotcha: When writing these plist files programmatically, you must write them atomically. Write to a temporary file first, then use mv to move it into place. This ensures the logging subsystem sees a complete, valid plist file.
\n

Step 3: Generate Fresh Logs

The configuration only affects new log entries. Run your app to generate fresh logs.

Step 4: Remove After Debugging

sudo rm /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n

Why This Method is Better

Scriptable: Can be added/removed programmatically from shell scripts
No UI interaction: No need to navigate System Settings
Granular control: Enable/disable specific subsystems instantly
CI/CD friendly: Perfect for automated testing environments

Documentation

This approach is documented in:

Apple’s os_log(5) man page (run man 5 os_log in Terminal)
Apple Developer Forums confirming the /Library/Preferences/Logging/Subsystems/ directory usage
Der Flounder’s detailed analysis of macOS Sequoia’s logging configuration

The Configuration Profile Solution (Alternative Method)

If you prefer a GUI approach or need to deploy settings across multiple machines, you can still use configuration profiles:

View Configuration Profile Template

<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n    <key>PayloadContent</key>\n    <array>\n        <dict>\n            <key>PayloadDisplayName</key>\n            <string>ManagedClient logging</string>\n            <key>PayloadEnabled</key>\n            <true/>\n            <key>PayloadIdentifier</key>\n            <string>com.yourapp.logging.EnablePrivateData</string>\n            <key>PayloadType</key>\n            <string>com.apple.system.logging</string>\n            <key>PayloadUUID</key>\n            <string>GENERATE-UUID-1</string>\n            <key>PayloadVersion</key>\n            <integer>1</integer>\n            <key>System</key>\n            <dict>\n                <key>Enable-Private-Data</key>\n                <true/>\n            </dict>\n            <key>Subsystems</key>\n            <dict>\n                <key>your.app.subsystem</key>\n                <dict>\n                    <key>DEFAULT-OPTIONS</key>\n                    <dict>\n                        <key>Enable-Private-Data</key>\n                        <true/>\n                    </dict>\n                </dict>\n            </dict>\n        </dict>\n    </array>\n    <key>PayloadDescription</key>\n    <string>This profile enables logging of private data for debugging.</string>\n    <key>PayloadDisplayName</key>\n    <string>Your App Private Data Logging</string>\n    <key>PayloadIdentifier</key>\n    <string>com.yourapp.PrivateDataLogging</string>\n    <key>PayloadOrganization</key>\n    <string>Your Organization</string>\n    <key>PayloadRemovalDisallowed</key>\n    <false/>\n    <key>PayloadType</key>\n    <string>Configuration</string>\n    <key>PayloadUUID</key>\n    <string>GENERATE-UUID-2</string>\n    <key>PayloadVersion</key>\n    <integer>1</integer>\n</dict>\n</plist>\n

Customizing the Profile

Critical Components to Replace:

\n
UUIDs: Two unique identifiers are required:
\n
- Replace GENERATE-UUID-1 and GENERATE-UUID-2 with actual UUIDs
- Generate with: uuidgen (run twice for two different UUIDs)
\n
\n
Organization: Replace Your Organization with your actual organization or app name
\n
\n
Subsystems: The most critical part! Replace your.app.subsystem with your actual logging subsystem(s):
\n
```
let logger = Logger(subsystem: "com.mycompany.myapp", category: "Network")\n
```
\n
In this example, "com.mycompany.myapp" is the subsystem you need to add.
\n

Multiple Subsystems: To enable private data for multiple subsystems, duplicate the subsystem structure:

<key>Subsystems</key>\n<dict>\n    <key>com.mycompany.myapp</key>\n    <dict>\n        <key>DEFAULT-OPTIONS</key>\n        <dict>\n            <key>Enable-Private-Data</key>\n            <true/>\n        </dict>\n    </dict>\n    <key>com.mycompany.myframework</key>\n    <dict>\n        <key>DEFAULT-OPTIONS</key>\n        <dict>\n            <key>Enable-Private-Data</key>\n            <true/>\n        </dict>\n    </dict>\n</dict>\n

Key Implementation Details:

PayloadType values: The top-level PayloadType must be Configuration, while the inner PayloadType (in PayloadContent) must be com.apple.system.logging
PayloadRemovalDisallowed: Keep this as false so you can easily remove the profile after debugging
System section: Enables private data for system-level logs
DEFAULT-OPTIONS: Required wrapper for subsystem options

Save the customized file as EnablePrivateLogging.mobileconfig.

Installing Configuration Profiles

Double-click the .mobileconfig file
Navigate to:\n
- macOS 15 (Sequoia) and later: System Settings → General → Device Management
- macOS 14 (Sonoma) and earlier: System Settings → Privacy & Security → Profiles
\n
Click “Install…” and authenticate
Wait 1-2 minutes for the system to apply changes

Removing Configuration Profiles

Go back to the Profiles/Device Management section and click the minus (-) button.

The Code-Level Solution

For production apps, mark specific non-sensitive values as public:

// This will always be visible\nlogger.info("Session: \\(sessionId, privacy: .public)")\n\n// This remains private by default\nlogger.info("Token: \\(apiToken)")\n

This is the safest approach as you explicitly control what’s exposed.

Automating with Claude Code

Instead of manually editing configuration files, just give Claude Code this blog post URL and ask it to create a customized plist or profile for your app. Living in the future means your documentation can be both human-readable and agent-executable.

Summary

Apple’s log privacy is well-intentioned but can be frustrating during development. The plist approach is your best bet for debugging:

Privacy redaction happens at write time
sudo can’t recover what was never stored
Direct plist files are simpler than configuration profiles
Always remove debugging configurations when done

For more details on this topic, check out:

Apple’s os_log(5) man page – The authoritative source
Howard Oakley’s excellent post – Deep dive into log privacy
Der Flounder’s Sequoia analysis – Latest macOS changes

Happy debugging, and may your logs be forever unredacted (but only when you need them to be)!

\n", "content_markdown": "![](https://steipete.me/assets/img/2025/logging-privacy-shenanigans/header.png)\n\n> **TL;DR** – Apple logs hide the juicy debugging bits as ``. Drop plist files into `/Library/Preferences/Logging/Subsystems/` for a simpler solution, or install a configuration profile as an alternative.\n\nIf you’ve ever tried debugging a macOS app using the unified logging system, you’ve probably encountered the dreaded `` redaction. Your carefully crafted log messages turn into cryptic puzzles where the most important debugging information is hidden. Let me show you what’s really going on and how to work around it.\n\n## The Privacy Problem\n\nWhen you log something like this in Swift:\n\n```swift\nlogger.info(\"User \\(username) connected to session \\(sessionId)\")\n```\n\nYou expect to see:\n\n```plaintext\nUser john.doe connected to session ABC-123-DEF\n```\n\nBut instead you get:\n\n```plaintext\nUser connected to session \n```\n\nNot very helpful when you’re trying to debug an issue, right?\n\n## What Actually Gets Redacted\n\nHere’s where it gets interesting. Through testing, I discovered that Apple’s redaction logic is **not** as straightforward as the documentation suggests:\n\n| What you log | Documentation says | Reality |\n| ------------------------------------- | ------------------ | --------------------- |\n| Simple strings (`\"user@example.com\"`) | Redacted | **Usually redacted!** |\n| File paths (`/Users/username`) | Redacted | ✓ Redacted |\n| UUIDs (`ABC-123-DEF`) | Redacted | ✓ Redacted |\n| Integers, booleans, floats | Public | ✓ Public |\n\nThe discrepancy comes from how Apple’s logging system is implemented. The os\\_log function requires format strings to be compile-time constants (C string literals) for performance optimization. When you use string interpolation with dynamic values, the compiler and logging library work together to mark these as runtime data that needs privacy protection.\n\nStatic strings embedded directly in your code are treated as part of the format string and assumed to be non-sensitive, while any runtime values (variables, computed properties, function returns) are automatically redacted to prevent accidental leakage of personal information.\n\n## Old Solutions That No Longer Work\n\nBefore we get to what works, let’s quickly cover what **doesn’t** work anymore:\n\n### ❌ The `private_data:on` flag (Dead since Catalina)\n\n```bash\n# This returns \"Invalid Modes 'private_data:on'\" on macOS 10.15+\nsudo log config --mode \"private_data:on\" --subsystem your.app.subsystem\n```\n\nThis was completely removed in macOS Catalina (10.15) and later.\n\n### ❌ sudo doesn’t reveal private data\n\nYou might think running with sudo would show everything:\n\n```bash\nsudo log show --predicate 'subsystem == \"your.app\"' --info\n```\n\nNope! The privacy redaction happens at **write time**, not read time. Once logged as ``, the actual data is gone forever.\n\n## The Plist Solution (Preferred Method)\n\nThanks to [Rasmus Sten](https://micro.blog/pajp/70072065) for pointing out this elegant solution! You don’t need to use `.mobileconfig` files – you can simply drop plist files directly into `/Library/Preferences/Logging/Subsystems/`. This is actually what happens when you install a configuration profile anyway.\n\n### Step 1: Create a Plist File\n\nCreate a file named after your subsystem (e.g., `com.mycompany.myapp.plist`) with this content:\n\n```xml\n\n\n\n\n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n\n\n```\n\n### Step 2: Install the Plist\n\n```bash\n# Create the directory if it doesn't exist\nsudo mkdir -p /Library/Preferences/Logging/Subsystems/\n\n# Copy your plist file\nsudo cp com.mycompany.myapp.plist /Library/Preferences/Logging/Subsystems/\n\n# Set proper permissions\nsudo chmod 644 /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n```\n\n> **Important Gotcha**: When writing these plist files programmatically, you **must write them atomically**. Write to a temporary file first, then use `mv` to move it into place. This ensures the logging subsystem sees a complete, valid plist file.\n\n### Step 3: Generate Fresh Logs\n\nThe configuration only affects **new** log entries. Run your app to generate fresh logs.\n\n### Step 4: Remove After Debugging\n\n```bash\nsudo rm /Library/Preferences/Logging/Subsystems/com.mycompany.myapp.plist\n```\n\n### Why This Method is Better\n\n- **Scriptable**: Can be added/removed programmatically from shell scripts\n- **No UI interaction**: No need to navigate System Settings\n- **Granular control**: Enable/disable specific subsystems instantly\n- **CI/CD friendly**: Perfect for automated testing environments\n\n### Documentation\n\nThis approach is documented in:\n\n- Apple’s [`os_log(5)` man page](https://www.manpagez.com/man/5/os_log/) (run `man 5 os_log` in Terminal)\n- [Apple Developer Forums](https://developer.apple.com/forums/thread/114166) confirming the `/Library/Preferences/Logging/Subsystems/` directory usage\n- [Der Flounder’s detailed analysis](https://derflounder.wordpress.com/2025/05/05/accessing-subsystem-logging-configurations-used-by-the-macos-unified-logging-on-macos-sequoia/) of macOS Sequoia’s logging configuration\n\n## The Configuration Profile Solution (Alternative Method)\n\nIf you prefer a GUI approach or need to deploy settings across multiple machines, you can still use configuration profiles:\n\n**View Configuration Profile Template**\n\n```xml\n\n\n\n\n PayloadContent\n \n \n PayloadDisplayName\n ManagedClient logging\n PayloadEnabled\n \n PayloadIdentifier\n com.yourapp.logging.EnablePrivateData\n PayloadType\n com.apple.system.logging\n PayloadUUID\n GENERATE-UUID-1\n PayloadVersion\n 1\n System\n \n Enable-Private-Data\n \n \n Subsystems\n \n your.app.subsystem\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n \n \n \n PayloadDescription\n This profile enables logging of private data for debugging.\n PayloadDisplayName\n Your App Private Data Logging\n PayloadIdentifier\n com.yourapp.PrivateDataLogging\n PayloadOrganization\n Your Organization\n PayloadRemovalDisallowed\n \n PayloadType\n Configuration\n PayloadUUID\n GENERATE-UUID-2\n PayloadVersion\n 1\n\n\n```\n\n**Customizing the Profile**\n\n**Critical Components to Replace:**\n\n1. **UUIDs**: Two unique identifiers are required:\n\n - Replace `GENERATE-UUID-1` and `GENERATE-UUID-2` with actual UUIDs\n - Generate with: `uuidgen` (run twice for two different UUIDs)\n2. **Organization**: Replace `Your Organization` with your actual organization or app name\n\n3. **Subsystems**: The most critical part! Replace `your.app.subsystem` with your actual logging subsystem(s):\n\n ```swift\n let logger = Logger(subsystem: \"com.mycompany.myapp\", category: \"Network\")\n ```\n\n In this example, `\"com.mycompany.myapp\"` is the subsystem you need to add.\n\n4. **Multiple Subsystems**: To enable private data for multiple subsystems, duplicate the subsystem structure:\n\n ```xml\n Subsystems\n \n com.mycompany.myapp\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n com.mycompany.myframework\n \n DEFAULT-OPTIONS\n \n Enable-Private-Data\n \n \n \n \n ```\n\n**Key Implementation Details:**\n\n- **PayloadType values**: The top-level PayloadType must be `Configuration`, while the inner PayloadType (in PayloadContent) must be `com.apple.system.logging`\n- **PayloadRemovalDisallowed**: Keep this as `false` so you can easily remove the profile after debugging\n- **System section**: Enables private data for system-level logs\n- **DEFAULT-OPTIONS**: Required wrapper for subsystem options\n\nSave the customized file as `EnablePrivateLogging.mobileconfig`.\n\n### Installing Configuration Profiles\n\n1. Double-click the `.mobileconfig` file\n2. Navigate to:\n - **macOS 15 (Sequoia) and later**: System Settings → General → Device Management\n - **macOS 14 (Sonoma) and earlier**: System Settings → Privacy & Security → Profiles\n3. Click “Install…” and authenticate\n4. Wait 1-2 minutes for the system to apply changes\n\n### Removing Configuration Profiles\n\nGo back to the Profiles/Device Management section and click the minus (-) button.\n\n## The Code-Level Solution\n\nFor production apps, mark specific non-sensitive values as public:\n\n```swift\n// This will always be visible\nlogger.info(\"Session: \\(sessionId, privacy: .public)\")\n\n// This remains private by default\nlogger.info(\"Token: \\(apiToken)\")\n```\n\nThis is the safest approach as you explicitly control what’s exposed.\n\n## Automating with Claude Code\n\nInstead of manually editing configuration files, just give Claude Code this blog post URL and ask it to create a customized plist or profile for your app. [Living in the future](https://steipete.me/posts/2025/claude-code-is-my-computer/) means your documentation can be both human-readable and agent-executable.\n\n## Summary\n\nApple’s log privacy is well-intentioned but can be frustrating during development. The plist approach is your best bet for debugging:\n\n1. Privacy redaction happens at write time\n2. sudo can’t recover what was never stored\n3. Direct plist files are simpler than configuration profiles\n4. Always remove debugging configurations when done\n\nFor more details on this topic, check out:\n\n- [Apple’s os\\_log(5) man page](https://www.manpagez.com/man/5/os_log/) – The authoritative source\n- [Howard Oakley’s excellent post](https://eclecticlight.co/2023/03/08/removing-privacy-censorship-from-the-log/) – Deep dive into log privacy\n- [Der Flounder’s Sequoia analysis](https://derflounder.wordpress.com/2025/05/05/accessing-subsystem-logging-configurations-used-by-the-macos-unified-logging-on-macos-sequoia/) – Latest macOS changes\n\nHappy debugging, and may your logs be forever unredacted (but only when you need them to be)!\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2025-07-29T07:00:00+00:00", "date_modified": "2025-07-29T07:00:00+00:00", "date_published": "2025-07-29T07:00:00+00:00", "description": "Apple's logs redact your debugging data as . Here's what actually gets hidden, why old tricks don't work anymore, and the only reliable way to see your logs again.", "external_url": "https://steipete.me/posts/2025/logging-privacy-shenanigans/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/steipete-me/2025/07/2025-07-29-logging-privacy-shenanigans.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/steipete-me/2025/07/2025-07-29-logging-privacy-shenanigans.md" }, "id": "urn:aggr:item:1d1686538071dca4713374d0308a32dc0f836e47", "isBasedOn": { "@id": "https://steipete.me/posts/2025/logging-privacy-shenanigans/" }, "mainEntity": { "@id": "https://steipete.me/posts/2025/logging-privacy-shenanigans/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-07-29-logging-privacy-shenanigans/#webpage" }, "dateModified": "2025-07-29T07:00:00+00:00", "datePublished": "2025-07-29T07:00:00+00:00", "headline": "Logging Privacy Shenanigans", "timeRequired": "PT6M", "url": "https://steipete.me/posts/2025/logging-privacy-shenanigans/", "wordCount": 1284 }, "name": "Archived snapshot: Logging Privacy Shenanigans", "preview": null, "reading_minutes": 6, "replicated_at": null, "source": "steipete-me", "source_name": "Peter Steinberger", "summary": "Apple's logs redact your debugging data as . Here's what actually gets hidden, why old tricks don't work anymore, and the only reliable way to see your logs again.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Logging Privacy Shenanigans", "url": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-07-29-logging-privacy-shenanigans/", "word_count": 1284 }