Privacy Audit Verification Guide Independent

Try to catch us making a network call.

We claim MeetingVault makes zero network calls during recording and transcription. 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 MLX framework and a local Whisper model. There is no server to call. Nothing leaves your machine.

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

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.

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.

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 the waitlist API endpoint. Nothing during the recording session.

Activity Monitor (no Terminal needed)

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

Open Activity Monitor (Applications → Utilities, or Spotlight)
Click the Network tab
Find the MeetingVault row and note its current Sent Bytes and Rcvd Bytes before you start recording
Start a recording session and let it run
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.

Little Snitch (continuous monitoring)

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

Install Little Snitch
Open Little Snitch Network Monitor
Filter by MeetingVault in the process list
Record a meeting from start to finish
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/waitlist: only if you submit your email

Block both if you want. The app still works. The transcription pipeline 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.

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 + waitlist) -->
                <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 waitlist form. 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 14+)
                    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 MLX Whisper (no network call)
                    let transcript = try await whisper.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.

Join the founding member waitlist

$9/month founding rate, fixed for life. Ships when it's ready.

Show HN post · Privacy scorecard · Blog · Privacy policy