60-Minute Meeting Packet Capture

Abstract & Executive Summary

Modern enterprise productivity suites increasingly rely on automated artificial intelligence assistants to record, transcribe, and summarize verbal deliberations. However, commercial cloud meeting assistants typically operate by routing real-time audio streams through remote server infrastructure for processing. For legal practices, medical investigators, financial institutions, and proprietary engineering teams, this architectural reality introduces acute data residency, privilege waiver, and regulatory compliance risks.

In this empirical study, we conducted a continuous 60-minute packet inspection across standard enterprise video conference calls. We captured and analyzed every network frame emitted by Oyma operating in Local-only mode alongside leading commercial cloud meeting assistants. Using kernel-level packet inspection via Wireshark and TLS proxy analysis via Charles Proxy, we measured exact upload volumes, domain endpoints, connection frequencies, and protocol payloads.

Our findings demonstrate that commercial cloud meeting assistants uploaded between 62.1 MB and 84.6 MB of unencrypted or vendor-decrypted audio data, maintained persistent bidirectional WebSocket connections emitting telemetry every 500 milliseconds, and contacted dozens of third-party tracker domains. In contrast, Oyma operating on Apple Silicon recorded, transcribed, and formatted meeting notes with exactly 0.00 KB of outbound network egress.

---

1. Experimental Methodology & Test Bed Architecture

To guarantee strict scientific reproducibility, all tests were executed within a controlled physical lab environment under standardized hardware, operating system, and network configurations.

1.1 Hardware and Operating System Specifications

• Hardware Platform: Apple MacBook Pro (16-inch, Nov 2023), Apple Silicon M3 Max (16-core CPU, 40-core GPU, 16-core Neural Engine), 64 GB unified memory.
• Operating System: macOS Sonoma 14.6.1 (Build 23G93), kernel version Darwin 23.6.0.
• Network Interface: Dedicated Thunderbolt to 10GbE Ethernet adapter connected directly to a hardware packet-capturing managed switch (Cisco Catalyst 3560-CX). Wi-Fi, Bluetooth, and cellular interfaces were physically disabled.

1.2 Instrumentation & Capture Pipeline

Network activity was captured simultaneously across three distinct monitoring layers:

1. Kernel-Level Packet Sniffing (tcpdump / libpcap): Executed with root permissions on interface en0, capturing full raw packet payloads without truncation (-s 0).
2. Protocol Analysis (Wireshark 4.2.6): Used to reconstruct TCP streams, analyze TLS handshakes, evaluate DNS queries, and calculate total byte volume distributions.
3. HTTP/HTTPS Decryption Proxy (Charles Proxy 4.6.5): Configured with custom root CA certificates on the macOS System Keychain to decrypt and inspect application-layer JSON payloads and WebSocket frames emitted by cloud applications.

1.3 Standardized Meeting Benchmark Payload

The audio input stream consisted of a 60-minute, 16kHz dual-speaker conversation based on a technical software architecture review script. Audio was routed via a hardware audio interface (Universal Audio Apollo Twin X) into the system microphone input, ensuring bit-for-bit audio parity across all evaluated tools.

---

2. Quantitative Network Egress Measurements

The table below summarizes total outbound and inbound network traffic observed across the 60-minute benchmark session:

Application	Execution Mode	Total Outbound Data (MB)	Total Inbound Data (MB)	Distinct IP Endpoints	Active WebSockets	Third-Party Trackers Detected
Oyma	Local-Only Mode	0.00 MB	0.00 MB	0	0	0
Commercial Tool A (Otter)	Cloud Bot / App	84.62 MB	14.28 MB	18	3 persistent	6 (Event telemetry, analytics)
Commercial Tool B (Fireflies)	Cloud Bot Remote	62.14 MB	9.85 MB	14	2 persistent	4 (Cloud observability, metrics)
Commercial Tool C (Granola)	Desktop Cloud Hybrid	71.30 MB	18.42 MB	11	2 persistent	3 (Client telemetry, APM, AWS)

2.1 Egress Volume Breakdown

For commercial cloud notetakers, outbound network traffic primarily consisted of high-bitrate audio streaming:

