Limit Ad Tracking

What the Apple ad tracking blocker does

This Automox Worklet™ disables Apple personalized advertising on macOS endpoints by writing the privacy baseline key to com.apple.AdLib.plist for the currently logged-in console user. The Worklet reads the Darwin kernel major version, branches on whether the endpoint is running Big Sur (Darwin 20) or Catalina (Darwin 19), and applies the matching plist write so the same policy enforces the baseline across both supported OS generations.

On Big Sur, the Worklet sets allowApplePersonalizedAdvertising to false. On Catalina, it sets forceLimitAdTracking to true. Both keys are written under /Users/<user>/Library/Preferences/com.apple.AdLib.plist using the defaults -currentHost write command, executed as the logged-in user with sudo -u so the change applies to that user's per-host preference domain.

The Worklet is idempotent. Endpoints that already meet the baseline pass evaluation with exit code 0 and remediation is skipped. Endpoints that drift back to the default value flip to non-compliant on the next evaluation, at which point the Worklet writes the baseline value again.

Why block Apple ad tracking on managed Macs

Apple's Identifier for Advertisers (IDFA) lets applications correlate user activity across apps, websites, and SDKs that share an advertising network. When personalized advertising is left at its default state, third-party SDKs embedded in everyday business applications can read the identifier and build a behavioral profile of the user behind the laptop. That telemetry intersects with GDPR Article 5 data minimization, CCPA Do Not Sell signals, and the NIST SP 800-53 Rev 5 PT-2 and PT-3 authority and processing-purpose controls.

The IDFA preference is one of the easier privacy toggles for an end user to reverse: a single switch in System Settings, a restored Time Machine backup, or a Migration Assistant import from a personal Mac can re-enable personalized advertising in seconds. The com.apple.AdLib.plist lives in the user's preference domain rather than a managed config profile, which is why MDM-only enforcement frequently fails to hold the value. The Worklet writes the expected key on every evaluation pass and treats the user-domain plist as the source of truth, so the baseline is re-established whenever a new profile imports the default or someone flips the toggle back in System Settings.

How Apple ad tracking enforcement works

1. Evaluation phase: The Worklet identifies the logged-in console user with scutil show State:/Users/ConsoleUser and captures the Darwin major version with uname -r. On Darwin 20 (Big Sur), it runs sudo -u <user> defaults -currentHost read /Users/<user>/Library/Preferences/com.apple.AdLib.plist allowApplePersonalizedAdvertising; if the value is 1, the endpoint is flagged non-compliant and exits 1. On Darwin 19 (Catalina), it reads forceLimitAdTracking from the same plist; if the value is 0, the endpoint is flagged non-compliant and exits 1. Any other Darwin version exits 0 with a message that the script is not compatible with the running macOS release.

2. Remediation phase: Remediation re-checks the same key. On Big Sur, the Worklet runs sudo -u <user> defaults -currentHost write /Users/<user>/Library/Preferences/com.apple.Adlib.plist allowApplePersonalizedAdvertising -bool false. On Catalina, it runs sudo -u <user> defaults -currentHost write /Users/<user>/Library/Preferences/com.apple.AdLib.plist forceLimitAdTracking -bool True. The defaults write happens in the logged-in user's current host preference domain, which is why the Worklet uses sudo -u to drop into that user's context rather than writing as root.

Apple ad tracking baseline requirements

• macOS Catalina (10.15, Darwin 19) or macOS Big Sur (11.x, Darwin 20). The case statement matches these Darwin versions exactly; other releases exit 0 with a not-compatible message

• An interactive console user logged in when the Worklet runs. The script resolves the user via scutil show State:/Users/ConsoleUser and writes the plist in that user's home directory

• Automox agent running with root privileges (the default), which is required to sudo -u into the logged-in user's context and write the per-host preference domain

• Not compatible with macOS 10.14 Mojave (Darwin 18) or older. Older endpoints exit 0 with a message so they do not show as failed in Automox reporting

• Endpoints in scope should be assigned to a recurring Automox policy so the baseline is re-enforced after profile imports, OS upgrades, or System Settings resets

Expected Apple ad tracking state after enforcement

After remediation, macOS reports the advertising identifier as a zero value to apps and websites that query it. Personalized ads in Apple News, the App Store, and Stocks fall back to generic placements. Third-party SDKs embedded in business apps read the same zero value, so the cross-app profile they would otherwise stitch together no longer ties back to a single user. End users see no functional difference outside the System Settings privacy pane, where the corresponding Personalized Ads toggle is now switched off.

Validate on Big Sur by running defaults -currentHost read /Users/<user>/Library/Preferences/com.apple.AdLib.plist allowApplePersonalizedAdvertising; the expected value is 0. On Catalina, run defaults -currentHost read /Users/<user>/Library/Preferences/com.apple.AdLib.plist forceLimitAdTracking; the expected value is 1. For a System Settings spot check on Big Sur, open System Settings > Privacy and Security > Apple Advertising and confirm Personalized Ads is off. Capture the defaults read output alongside the Automox policy run ID for audit evidence.

The setting persists across reboots and user logouts. A profile reset, System Settings change, or Migration Assistant import will return the endpoint to a non-compliant state, at which point the next evaluation pass re-enforces the baseline. Note that on Big Sur, the GUI toggle in System Settings may not reflect the new value until the endpoint reboots, though the underlying preference is applied immediately.