Back to blog
·10 min read·productdevbook

How to Tell If a Mac App Is Spying on You via the Network

A grounded guide to spotting Mac apps that phone home more than they should — and the signals that separate noise from actual surveillance.

  • Privacy
  • Security
  • macOS
  • Network monitoring

You install a screen recording app, give it the permissions it asks for, and a week later you notice it's transferring a few hundred kilobytes every night at 3 AM. Is it spying on you? Probably not. Is it doing something you didn't sign up for? Possibly. The question of whether a mac app is spying on the network has a real answer, and it isn't "yes" or "no" — it's "what's actually leaving the machine, where is it going, and does that match what the app told you it would do."

This is a technical post, not a paranoid one. Most apps are fine. A few apps are noisy. A very small number do things they shouldn't. The goal is to tell them apart with evidence rather than vibes.

Telemetry vs. surveillance — they're not the same

Two very different things often get lumped together:

  • Telemetry. The app reports anonymous-ish usage data: feature counts, crash logs, install info, sometimes coarse demographics. Usually disclosed in the privacy policy. Often opt-out-able. Generally not malicious, even when it's annoying.
  • Surveillance. The app exfiltrates content — what you typed, what files you opened, what's on your screen, your contacts, your camera input — to a server, without disclosure or with deliberately vague disclosure. This is rare in mainstream Mac App Store apps but does happen, especially in free apps with unclear monetization.

A bandwidth monitor can show you the volume and timing of network activity. It can't tell you the content of an encrypted connection. The mismatch between disclosed behavior and observed behavior is usually enough to flag a mac app spying on the network — or, more often, to confirm that what looked suspicious is actually mundane.

Signs of a mac app spying on the network

Here are the patterns that warrant a closer look.

Off-hours uploads

An app that uploads data at 3 AM when you're asleep, when no user action could have triggered it, deserves a question. Some legitimate reasons exist (analytics batching, error log uploads, content sync), but a screen recorder uploading 80 MB at 3 AM with the recording function not in use is at least worth asking about.

Persistent reconnects

An app that holds a long-lived connection or reconnects every few seconds is doing live communication. Chat apps and collaboration tools (Slack, Discord, Figma) need this. A PDF reader doesn't.

Sustained slow uploads

A trickle of 5-20 KB/s constantly is a fingerprint of streaming telemetry. Whether that's keystrokes, screen frames, or just analytics events depends on the app. Worth knowing what's behind it.

Connections to many distinct hosts

Most legitimate apps talk to a small number of backends — their own servers, maybe one analytics provider, maybe one CDN. An app talking to 30 distinct hosts is either using a lot of third-party SDKs (typical for ad-supported apps) or doing something more interesting.

Encrypted destinations to unknown IP ranges

Almost all modern apps use HTTPS, so encryption itself isn't suspicious. What is interesting is which hosts. An app that talks to its own domain plus a Cloudflare CDN and an Apple analytics endpoint is normal. An app that talks to a bare IP address in a country unrelated to the developer is at least curious.

What you can actually see, and what you can't

A per-app bandwidth monitor on macOS gives you:

  • Process name (and helper processes, when properly attributed).
  • Bytes sent and received over time.
  • Live rate, with history.
  • Often the connection counts.

It does not give you:

  • The content of encrypted connections.
  • The destination domain or IP without additional tools.
  • Whether the app is reading your microphone, screen, or keystrokes.

For the destination side, lsof -i -n -P shows currently open connections per process. For domain resolution, you can pair that with a DNS log or a tool like Little Snitch. For content, you'd need a man-in-the-middle proxy with installed root certificates, which is a more invasive setup than most people want.

The realistic stack for most users is:

  1. A menu bar bandwidth monitor for when and how much.
  2. macOS's privacy permissions panels for what the app can access.
  3. Occasional lsof for who it's talking to.

That's enough to catch nearly everything that matters.

A practical investigation routine

If an app's behavior makes you suspicious:

