Signed Out. Still Watching.

Not technical? Skip to the part where we explain it like Apple never would.

The Setup

This is not a theory. This is a documented, timestamped, terminal-verified investigation conducted on a MacBook Pro (Mac16,6, macOS 15.7.4) on March 26, 2026.

The machine belonged to a developer and performance marketer who had:

• Explicitly disabled iCloud services in System Settings
• Turned off Siri, Find My, Photos, Messages, Mail, Notes, Keychain Sync, and iCloud Drive
• Enabled Advanced Data Protection
• Signed out of iCloud entirely

What happened next is the story.

It Started With a Ghost IP

A single outbound connection showed up in a firewall log:

17.248.193.57:443  HTTPS  Apple Inc  Los Angeles  10 hits
BINARY: /usr/libexec/networkserviceproxy

One destination. Ten hits. No PTR record.

A reverse DNS lookup returned NXDOMAIN. No record exists. But the SOA record exposed ns-ext-prod.jackfruit.apple.com, Apple’s own internal nameserver infrastructure. This endpoint was deliberately made un-fingerprintable. Apple chose not to give it a reverse DNS record. That is not an accident.

We covered this endpoint in detail in The Silent Pipe. What follows is what happened when we pulled the thread further.

What networkserviceproxy Actually Does

Apple calls it a local proxy layer for sandboxed apps and network extensions.

fs_usage told a different story. During a 3-second capture window, the following processes fired simultaneously and were actively writing data:

Process	Data Being Written
identityservicesd	Identity tokens and push credentials
cloudd	CloudKit metadata and sync state
remindd	Three separate Reminders SQLite stores
contactsd	Contacts database, three concurrent instances
locationd	consolidated.db, encrypted location caches, gyroscope calibration
routined	Cloud-V2.sqlite, behavioral routine model, pattern-of-life data
contextstored	knowledgeC.db, CoreDuet behavioral knowledge graph
searchpartyd	iCloud search index sharing keys
nsurlsessiond	Two active HTTP task queue instances

networkserviceproxy was receiving small fixed-size control messages (48 to 56 bytes) at roughly 180ms intervals on a single socket. A structured heartbeat channel. It held a map_fd call passing socket handles between processes and an NPOLICY file descriptor registering itself with the kernel’s network policy engine.

Every data-collecting daemon routes its outbound connections through networkserviceproxy. None of them show a direct outbound connection in your firewall. Only the proxy does. It is a single process that launders the network identity of a dozen data-collecting daemons.

Then We Found callservicesd

/System/Library/PrivateFrameworks/TelephonyUtilities.framework/callservicesd
Real Memory:    2.34 GB
Private Memory: 2.05 GB
Ports:          418
PID:            765

A telephony daemon holding 2.34 GB of private memory and 418 Mach IPC ports.

The lsof output told the real story. callservicesd had loaded:

• Every contact source: CardDAV, LocalSource, LDAP, Exchange, DirectoryServices
• AddressBookCore.framework, complete contacts infrastructure
• IMCore.framework, iMessage core framework
• Contacts.framework, full contacts API
• CallHistory.storedata-wal, a 3.01 MB write-ahead log actively growing
• GeoServices cache, location and geo lookups
• analyticsd/events.allowlist, analytics event filtering
• LaunchServices store, application registry

Its stderr (FD 2) had written 1.38 MB of output to /dev/null. Silently discarded. It held an NPOLICY network policy file descriptor registering itself with the kernel network layer.

This is not a call relay daemon. This is a communications intelligence aggregator holding your entire contact graph, message infrastructure, call history, and location data in private memory, communicating through 418 Mach IPC channels invisible to any firewall.

The Opt-Out File

We captured Apple’s own service configuration:

defaults read MobileMeAccounts > icloud_service_states.txt

The file confirmed explicit opt-outs with Enabled = 0:

• iCloud Drive
• Photos
• Messages
• Mail
• Notes
• Siri
• Freeform
• Keychain Sync
• Find My Mac
• News, Stocks, Home

Then there were the services with no Enabled flag at all. No opt-out mechanism exposed to the user:

• Contacts
• Calendar
• Reminders
• Bookmarks
• PhoneFaceTime
• Settings Sync, syncing your system settings to Apple with no visible disable option

