Skip to content

ZeroTrace AirLeak

Alert Rules

Every privacy and tracking alert the firmware fires

The alert engine is what turns "AirLeak captures everything" into "AirLeak tells you what matters." Each captured event runs through every armed alert rule. Matching events trigger the rule, surface in the desktop's alerts page, and stream to the desktop as AL: lines.


Severity levels

LevelColorMeaning
0 — InfograyInformational. Not necessarily a problem.
1 — LowblueMinor leak or expected behavior worth noting.
2 — MediumyellowReal exposure of identifiable data.
3 — HighredStrong tracking signal or active attack pattern.

The desktop alerts page sorts by severity descending — high-severity alerts always at the top.


Alert rate limiting

Each rule has a per-device cooldown of 30 seconds. A rule that fires for Device A doesn't re-fire for Device A again for 30 seconds, even if the conditions remain true. This prevents flooding the alert log with repeats.

The sole exception: multi_hour_follower re-checks every hour and re-fires if the condition persists, because the time-since-first-seen is genuinely changing.

Disabled rules don't fire at all (and don't consume cycles). See airleak-alert-disable.


Rule reference

airdrop_discoverable — severity 2

Trigger: An AirDrop discovery advertisement is observed where the status indicates Everyone mode.

What it means: A nearby iPhone has AirDrop set to receive from everyone. The phone is broadcasting hash prefixes of the user's Apple ID, phone number, and email. These prefixes are short and can be cracked offline back to plaintext within seconds. Anyone nearby can also spam the user with unsolicited file-share prompts.

Surfaced detail: hash prefixes, sender MAC.

What you can do: most useful in public spaces. iOS 16.2+ defaults AirDrop to Contacts only. Seeing Everyone suggests an old iOS or someone who manually changed it.


findmy_separated — severity 1

Trigger: A Find My / AirTag advertisement is observed where the status flag indicates separated-from-owner mode.

What it means: An AirTag or compatible Find My accessory is broadcasting in "owner not nearby" mode. Normal for a tracker in a backpack while you walk away briefly, but persistent observation across hours can indicate an unwanted tracker.

Surfaced detail: tracker MAC, public-key prefix, first-seen timestamp.

What you can do: cross-check against your own AirTag list. If unrecognized, walk to a different location and see if the alert follows you — multi_hour_follower covers that scenario.


multi_hour_follower — severity 3

Trigger: The same fingerprint is observed at unique timestamps spanning more than 3 hours, with at least one alert (such as findmy_separated) on it.

What it means: A tracker has been near you persistently for hours. This reproduces the iOS "AirTag found moving with you" alert in our captures.

Surfaced detail: fingerprint, every MAC seen, first-seen, last-seen, observation count.

What you can do: if it's confirmed unfamiliar, take action — locate the device, contact local authorities if appropriate.


pii_ssid_in_probe — severity 1

