Privacy & Legal

AirLeak is a passive RF-monitoring tool. The information it collects is publicly broadcast by every device in range — but that doesn't mean every use of that information is appropriate or legal.

This page explains what AirLeak does and doesn't capture, the legal context for passive RF monitoring in major jurisdictions, and recommended practices for responsible use.

---

What AirLeak does NOT do

• No decryption. AirLeak only reads frames that broadcast in plaintext on the radio (BLE advertisements, WiFi management frames). Encrypted traffic — anything inside a WPA-protected data session, anything inside a paired BLE connection — is not captured.
• No active intrusion. AirLeak does not associate with WiFi networks. It does not pair with BLE peers. It does not de-authenticate clients or transmit deauth frames. It does not run scans against IP-layer services.
• No probing of authenticated services. AirLeak doesn't open TCP connections, doesn't probe mDNS-Bonjour-discovered hosts, doesn't enumerate SMB shares. The unit's only transmissions are BLE SCAN_REQ packets (when active scan is on) — a single 30-byte packet per scannable advertisement.
• No data exfiltration. All captured data stays on your local machine. The desktop app does not transmit captured RF data to any cloud, server, or third party. The library, session records, and live captures live on your local disk.
• No user identification of bystanders by default. AirLeak captures publicly broadcast identifiers (MACs, names, SSIDs) — but it doesn't lookup people, run face-recognition, or correlate with online services.

---

What AirLeak does capture

• WiFi management frames (probe-requests, beacons, probe-responses, association-requests, deauthentications) on 2.4 GHz channels. These are broadcast unencrypted by every WiFi-capable device.
• BLE advertisements and scan responses on 2.4 GHz BLE advertising channels (37, 38, 39). These are broadcast unencrypted by every BLE peer in advertising state.

Both are the publicly-visible "discovery" layer of the protocols. They exist specifically to be heard by any nearby radio.

---

Legal context (general guidance — not legal advice)

The legal status of passive RF monitoring varies by jurisdiction. We aren't lawyers; this section is general orientation only.

United States

Passive reception of radio signals on shared frequencies is generally legal under federal law (47 USC § 605). The same statute prohibits divulging the contents of intercepted communications without authorization, and prohibits using such interceptions for personal gain.

What's broadly understood as legal:

• Listening to broadcast advertisements and management frames in a space you occupy
• Recording aggregate observations (MAC counts, SSID names) for personal use, security research, or property surveys

What's risky:

• Publishing identifiable information about specific bystanders
• Using captured data for stalking, harassment, or commercial profiling
• Capturing in a space you don't occupy and aren't authorized to monitor

The Wiretap Act (18 USC § 2510 et seq.) generally exempts public-radio reception, but is not a blanket green light for everything. Some state laws (California, Florida, Maryland) impose stricter rules on the recording of communications.

European Union (GDPR)

GDPR considers MAC addresses (even rotating ones) to be personal data when associated with an identifiable person. Passive capture of identifiable MAC traffic in a private capacity is generally permitted under the "household exception" (Recital 18). Commercial deployments and any retention beyond personal use require a lawful basis under Article 6.

Practically: capturing in your own home or office, for your own use, with no retention beyond what's needed, is fine. Deploying AirLeak in a public space and saving the data, sharing it, or using it for any purpose touching another person's identifiable data is regulated and may require consent or another lawful basis.

United Kingdom

Similar to the EU under UK GDPR / Data Protection Act 2018. The Investigatory Powers Act regulates unauthorized interception of communications but does not generally cover discovery-layer broadcasts. Personal-use captures in spaces you occupy are not generally prohibited.

Other jurisdictions

Germany, Switzerland, Japan, Australia, and Canada all have privacy frameworks that treat passive RF monitoring within the household exception or its local equivalent. Public deployments and commercial uses are regulated.

The important common thread across jurisdictions: the act of reception is generally legal; the use, retention, and sharing of identifiable data is what's regulated.

---

Recommended practices

Use spaces you control or are authorized to monitor

Capturing in your own home, your own office, or a space where you have explicit authorization (e.g. a security-research engagement, a vendor lab, an employer-issued workspace) is the cleanest scenario.

Capturing in spaces where you don't have authorization (a stranger's apartment from outside, a coffee shop you happen to be sitting in) is a gray area. Avoid retaining identifiable data from such captures.