Nowhere in that file: any entry for routined, contextstored, or behavioral intelligence sync. Apple never gave you the option to opt out of those. They do not appear in the UI because they were never exposed as user-controllable services.

The Signout Test

We signed out of iCloud entirely. Advanced Data Protection enabled. Kept nothing local. Full account dissociation.

Process list before signout:

26166   cloudd
973     networkserviceproxy
25436   identityservicesd
765     callservicesd
25551   routined
25600   contactsd

Process list after signout:

46374   cloudd               ← new PID, restarted immediately
973     networkserviceproxy  ← SAME PID, never stopped
46489   identityservicesd    ← new PID, restarted immediately
765     callservicesd        ← SAME PID, never stopped
46695   routined             ← new PID, restarted immediately
46732   contactsd            ← new PID, restarted immediately

networkserviceproxy and callservicesd never stopped. The others cycled and immediately restarted.

Signing out of iCloud did not stop a single daemon.

The Fresh Boot Test

Someone could argue the daemons were residual from a previous session. So we restarted the machine. Full power cycle. No iCloud account signed in.

22 minutes after a cold boot, with no user action beyond login:

  518 _locationd   Thu Mar 26 12:29:23 2026   com.apple.geod
  723 roipipe      Thu Mar 26 12:29:24 2026   callservicesd
  907 roipipe      Thu Mar 26 12:29:25 2026   networkserviceproxy
95039 roipipe      Thu Mar 26 12:53:28 2026   cloudd
95144 roipipe      Thu Mar 26 12:53:28 2026   identityservicesd
95294 _locationd   Thu Mar 26 12:53:30 2026   locationd
95308 roipipe      Thu Mar 26 12:53:30 2026   routined
95334 root         Thu Mar 26 12:53:30 2026   contextstored
95347 roipipe      Thu Mar 26 12:53:30 2026   contactsd

callservicesd started at 12:29:24. networkserviceproxy at 12:29:25. Both launched during the boot sequence, before the user-level daemons even initialized. contextstored is running as root. No iCloud account attached. No user consent given. Every daemon active.

The infrastructure does not depend on your iCloud account. It does not depend on your consent. It starts at boot and it runs until you power off the machine.

The Disable Attempt

We tried every path Apple provides to disable these services.

User domain, no sudo:

$ launchctl disable gui/501/com.apple.networkserviceproxy
(no error)

Service kept running. Same PID. No effect.

System domain, with sudo:

$ sudo launchctl disable system/com.apple.networkserviceproxy
(no error)

$ sudo launchctl disable system/com.apple.contextstored
(no error)

Both accepted silently. Both services kept running. We checked the system domain:

$ sudo launchctl list | grep networkserviceproxy
(nothing returned)

networkserviceproxy was never registered in the system domain. The sudo command targeted a domain where the service does not exist. Apple accepted it without error. No warning that the target was invalid. Silent acceptance of a useless command.

Then we rebooted.

$ ps -eo pid,user,comm | grep -E 'networkserviceproxy|contextstored'
  910 roipipe   /usr/libexec/networkserviceproxy
 1980 root      contextstored

Both back. New PIDs. We checked whether the disable flag persisted:

$ launchctl print-disabled gui/501 | grep networkserviceproxy
(nothing returned)

The disable flag was wiped on reboot. Apple discarded it.

The full sequence: we issued disable commands in both the user domain and the system domain. Every command was accepted without error. The services continued running. After reboot, both services restarted with new PIDs and the disable flags were gone from the registry.

This is worse than blocking the command. SIP gives you an honest error. This gives you silence. The command exists. It runs. It returns success. It does nothing. And on reboot, even the record that you tried is erased.

The Command That Tells the Truth

There is one more command. launchctl bootout attempts to actually stop and unload a service.

$ launchctl bootout gui/501/com.apple.routined
Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged

$ launchctl bootout gui/501/com.apple.networkserviceproxy
Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged

Both SIP-protected. The behavioral data collector and the proxy that transmits it are guarded by the same security layer designed to protect your system from malware.

Apple gave you two commands. launchctl disable pretends to work. It accepts your input, returns no error, and erases the record on reboot. launchctl bootout tells you the truth: these services are untouchable without entering Recovery Mode and disabling your system’s core security model.

