How to Check Whether a Desktop App Has Telemetry

"Telemetry-free" is a marketing claim. It tells you what the developer says; it does not tell you what the binary does. The only way to know whether a desktop utility actually phones home is to watch its network traffic while you use it. This guide walks through the method, not the vibes: which tools to use, what to look for, and what counts as evidence. For related reading, see bus factor: what if a solo app goes quiet, why macOS has better visual clipboards than Windows, what local-first means for clipboard apps, and managers that stay local on purpose.

Why "the source is on GitHub" is not enough

Source availability is necessary but not sufficient. Two failure modes make it weaker than it looks:

1. The binary you installed is not the binary built from source. A maintainer can ship a release with extra code that is not in the public repo. For projects with reproducible builds, you can verify. For projects without, you cannot.
2. The source is honest but the dependencies are not. A package.json with 400 transitive dependencies can include a telemetry SDK the maintainer never read. This is the npm supply-chain problem in miniature.

The first failure mode is rare for solo projects with active communities. The second is common. Network monitoring catches both, because both end with packets leaving your machine.

The three-tool method

The reliable way to check whether a desktop utility is telemetry-free is to run it on a clean Windows install, watch its traffic, and confirm what you see. Three tools cover the range:

pktmon is the cheapest starting point because it is already on Windows 10 and 11. Wireshark is the gold standard for decoding. TCPView is the easiest way to see which process owns a connection.

Step 1: baseline before installing

Before installing the app, capture a baseline. Boot the machine, log in, wait ten minutes without touching anything, and capture the traffic. This tells you what Windows itself sends: time sync, certificate revocation checks, Store updates, Defender signature updates, and so on. Without this baseline, you will mistake Windows traffic for app traffic.

pktmon start --capture --comp nics
# wait ten minutes, do nothing
pktmon stop
pktmon format C:\pktmon.etl --json > baseline.json

The exact flags vary by Windows version; check pktmon /? for the current syntax.

Step 2: install the app and capture again

Install the app, do not configure it, and capture again for ten minutes. Compare the second capture to the baseline. New connections are the app's responsibility.

Look for:

• Connection targets. Is the app talking to the developer's own domain, to a third-party telemetry provider (Amplitude, Mixpanel, Segment, PostHog, Sentry), or to something you do not recognise?
• Connection timing. A connection on first run, before you have done anything, is a stronger signal than a connection triggered by an action.
• Connection volume. One small request per session is different from a steady stream of beacons.

For a clipboard manager, the expectation is zero connections, because there is no legitimate reason for a local clipboard tool to talk to a server. The exceptions are explicit: a version-check endpoint, a crash-report uploader you opted into, or a sync feature you enabled.

Step 3: use it and capture again

Some telemetry is event-driven. A first-run check might be silent; a "copy ten items" check might light up. Run the app through a realistic session:

• Copy ten text items.
• Copy a file path.
• Copy an image.
• Pin an item.
• Restart the app.

Capture throughout. If new connections appear during these actions, the app is sending something tied to what you copied. For a clipboard manager, that is a leak unless the developer has documented it and you have opted in.

Step 4: decode and read

Open the capture in Wireshark. Filter by the app's process name (Wireshark can correlate processes if you capture with the right options) or by destination IP. Read the contents of each request. Things worth flagging:

• Form-encoded or JSON bodies that look like event names, timestamps, user IDs, or hashed machine fingerprints.
• Query strings with uid=, session=, event= parameters.
• TLS connections to analytics providers that the readme does not mention.
• TLS connections to the developer's own domain that fire on every copy.

The third is the most common finding in apps that claim to be telemetry-free. A connection to sentry.io is usually crash reporting; a connection to amplitude.com is usually product analytics; a connection to *.google-analytics.com is web analytics dressed up as desktop telemetry.

Step 5: confirm with TCPView

Wireshark tells you what was sent. TCPView tells you which process sent it. Run TCPView alongside the app, sort by process name, and watch for new connections when you trigger actions. If a connection appears under the app's process and you cannot explain it, the audit is positive: the app is sending something.

What counts as evidence

A single pktmon capture showing no traffic from the app's process during a ten-minute idle and a ten-minute active session is reasonable evidence. A capture showing one connection to a version-check endpoint that returns a 200 with a tiny body is consistent with "telemetry-free, with version check." A capture showing recurring POST requests to an analytics provider during normal use is not telemetry-free, regardless of what the readme says.

For projects with public source, you can corroborate the network evidence by grepping the source for known telemetry SDKs:

grep -r "sentry" src/
grep -r "amplitude" src/
grep -r "posthog" src/
grep -r "segment" src/
grep -r "telemetry" src/

A hit is not a conviction — Sentry can be used for crash reporting only, with explicit opt-in. But a hit combined with traffic to that provider during a session is a strong signal. For more on reading source, see reading an Electron app's IPC surface as a user.

The dependency-tree audit

For Electron apps especially, the dependency tree is where unannounced telemetry lives. A package.json with 400 transitive packages can include an analytics SDK the maintainer never deliberately added. Two checks help: run npm ls (or pnpm why) against the package name of any SDK you see in traffic, and read the lockfile diff between releases. A new entry in package-lock.json for @sentry/electron or posthog-js is a concrete signal worth an issue tracker question, even if the maintainer's intent was crash reporting only.

The same audit applies to native dependencies. A Rust crate that mentions ureq or reqwest in its Cargo.toml is making outbound HTTP possible; whether it does so is a question for the source.

The honest case for Edge-Drop

Edge-Drop's source is Apache-2.0 on GitHub. The readme states no telemetry. The audit you would run is the same as for any other app: install on a clean machine, capture idle and active traffic, confirm zero connections outside the auto-updater. If you find traffic the readme does not mention, file an issue. If the issue gets no response, see bus factor: what if a solo app goes quiet.

This is not a claim that Edge-Drop is telemetry-free. It is a claim that the verification method is the same as for any other tool, and the source is available for grep. For a privacy-first comparison, see best clipboard manager if you care about privacy and red flags in clipboard app marketing.

Limits of the method

Network monitoring catches what is sent; it does not catch what is stored locally and exfiltrated later. A clipboard app could in principle cache telemetry to disk and ship it on the next update check. The defence is the same: capture during an update, not just during normal use.

The method also does not catch side channels. An app could leak data through DNS queries, through TLS SNI, or through the timing of its requests. These are exotic for desktop utilities and rare in practice, but they exist.

For most users, the practical takeaway is simpler: install the app on a clean machine, capture ten minutes of idle traffic, capture ten minutes of active traffic, and read what you see. If the answer is "nothing," the marketing claim is supported. If the answer is "one connection to a known analytics provider," the marketing claim is wrong, and the issue tracker is the next step.

Related reading

• Why macOS Has Better Visual Clipboards Than Windows
• Windows Equivalents If You Used Paste, Maccy, or Raycast
• What Local-First Software Means for Clipboard Apps
• How to Enable Clipboard History in Windows 11

Sources

• Microsoft Learn — pktmon — official documentation for the Windows built-in packet monitor
• Wireshark — User's Guide — official Wireshark documentation, including process correlation and protocol dissectors
• Sysinternals — TCPView — official TCPView download and documentation from Microsoft Sysinternals
• Microsoft Learn — Windows diagnostic data — official description of what Windows itself sends, useful for distinguishing OS traffic from app traffic
• OWASP — Software supply chain — community reference for the dependency-tree attack surface that makes source-availability necessary but not sufficient

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support