Trigger: A WiFi probe-request includes an SSID matching personal-naming patterns:

  • Name + device token (Sarah's iPhone, John's MacBook)
  • Personal possessive (My Phone, Mom's Hotspot)

What it means: The probing client is asking the air if a network with this name is nearby. The SSID itself reveals identity.

Surfaced detail: SSID, probing MAC.

What you can do: if it's your own phone, fix the SSID name on your home/office network. If it's a stranger's, you've passively learned their first name and that they own the named device.


corp_ssid_in_probe — severity 2

Trigger: A probe-request includes an SSID matching corporate-network patterns. Examples:

  • *-Corp-Wifi, *-Corporate, *-Internal
  • Known major-corp guest patterns (Microsoft-Guest, GoogleGuest, AppleGuest, SalesforceGuest, AmazonGuest)
  • eduroam, corp-vpn

What it means: The probing client has a saved corporate network — reveals where the user works (or has worked).

Surfaced detail: SSID, probing MAC.

What you can do: useful for security awareness. Organizations seeing their corp SSID in passing probes know that user's device is leaking employer identity in public.


airport_ssid_in_probe — severity 1

Trigger: A probe-request includes a known airport free-WiFi SSID (*-airport, _LHR_Free_WiFi, LAX-WiFi, JFK-Free, Boingo Hotspot, _Free_Lufthansa, BoardingPassWiFi, Cathay Pacific Lounge, etc.).

What it means: The probing client has been to that airport. Travel-pattern leak.

Surfaced detail: SSID, probing MAC.


hotel_ssid_in_probe — severity 1

Trigger: A probe-request includes a known hotel WiFi SSID (Marriott_GUEST, Hilton_HONORS, Hyatt_GUEST, IHG_GUEST, Best Western Lobby, Holiday Inn Wifi, airbnb-*, vrbo-*, etc.).

What it means: User has stayed at this hotel chain. Travel + accommodation leak.

Surfaced detail: SSID, probing MAC.


cafe_ssid_in_probe — severity 0

Trigger: A probe-request includes a known coffee-shop WiFi SSID (Starbucks WiFi, Costa Coffee, Pret Free WiFi, etc.).

What it means: User frequents that chain. Lifestyle leak — low severity because the geographic implication is broad.

Default: disabled (often noisy in urban captures).


open_network_near — severity 0

Trigger: A beacon or probe-response is observed for a network with no encryption.

What it means: An open WiFi network is in range. Anyone connected has all traffic visible to other clients.

Surfaced detail: SSID, BSSID, channel, RSSI.

What you can do: useful for security audits where encryption would be expected. Open networks in homes are highly unusual.


wep_network_near — severity 2

Trigger: A network using WEP (privacy bit set, no RSN).

What it means: WEP is trivially crackable in minutes with public tools. Effectively no encryption.


wpa_personal_only — severity 1

Trigger: A network whose AKM list contains only PSK (no SAE), with cipher TKIP or CCMP-128 only.

What it means: WPA2-Personal at best — no WPA3, no MFP-required. Vulnerable to KRACK and PMKID extraction.


wps_enabled — severity 0

Trigger: A vendor-IE WPS payload is observed with PIN method enabled.

What it means: WPS-PIN is brute-forceable in hours.


mfp_required_off — severity 1

Trigger: An RSN beacon with MFP-required = false and MFP-capable = false.

What it means: Network is vulnerable to deauth-driven evil-twin attacks. WPA3 mandates MFP; older WPA2-only networks often have it off.


deauth_burst — severity 2

Trigger: 5+ deauth frames observed within 10 s, targeting the same destination MAC.

What it means: Either an attack (deauth-driven evil-twin), a buggy AP burst, or local 2.4 GHz interference confusing the AP.

What you can do: walk away. If the burst follows you, suspect targeted activity.


tile_tracker — severity 1

Trigger: A Tile Service UUID advertisement is observed.

What it means: A Tile tracker is in range. Same tracking-implication category as AirTag detection.


samsung_smarttag_near — severity 1

Trigger: A Samsung SmartTag advertisement.

What it means: SmartTag is in range. Includes mode (owner_nearby / moving / separated) when broadcast.


unknown_tracker_near — severity 1

Trigger: A tracker-class device that doesn't match any known fleet (AirTag / Tile / SmartTag / Pebblebee / Chipolo).

What it means: An unfamiliar tracker is broadcasting. Could be a niche product or a custom-built tracker.


random_mac_no_name — severity 0

Trigger: A device with a locally-administered (random) MAC advertises BLE without ever resolving a friendly name.

What it means: A privacy-randomized device that doesn't allow scan responses. Common for iPhones in fully private mode. Almost never alarming on its own.

Default: disabled (info-only).


mac_rotation_detected — severity 0

Trigger: The fingerprinter merges 2+ MACs into one device entity (cross-MAC identification succeeded).

What it means: The device randomized its MAC and we tracked it across rotations. Expected behavior for modern devices but worth knowing it's happening.

Surfaced detail: list of MACs grouped, fingerprint key.


Alert ring buffer

The firmware keeps the last 1024 alerts in an alert ring buffer. When full, the oldest get evicted.

The desktop reads alerts via:

  1. Real-time stream — every alert is also pushed over USB-CDC as an AL: line
  2. Replay on connect — when the desktop connects mid-capture, it issues airleak-alerts-replay to backfill alerts that fired before it attached

This means alerts from before the desktop attached are recoverable up to the ring depth.


Configuring alerts

You can disable individual rules. Disabled rules don't fire and don't consume cycles.

airleak-alert-disable cafe_ssid_in_probe
airleak-alert-enable cafe_ssid_in_probe
airleak-alert-list                   # full enable/disable state

State persists across reboots.


False positives are normal

Some alerts will fire on perfectly innocent traffic. open_network_near at a coffee shop is expected; iphone_in_call at a busy office is constant. We surface them because somebody downstream might want them. The desktop's alerts page has a severity filter — set it to ≥1 or ≥2 to drop the noise.

Command Palette

Search for a command to run...