Privacy Audit Verification Guide Independent

Block it from the internet. It still transcribes.

We claim you can block all of MeetingVault's network access and still record and transcribe — your meeting content never leaves your Mac. Don't take our word for it. Here's how to verify it yourself, using tools you already have.

🔍

The open audit challenge

Start MeetingVault, record a meeting, and use any of the methods below to monitor its network activity. If you see a single outbound connection to any host other than your local network during recording or transcription, we want to know at sully@getmeetingvault.com. We will investigate immediately and publish what we found.

The entire transcription pipeline runs on your Mac, using Apple's on-device Speech framework (SpeechAnalyzer). There is no server to call. Your meeting content never leaves your machine.

We built MeetingVault to pass that test. That constraint is the product.

1

Turn off WiFi (no tools needed)

The simplest possible test. No software required.

Disconnect from the internet entirely. Then open MeetingVault and record a meeting.

Result: transcription works. You get a complete transcript. Nothing breaks.

A product that depends on the cloud fails when you cut the network. MeetingVault doesn't fail. If it did, this page wouldn't exist.

2

nettop (built-in, per-process, live view)

Built into macOS. Shows live per-process network stats. No install needed.

While MeetingVault is recording, open Terminal and run:

# Find MeetingVault's PID first pgrep -l Meeting   # Then watch its live network stats (replace PID with actual value) nettop -p PID

You'll see a live table. The bytes_in and bytes_out columns for MeetingVault should stay at zero during recording and transcription. If any data is moving, nettop shows it immediately, by process.

3

lsof (built-in, open connections)

Lists every open network connection by process name.

While MeetingVault is recording:

# Poll for MeetingVault network connections every 2 seconds # (while loop works without Homebrew; watch -n 2 also works if installed) while true; do lsof -i -n -P | grep -i meetingvault; sleep 2; done

Expected output during recording and transcription:

(no output)

Want to see everything MeetingVault has opened since it launched? Run lsof -i -n -P -p $(pgrep -f MeetingVault) and scroll through the full list. The only entries you'll see are Sparkle update checks (which fire once on launch, not during recording) and license checks against getmeetingvault.com once you start a trial or subscribe. Nothing during the recording session.

4

Activity Monitor (no Terminal needed)

Built-in GUI approach. Good for verifying at a glance.

  1. Open Activity Monitor (Applications → Utilities, or Spotlight)
  2. Click the Network tab
  3. Find the MeetingVault row and note its current Sent Bytes and Rcvd Bytes before you start recording
  4. Start a recording session and let it run
  5. After transcription completes, compare the byte counts to your baseline

The counters are cumulative since app launch, so you need a before/after comparison. Any bytes transferred during recording would show up here as an increase over your baseline. You won't see one.

5

Little Snitch (continuous monitoring)

The most thorough macOS network monitor. Trial version works for this.

  1. Install Little Snitch
  2. Open Little Snitch Network Monitor
  3. Filter by MeetingVault in the process list
  4. Record a meeting from start to finish
  5. Review the connection log for MeetingVault

During recording and transcription, no connections are logged. The only entries (if any) appear outside the recording session:

  • getmeetingvault.com: Sparkle update check, fires once on app launch
  • getmeetingvault.com/api/license: license checks, only once you start a trial or subscribe

Block both if you want. Recording and transcription keep working (the license check has an offline grace period of about a week, so a paying user is never locked out). The transcription pipeline itself has no external dependencies.

For the skeptical (we respect this)

Create a Little Snitch rule that denies all connections from MeetingVault. Record a meeting. Transcription completes. Nothing breaks. That's by design.

6

tcpdump + Wireshark (packet-level)

Raw packet capture. If anything gets out, this catches it.

Capture a recording session to a pcap file, then inspect it in Wireshark filtered by MeetingVault's PID:

# 1. Get MeetingVault's PID pgrep -f MeetingVault   # 2. Find which ports it has open (if any) lsof -i -n -P -p $(pgrep -f MeetingVault)   # 3. Capture all traffic to file, then analyze in Wireshark sudo tcpdump -i en0 -n -w /tmp/meetingvault-audit.pcap # Open the .pcap in Wireshark and filter by process or IP

Prefer HTTP proxy tools? Proxyman or Charles Proxy will intercept any HTTPS calls MeetingVault makes, with full SSL inspection. You won't see anything during a recording session.

Read the signed entitlements

macOS app entitlements declare what capabilities an app is authorized to use. You can extract them from the signed binary and read them yourself:

codesign -d --entitlements - /Applications/MeetingVault.app

What you'll see in the output:

<!-- MeetingVault entitlements (relevant network entries) -->   <!-- Outbound network access (for Sparkle updates + license checks) --> <key>com.apple.security.network.client</key><true/>   <!-- NOT present: inbound server capability --> <!-- com.apple.security.network.server is absent -->

MeetingVault requests network.client only, which covers outbound connections for the update checker and license checks. It does not request network.server. The entitlements are signed into the binary by Apple's notarization process. They cannot be changed without invalidating the signature.

The entitlements tell you what the app can do. The audit methods above tell you what it actually does during a recording. Between the two, you have a complete picture.

What the recording pipeline does

// pseudocode, simplified from Swift source
// 1. Capture audio via ScreenCaptureKit (audio-only mode, macOS 26+) let stream = SCStream(filter: filter, config: config) // ScreenCaptureKit with audio-only filter cannot read screen pixels. // Captures mic + system audio to in-memory buffer.   // 2. Transcribe locally via Apple's Speech framework (no network call) let transcript = try await speechTranscriber.transcribe(audioBuffer) // Runs on-device on Apple Silicon. No external API call.   // 3. Write transcript to local SQLite database try context.save() // Local file only. Never synced to cloud.   // 4. Zero and release the audio buffer audioBuffer.zero() // Audio is gone. Transcript is all that remains.

Run the same test on any competitor

Open nettop or Little Snitch and run the same audit on Otter.ai, Fireflies, or Fathom during a recording session. You'll see a constant stream of outbound connections. That's not a bug. It's how their product works. Your audio travels over the network in real time to their transcription servers.

We built MeetingVault to pass that test. That constraint is the product.

See the full privacy comparison →
⚠️

Found something unexpected?

If your audit turns up a connection that shouldn't be there, email sully@getmeetingvault.com with what tool you used and what you saw. We will investigate and publish the findings. Any leak is a critical bug.

Try MeetingVault free for 14 days

$9/month founding rate, fixed for the life of your subscription. Download it and run the audit yourself.

Download for Mac

No credit card to download. Requires macOS 26 and Apple Silicon.

Show HN post · Privacy scorecard · Blog · Privacy policy