Who's Calling? Auditing What Your Plugins Say Behind Your Back

Open a terminal, start a session, and watch what happens on your network. If you've never done it, the first run is instructive. License checks, update pings, crash reporters, and the occasional analytics call from a plugin you'd swear was a dumb little EQ.

None of this is automatically sinister. Most of it is licensing and support, and there are legitimate reasons a vendor wants a heartbeat. But you should know what's leaving your machine, and on Linux you have every tool you need to find out.

Why a plugin wants the internet

There are five common reasons, and they behave differently.

License validation is the big one. Some plugins call home at launch, some on a schedule, some only when you open the authorization panel. Many systems cache a token and work offline for a period — thirty days, ninety days, sometimes indefinitely until something changes.

Update checks are usually benign and usually periodic. They leak a little information about which products you own and when you use them.

Crash and telemetry reporting sends stack traces, plugin versions, host names, and sometimes session metadata. Whether that's acceptable depends on how much you care about session names and file paths crossing the wire.

Analytics shows up in plugins built on frameworks that pulled in a mobile-style SDK. This is the category nobody expects and everybody should look for.

Content and preset sync is the friendliest case, and often the most chatty.

Start with a baseline

Before you open anything, capture what your machine normally does. Open a browser and check your mail, and you'll see a torrent of connections from things that have nothing to do with audio.

So do this: disconnect the network, start your DAW, load the plugin, play a few notes, close it. That's your silent control. Then reconnect, repeat the same steps, and compare. Whatever is new is coming from the plugin or its licensing service.

Three levels of auditing

The passive level costs nothing. ss -tupn shows current connections with process names. lsof -i does something similar for open sockets. Run either in a loop while you're auditioning plugins and you'll get a rough map of who's talking.

pw-top isn't the only thing you should keep an eye on, either.

The active level is tcpdump or Wireshark. Capture for five minutes, then look at destination hosts and ports. You don't need to read packets — hostnames and timing will tell you most of the story. nethogs and iftop give you a live per-process view if you prefer something more visual.

If you want to see exactly what's being sent, strace -f -e trace=network against the plugin process will show connection attempts and the hostnames being resolved. For encrypted traffic you won't get contents, but you'll get the who and the when.

Reading the results without panicking

A connection to a domain you recognize as the vendor's licensing server is a known cost. A connection to an analytics endpoint you've never heard of is worth investigating.

A few patterns to note:

• Traffic on plugin load only is usually a license check.
• Traffic every N minutes is usually a heartbeat or update check. It also creates a usage fingerprint.
• Traffic when the GUI opens is often an embedded browser fetching a store page or news feed.
• Traffic to addresses in unexpected countries isn't automatically bad, but it deserves an explanation.
• DNS lookups for domains unrelated to the vendor are the ones that should raise an eyebrow.

Record hostnames per plugin. That list becomes your allowlist, and it turns a vague worry into a maintainable policy.

Deciding what's acceptable

There's no universal answer, but there's a useful question: does this network activity serve me, or does it serve someone else?

An authorization check that lets you keep working offline for thirty days serves you. A heartbeat that tells a vendor your plugin was open at 11 p.m. serves them. Neither is illegal, but you get to have an opinion.

If you're working on material under an NDA, or you just don't want your session names leaving the building, that opinion should be firm.

An offline-by-default workflow

You can't simply yank the network cable and expect everything to work, so build this in layers.

Authorize while connected, then go offline. Most licensing systems tolerate this. Check the vendor's documented offline period before you rely on it, and re-authorize on a schedule rather than in the middle of a deadline.

Use a firewall policy, not a cable. Outbound rules that default to deny and allow only the hosts you've identified give you internet access for everything else while keeping the interesting ports quiet. nftables or ufw both handle this fine.

Sinkhole the noise. Point known telemetry domains at 127.0.0.1 in /etc/hosts or through a local DNS blocker. It's crude, it's effective, and it's reversible.

Sandbox aggressively. firejail or a network namespace via unshare -n will run a plugin host with no network interface at all. If a plugin works happily in that environment, it never needed the connection in the first place.

Test before you trust. Anything you do to restrict traffic should be validated with a real session, a real save, and a real reopen. Bench testing a plugin in isolation proves very little.

Where to stop

The goal isn't a studio with no network. It's a studio where you could name, if asked, every connection your plugin folder makes and why. Most producers can't. It takes one evening to change that, and the list is genuinely useful the next time a plugin stops loading after an update and you need to know whether authorization or the binary is at fault.