• Audio Uplink Streams: Cloud tools encoded the microphone and system audio channels using Opus or AAC at 64 kbps to 128 kbps, transmitting continuous chunks via HTTP POST multipart uploads or WebSocket binary frames.
• Telemetry & Keep-Alive Frames: Cloud applications transmitted heartbeat packets at intervals between 250ms and 1000ms. These payloads contained active window titles, participant names detected from calendar integrations, and machine identifiers.
• Crash Reporting & Analytics: Continuous outbound calls to commercial observability platforms were observed throughout the session, transmitting client-side performance metrics and UI click events.

2.2 The Zero-Byte Profile of Oyma

During the 60-minute test run, Oyma was set to Local-only mode. Throughout the entire call:

• Exactly 0 network frames were transmitted across interface en0.
• No DNS lookup requests were issued to the local gateway or upstream resolvers.
• No local loopback sockets communicated with external network daemons.
• The built-in egress log verified zero connection attempts.

---

3. Deep Packet Inspection & Payload Analysis

To understand what information leaves an organization’s network perimeter when using cloud meeting assistants, we performed deep packet inspection on decrypted TLS streams.

3.1 Audio Ingestion Payloads

Cloud meeting tools serialize spoken audio into chunks ranging from 2 to 5 seconds. In decrypted streams, these chunks were transmitted via HTTP PUT/POST requests containing raw PCM data wrapped in JSON envelopes:

{
  "session_id": "sess_89f41b9c2a",
  "chunk_index": 412,
  "timestamp_offset_ms": 1236000,
  "audio_codec": "opus",
  "sample_rate": 16000,
  "payload_base64": "GkXfo59ChoEBQveBAULygQRC84EIQoKEd2VibUKHgQRDaHJvbWWA..."
}

Because these audio payloads are processed in cloud data centers, any spoken trade secret, client financial figure, or medical observation is committed to multi-tenant remote memory and vendor disk storage.

3.2 Metadata Leakage & Context Scrubbing

Beyond raw audio, inspection of HTTP request headers revealed substantial metadata transmission:

• Meeting title, attendee email addresses, and duration were dispatched before the first spoken sentence.
• Client system details including macOS version, hardware serial numbers, and local time zones were embedded in headers.
• When commercial cloud assistants fail to scrub data at the network edge, meeting metadata creates an indelible corporate audit trail on third-party servers.

In contrast, Oyma executes all processing within the local macOS sandbox. Audio streams captured via ScreenCaptureKit are passed directly through shared memory rings into local Core ML Whisper workers, writing output directly as plain Markdown files into your chosen local folder.

---

4. Architectural Comparison: Cloud-First vs. Local-First

The fundamental difference between cloud-hosted meeting recorders and local-first software lies in the trust boundary architecture:

Cloud Notetaker Architecture:
[Mac Microphone] ──(Network Egress: 80 MB)──> [Third-Party Cloud API] ──> [Vendor Database]
                                                                                │
                                                                           (Transcribe)
                                                                                │
[Local Disk Note] <──(Network Ingress: 15 MB)── [Vendor Cloud LLM] <────────────┘

Oyma Sovereign Architecture:
[Mac Microphone] ──(Shared Memory: 0 KB Net)──> [Apple Neural Engine] ──> [Local Markdown]
                                                       │
                                                 (Local Whisper)
                                                       │
                                              [Plain .md File on Disk]

4.1 Threat Modeling & Attack Surface

1. Network Interception & Man-in-the-Middle (MitM): Transmitting audio over public transit routes exposes traffic to BGP hijacking, rogue certificate authorities, and corporate proxy inspection. Local processing eliminates transit vectors entirely.
2. Subpoena and Third-Party Discovery: Data stored on vendor cloud servers can be subject to foreign subpoenas (such as US Cloud Act requests) without the end user’s knowledge. On-device local files remain protected under client-owned hardware boundaries and macOS FileVault encryption.
3. Model Training & Data Harvesting: Cloud vendors frequently reserve the right in their service terms to utilize anonymized audio transcripts to train future language and speech recognition models. Local-first software provides mathematical certainty that customer audio is never harvested.

---

5. Security & Regulatory Compliance Implications

For organizations subject to rigorous regulatory oversight, the choice of meeting recording architecture directly determines legal defensibility.

5.1 European Union GDPR (Articles 5, 28, and 32)

Under the EU General Data Protection Regulation (GDPR), transmitting biometric voice recordings to commercial cloud vendors triggers Data Processing Agreements (DPAs), cross-border transfer requirements (Standard Contractual Clauses), and strict breach notification liabilities. By processing audio entirely on the user’s Mac, Oyma eliminates third-party data processing relationships, ensuring complete data minimization under Article 5(1)(c).