Limit retention

The library and session files are local-only, but they accumulate over time. Periodically:

• Delete sessions you no longer need (Sessions page → trash icon)
• Clear the library if you don't need cross-session history (Insights → Library → Clear)
• Mark sensitive devices as do_not_log to prevent retention

A 30-day retention window is a reasonable default for most personal use.

Don't publish identifiable data

Captured SSIDs, MACs, friendly names, AppleID hashes, and probed-network history are identifying information. Don't post these on social media, in blog posts, in research papers, or in any context where they can be linked back to specific people.

If you need to publish capture results (security research, vendor disclosure), aggregate the data and anonymize the identifiers. Replace MACs with index numbers, redact friendly names, hash the SSIDs.

Mark your own devices

Use the desktop's "Mark as own" feature on devices you control. This:

• Suppresses retention of unnecessary detail about those devices
• Excludes them from cross-session privacy stats
• Helps separate "noise from your own pocket" from "actual environment"

Switch to Setup mode when not capturing

When you're moving locations, in a meeting, or otherwise not actively monitoring, switch to Setup. This:

• Stops the radios entirely (no more advertisements captured)
• Finalizes the active session
• Reduces power draw and heat

This isn't about legality — it's about not accumulating data you'll never use.

Disable specific alert rules in spaces where they're noise

In a coffee shop, cafe_ssid_in_probe and open_network_near will fire constantly. Disable them per-session or persistently if they don't matter to your use case.

airleak-alert-disable cafe_ssid_in_probe
airleak-alert-disable open_network_near

---

What about active scan?

The default firmware setting is active scan ON, meaning the unit transmits SCAN_REQ packets to elicit SCAN_RSPs. This is technically a transmission, but:

• The packets are protocol-standard (defined by the Bluetooth Core specification)
• They are sent only in response to scannable advertisements
• They contain no payload beyond the SCAN_REQ structure (MAC, scan filter)
• Every BLE-capable device in scanning mode does this — your phone does this constantly when it scans

The legal status of active scanning is the same as passive scanning in every jurisdiction we know of, because the SCAN_REQ is part of the BLE discovery protocol that the advertising peer expects to receive.

If you want strictly passive operation (no transmissions at all), set:

airleak-active-scan off

Tradeoff: friendly device names disappear for ~80 % of devices, since most put the friendly name in the SCAN_RSP, not the legacy advertisement.

---

Special note: tracker-following detection

The multi_hour_follower alert and findmy_separated alert can detect AirTags and similar trackers being used to follow someone. This is a genuine safety feature — many published cases of stalker-AirTag use have been detected by similar tools.

If AirLeak fires multi_hour_follower and you don't recognize the tracker:

1. Don't panic — the alert just means a tracker was near you for a long time. Many false positives exist (a tracker forgotten in a public place that you happened to pass twice).
2. Verify — check the device detail page. If the same fingerprint follows you across separate locations, it's more likely a real follower.
3. Locate — modern AirTags can be made to play a sound via the iOS / Android Find My app, even by non-owners. Use that to physically locate the device.
4. Document — the desktop's session export includes everything you need for a report (timestamps, MACs, fingerprint, observation count).
5. Contact authorities — in genuine stalking scenarios, local police can subpoena Apple / Tile / Samsung for the tracker owner's identity.

---

Data we never want you to capture

Some categories of RF traffic we encourage users not to retain even if technically captured:

• Medical device data — pulse oximeters, glucose meters, BP cuffs, etc. The aggregator picks these up; we recommend marking them do_not_log so retention is minimized.
• Hearing aids — Bluetooth hearing aids broadcast advertisements that can identify a user's accessibility needs. Treat as sensitive.
• Children's devices — toys, smart watches, baby monitors. If you're capturing in a space with children, use Setup mode or strict per-device labeling to avoid accumulating their data.

The "Mark as do_not_log" feature in the device detail page suppresses both library retention and session-export inclusion for the marked device.

---

Reporting issues

If you discover a privacy concern with AirLeak itself — a setting that retains more than expected, a default that captures too aggressively, a leak in the desktop app — report it via security@zerotrace.pw. We treat privacy bugs the same as security bugs.

---