To stop the collection, you would have to disable the protection Apple built to keep your Mac secure from attackers. That is the trade-off. Apple made the behavioral data infrastructure and your system’s security depend on the same mechanism. You cannot remove one without removing the other.

What Is Still Running

With the daemons back and no iCloud account signed in, we checked what each one was actually doing.

networkserviceproxy:

$ lsof -i -n -P | grep networkserviceproxy
(nothing returned)

No active network connections. The proxy is running but idle. With no iCloud account, it has nowhere to send data. We are not going to claim otherwise.

contextstored:

$ lsof -c contextstored | grep -E '\.db|\.sqlite'
(nothing returned)

No database files open. Running but idle.

routined:

$ lsof -c routined | grep -E '\.db|\.sqlite'
Cache.sqlite          847,872 bytes   WAL: 90 KB
Cloud-V2.sqlite         4,096 bytes   WAL: 947 KB
Local.sqlite            4,096 bytes   WAL: 873 KB
SafetyCache.sqlite      4,096 bytes   WAL: 939 KB

All four databases open. All four actively being written to. The write-ahead logs tell the story:

• Cloud-V2.sqlite has a 947 KB write-ahead log. This is the cloud sync database for your behavioral routine model. It is accumulating data with no iCloud account signed in.
• Local.sqlite has an 873 KB WAL. Your local pattern-of-life model, actively growing.
• SafetyCache.sqlite has a 939 KB WAL. Safety and location caching, actively written.
• Cache.sqlite has a 90 KB WAL. General behavioral cache.

routined does not need an iCloud account to collect your behavioral data. It does not need your permission. It does not need any service enabled. It records where you go, when, and how often, and it writes that data to a cloud sync database regardless of whether there is an account to sync it to.

The collection never stops. The pipe waits. The moment you sign back into iCloud, that data is queued and ready to transmit through networkserviceproxy to the no-PTR endpoint on Apple’s infrastructure.

What This Means

The sequence of events is documented and timestamped:

1. User explicitly disabled individual iCloud services. Enabled = 0 confirmed in Apple’s own config file.
2. User signed out of iCloud entirely.
3. Infrastructure continued operating on user-owned hardware.
4. Daemons auto-restarted within seconds of signout and persisted through a full reboot.
5. Disable commands accepted silently across both launchd domains with no effect.
6. Disable flags erased on reboot.
7. Bootout commands blocked by System Integrity Protection. Both routined and networkserviceproxy are SIP-protected.
8. Behavioral data collection continued with no account signed in. Cloud sync database actively written to, queuing data for future transmission.

The hardware is privately owned. The service was explicitly declined. Every disable mechanism Apple provides was used. The one that pretended to work was erased on reboot. The one that would actually work is blocked by SIP. Behavioral data collection continued regardless.

This is not a terms of service dispute. This is unauthorized code executing on privately owned hardware after explicit service refusal. The disable mechanism is theater. The real protection is SIP. The evidence infrastructure is deliberately obfuscated through no-PTR endpoints, IPC routing that bypasses firewall visibility, and stderr piped to /dev/null.

The Only Remediation

Short of entering Recovery Mode, disabling SIP, and manually unloading system services, the only practical mitigation is a firewall that blocks at the process level.

LuLu by Patrick Wardle. Block networkserviceproxy, callservicesd, cloudd, routined, and contextstored permanently. These processes can run. They just cannot phone home.

The longer remediation: leave the platform entirely.

Innocent Infrastructure Does Not Need to Hide

A developer signed out of iCloud on his own hardware. Every daemon that serves Apple’s data collection infrastructure restarted within seconds. Two of them never stopped at all. The disable commands Apple provides were accepted silently and erased on reboot.

This machine was used to run businesses. It processed client data, campaign strategy, proprietary attribution architecture, and legal research. All of it was accessible to an infrastructure layer the user could not stop, could not fully see, and could not remove without compromising the operating system’s own security model.

The thing that should bother people most is not even the data collection. It is that Apple built an entire obfuscation architecture around it. No PTR records. Stderr to /dev/null. IPC routing that bypasses firewall visibility. Services with no opt-out exposed in the UI.

Innocent infrastructure does not need to hide.

You signed out. They stayed in.