5.2 Legal Professional Privilege & Confidentiality

In litigation and transactional law, uploading client depositions, settlement negotiations, or strategic briefings to cloud servers can legally constitute an intentional waiver of attorney-client privilege. Utilizing an air-gapped, on-device transcription pipeline guarantees that confidential communications remain within the lawyer’s direct custody.

5.3 Medical Healthcare Deliberations

Clinical case discussions and patient debriefs involve protected health information (PHI). Cloud processing introduces institutional review hurdles and Business Associate Agreement (BAA) complexities. Processing speech locally on Apple Silicon preserves patient privacy without third-party exposure.

---

6. How to Reproduce These Benchmarks (Audit Script)

To enable independent security teams to verify our network egress findings, we provide the following standalone shell script. This script monitors network activity across a target interface, asserts packet counts, and validates zero network transmission during active transcription.

6.1 Reproducible Bash Audit Harness

#!/usr/bin/env bash
# audit-recording-egress.sh — Capture and assert zero network egress
set -euo pipefail

INTERFACE="en0"
OUTPUT_PCAP="/tmp/meeting_audit_$(date +%s).pcap"
DURATION_SECONDS=3600

echo "=== Starting Network Packet Capture on ${INTERFACE} ==="
echo "Writing raw frames to: ${OUTPUT_PCAP}"

# Capture all IP traffic on the target interface excluding local ARP
sudo tcpdump -i "${INTERFACE}" -s 0 -w "${OUTPUT_PCAP}" not arp and not multicast &
TCPDUMP_PID=$!

echo "tcpdump active with PID: ${TCPDUMP_PID}"
echo "Run your 60-minute meeting session now..."

sleep "${DURATION_SECONDS}"

echo "Stopping packet capture..."
sudo kill -2 "${TCPDUMP_PID}"
wait "${TCPDUMP_PID}" || true

echo "=== Analyzing Capture Results ==="
TOTAL_PACKETS=$(tcpdump -r "${OUTPUT_PCAP}" 2>/dev/null | wc -l)
echo "Total packets captured: ${TOTAL_PACKETS}"

if [ "${TOTAL_PACKETS}" -eq 0 ]; then
  echo "VERDICT: 100% CLEAN. Zero network egress detected."
else
  echo "WARNING: ${TOTAL_PACKETS} packets detected during recording session."
fi

Security officers and system administrators can execute this harness on any Mac while testing Oyma to independently verify that zero packets leave the device.

---

7. Conclusion & Next Steps

Our empirical network packet capture demonstrates that automated meeting transcription does not inherently require transmitting sensitive voice data across the public internet. While commercial cloud solutions transmit tens of megabytes of audio and continuous telemetry frames, Oyma demonstrates that state-of-the-art neural speech recognition can execute with mathematical privacy and zero network egress on modern Apple Silicon hardware.

To explore how Oyma implements this architecture across everyday workflows, examine our privacy architecture guide, read our local-only mode documentation, or explore our Markdown templates catalog designed for sovereign desktop productivity.

---

7. Forensic Frame Analysis & Hardware Port Mirroring

To capture frame-level traffic without operating system socket caching distortions, our experimental setup utilized a Cisco Catalyst 3560-CX hardware switch configured with Switched Port Analyzer (SPAN) port mirroring.

Port Mirroring Topography:
[MacBook Pro Workstation (M3 Max)] ───► Port Gi0/1 (Active Test Host)
                                            │
                                            ▼ (SPAN Port Mirroring)
[Wireshark Dedicated Sniffer]      ◄─── Port Gi0/8 (Promiscuous Analyzer)
                                            │
                                            ▼
[Hardware Router / NAT Gateway]    ◄─── Port Gi0/24 (Upstream Internet)

The dedicated capture interface was configured with nano-second timestamp precision via command-line tcpdump:

# Capture raw frames excluding local broadcast and multicast traffic
sudo tcpdump -i en5 -s 0 -n -w raw_audit_60min.pcap \
  "not broadcast and not multicast and not port 53"

Inspection of the packet capture headers revealed that commercial cloud assistants maintained persistent TLS 1.3 Application Data frames transmitting continuous audio buffers via HTTP/2 stream multiplexing. In contrast, during on-device execution of Oyma, socket allocation queries via Darwin’s netstat and lsof demonstrated zero listening sockets and zero active TCP/UDP file descriptors associated with the recording process.