1. Get a baseline

Watch the app for a week without intervention. What's its normal upload pattern? When does it transfer data? How much per day? Without a baseline, every spike looks suspicious. With one, only real anomalies stand out.

2. Check the privacy permissions

System Settings → Privacy & Security. Look at:

  • Full Disk Access (very powerful — most apps don't need it).
  • Screen Recording.
  • Accessibility.
  • Camera, Microphone.
  • Files and Folders.

Cross-reference: does this app's stated purpose require these permissions? A note-taking app does not need Screen Recording. A keyboard utility does not need Full Disk Access.

3. Check the network destinations

Run lsof -i -n -P | grep AppName while the app is doing whatever made you curious. Look at the remote hosts. Do a reverse DNS or WHOIS lookup on any that look unusual.

4. Read the privacy policy

Yes, it's tedious. But the relevant question is "does the policy disclose what you're observing." If the app uploads daily telemetry and the policy says "we collect anonymous usage data," that's consistent. If the app uploads daily telemetry and the policy says nothing about data collection, that's a mismatch.

Watching this on your own machine

ova is a menu bar bandwidth monitor that shows live per-app rates and historical timelines. For the kind of investigation in this post, what matters is:

  • Per-app attribution that handles helper processes correctly (so a Chrome Helper isn't its own row).
  • History you can scrub, so "what did this app do at 3 AM last Tuesday" has an answer.
  • Local-only data, so you're not sharing the very information you're trying to protect by handing it to a cloud monitoring service.
Local-only by design
ova stores per-app sample data on disk locally. No telemetry, no cloud sync, no account. The point of monitoring privacy concerns is undermined if the monitoring tool itself uploads what it sees.

What's normal — a few examples

Some apps that look suspicious if you don't know them:

  • mdworker_shared. macOS Spotlight indexer. Background work, not network-heavy.
  • trustd. Validates SSL certificates. Talks to Apple servers. Normal.
  • apsd. Apple Push Service. Holds a long-lived connection to Apple. Normal.
  • nsurlsessiond. Background network task scheduler. Many apps queue uploads/downloads through this; it shows up as the worker, not the original app.
  • syncdefaultsd. Syncs preferences via iCloud. Low volume, frequent.
  • Dropbox / Google Drive / OneDrive. Sync clients. High volume, not suspicious.
  • Slack Helper (Renderer). Slack's helper processes. Many of them; together they account for Slack's traffic.

If you don't recognize a process, search the exact name with quotes — "process_name" macOS — and you'll usually find a clear answer in five minutes.

See what your apps actually do online

ova is a glance-able menu bar bandwidth monitor — local, signed, ~3 MB. No accounts, no cloud.

Download for macOS

When something genuinely looks wrong

You've watched an app for a week, the pattern doesn't match its stated purpose, the privacy policy doesn't mention what you're seeing, and lsof shows connections to hosts that don't make sense. What now?

In order:

  1. Quit the app and remove it. Drag to Trash isn't always enough — many apps install LaunchAgents or LaunchDaemons that persist. Tools like AppCleaner help; manual inspection of ~/Library/LaunchAgents and /Library/LaunchAgents is more thorough.
  2. Revoke any privacy permissions it had.
  3. Decide whether you want to report it. Apple takes Mac App Store reports seriously. The Apple Feedback Assistant and the App Store report flow are the right channels.
  4. Don't try to "block" it at the firewall level on a machine you'll keep using the app on. That's the firewall use case (Little Snitch territory). A monitor is for visibility; if you want to block, use a blocking tool. ova is a monitor, not a firewall.

Wrapping up

Most apps are fine. A few are noisy. A small number cross lines they shouldn't. Spotting a mac app spying on the network isn't paranoia — it's hygiene. Watch your machine for a week, develop a baseline, and the abnormal stands out without effort.

Install ova, let it run quietly, and the next time an app feels wrong you'll have data instead of a hunch.