VIGIL/paper/vigil.md

# VIGIL: On-Device Temporal Detection of Personal Location Trackers, Including Identity-Rotating Clones

**Kara Zajac** · Black Flag Intel
Draft v0.1 · 2026-07-15 · *working paper, accompanies the VIGIL reference implementation*

---

## Abstract

Consumer item-trackers — Apple AirTag, Tile, Samsung Galaxy SmartTag, and the
Google Find My Device network — have become instruments of stalking: in a survey
of intimate-partner-violence survivors, 44% of those stalked reported physical
location tracking, with vehicles the most common hiding place. Every deployed
countermeasure (Apple *Tracker Detect*, the iOS *Find My* and Android *Unknown
Tracker* alerts, and the open-source *AirGuard*) shares a structural assumption:
it **keys on a device identity** and alarms when the *same* identifier is seen
repeatedly while moving with the victim. This assumption fails in two directions.
It is *spatial* where the true signal is *temporal*; and it is defeated outright
by identity-rotating clones — a commodity ESP32 firmware that cycles ~2,000 Find
My keys (a fresh one every ~30 s) tracked a victim for five days while raising
**zero** alerts on every tool tested.

We present **VIGIL**, an Android application that reframes the problem as
*temporal co-movement*: not "is a tracker near me" but "has *the same* tracker
been at enough of *my* distinct places, over enough time, while close enough to
be on me." VIGIL contributes (1) a cross-ecosystem, fully on-device detector that
parses five BLE wire formats and gates alerts on an RSSI proximity test that
prior tools omit, together with a learned, on-device *baseline* that auto-trusts
the trackers that live where the user lives; and (2) an identity-agnostic
**presence engine** that detects rotating-key clones by the one thing identity
churn cannot hide — an unbroken, coherent, co-moving RF *presence* — and a
**rotation-rate "squeeze"** argument showing that running an identity detector and
a churn detector together leaves no rotation rate that evades both. VIGIL holds no
network permission: the tracker database, the learned baseline, and all inference
run and remain on the device. We describe the per-ecosystem detection methodology,
the temporal model, the presence engine, the implementation, and a proposed
evaluation, and we are explicit about the adaptive-adversary floor below which
single-session on-device detection is information-theoretically impossible.

---

## 1. Introduction

The same crowd-sourced location networks that help people find lost keys also let
a motivated abuser find a person. Apple's Find My network turns a US$29 coin-sized
beacon into a globe-spanning tracker that piggybacks on hundreds of millions of
other people's iPhones; Google's Find My Device network does the same across the
Android install base. Placed in a target's bag, coat, or car, such a beacon
reports the target's location without any infrastructure of the attacker's own.

Platform vendors responded with **unwanted-tracking alerts**, and the security
community produced **AirGuard** (TU Darmstadt), the best open-source detector.
These tools work, in their measured evaluations, *slowly and narrowly*: an
in-the-wild study found an iPhone took 5 h 41 m to alert on an AirTag (and only on
reaching home Wi-Fi), never detected a Chipolo, and that Samsung's own app never
found its own SmartTag. All of them share the same core algorithm — **count
repeat sightings of one BLE identifier; alarm past a threshold** — and all of
them inherit its two structural weaknesses:

1. **Spatial, not temporal.** They reason about *presence*, so they need
   hand-tuned thresholds to avoid alarming on the many trackers legitimately
   around us. The discriminating fact — that a *stalking* tracker recurs across
   the victim's *changing* locations — is used only weakly.
2. **Identity-bound.** Because they track an identifier, any tracker that
   *rotates* its identifier faster than the accumulation window is invisible.
   Positive Security's *Find You* clone exploits exactly this: ~2,000 pre-loaded
   Find My public keys, one broadcast every ~30 s, so every sighting looks like a
   brand-new device. In a five-day carry test it defeated iOS, Apple's Tracker
   Detect, and AirGuard's background detection.

**VIGIL** is built on the opposite premise. Where OVERWATCH (its sibling project)
asks *what is watching this place*, VIGIL asks *what has been with me* — it is a
temporal detector. Its contributions:

- **A cross-ecosystem, on-device temporal detector.** VIGIL parses Apple Find My,
  Google FMDN, Samsung SmartTag, Tile, and the unified DULT format, filters to the
  separated-from-owner state where signalled, and escalates a device only when it
  clears a **co-movement test** across the user's distinct geographic cells — gated
  by an **RSSI proximity check** that AirGuard omits, which rejects the "tracker in
  a passing car" false positive.
- **A learned, on-device baseline.** VIGIL learns the places a user dwells and
  auto-trusts trackers that recur there across days — the user's own AirTag, a
  partner's Tile — collapsing the dominant benign false-positive class without a
  server and without the user tagging anything.
- **A presence engine for rotating clones.** VIGIL detects the attack class that
  defeats every deployed tool, by abandoning identity tracking in favour of
  identity-agnostic *presence continuity*, and we give a squeeze argument
  (§5.4) that closes the evasion gap left by either detector alone.
- **A privacy architecture with no network.** VIGIL requests no `INTERNET`
  permission. There is no server, no account, and no telemetry.

We are equally explicit about what VIGIL *cannot* do (§5.6, §10): a patient,
low-duty-cycle adaptive adversary can push detection from minutes-latency
single-session to days-latency multi-session, and no on-device passive detector
escapes that floor.

---

## 2. Background and threat model

### 2.1 BLE trackers and the separated state

An item-tracker is a Bluetooth-Low-Energy beacon. When **near its owner** it is
connected or advertises a non-locatable payload; when **separated** from its owner
it broadcasts a payload that any nearby "finder" phone can encrypt-and-upload to
the vendor's network, letting the owner retrieve its location. Two facts make
passive third-party detection possible at all:

1. Only the **separated** state matters for stalking — a tracker with its owner is
   not following *you* — and separated trackers advertise loudly (every ~2 s).
2. To be findable, separated trackers **rotate their identifier slowly.** The
   Apple/Google **DULT** specification, and each vendor's implementation, rotate
   the advertised address/key roughly **once per 24 hours** in the separated state
   (versus ~15 minutes near-owner). A separated AirTag holds one identity for a
   full day, re-rolling at 04:00 local. This slow rotation is *deliberate* — it is
   what lets a victim's phone recognise the same tracker over time — and it is the
   invariant the clone attack violates and that VIGIL's presence engine exploits.

### 2.2 Threat model

**Adversary.** Plants one or more trackers on the victim (bag, vehicle, clothing).
May use (a) a genuine, unmodified tracker; (b) a genuine tracker with a physically
disabled speaker; or (c) a modified/cloned emitter (custom firmware, rotating
keys, silent). The adversary controls the tracker but not the victim's phone.

**Defender.** The victim's Android phone, running VIGIL, **passively** scanning
BLE. It never transmits to or connects to the tracker for detection (an optional,
user-initiated GATT "make it ring" is out of the passive path). It has no server.

**Goal.** Alert the victim, with useful latency and a tolerable false-positive
rate, that a tracker is travelling with them — *including* when the tracker rotates
its identity or is silent.

**Non-goals.** VIGIL does not track individuals, does not deanonymise tracker
owners beyond the vendor-provided reactive flows, and does not claim to defeat a
patient adaptive adversary in a single session (§5.6).

---

## 3. Per-ecosystem detection

VIGIL's scanner (`scan/BleTrackerScanner.kt`) runs a hardware-filtered BLE scan —
the controller wakes the app only on a signature match, which makes screen-off
scanning deliverable — and hands each match to a stateless parser
(`scan/TrackerParser.kt`) that recognises five wire formats. For each ecosystem we
describe (a) the on-air **signature** VIGIL matches, (b) how it reads the
**separated** state, and (c) the **identity** it keys on for temporal correlation.

### 3.1 Apple Find My / AirTag

**Signature.** BLE manufacturer-specific data under Apple company id `0x004C`,
message type `0x12` (offline finding), payload length `0x19` (25 bytes). After
Android strips the two company-id bytes, the payload is
`[type=0x12, length=0x19, status, key(22), keyTopBits, hint]`.

**Separated state.** The **status byte** carries a "maintained" bit (bit 2): set
when the owner was in range within the current rotation period, cleared when
separated. VIGIL treats a cleared/absent maintained bit as separated. (Setting the
status byte to `0x00` is a known first-party-alert-suppression trick, so VIGIL
does not treat the bit as ground truth for *benign-ness* — only for *relevance*.)

**Identity.** The advertised P-224 public key **is** the identity, and — uniquely
— the BLE MAC is *derived from the key*, so both rotate together. VIGIL keys on a
hash of the advertised key bytes, which is stable across the ~24 h separated
epoch. The 04:00 re-roll intentionally severs continuity; §5 addresses bridging it.

### 3.2 Google Find My Device network (FMDN / "Find Hub")

**Signature.** BLE service data (AD type `0x16`) under 16-bit UUID `0xFEAA` (the
Eddystone UUID; pairing uses a different service, `0xFE2C`). The first
service-data byte is the frame type.

**Separated state.** VIGIL reads it **in cleartext**: frame `0x40` = normal, frame
`0x41` = unwanted-tracking/separated. A subtlety with defensive consequences: the
`0x41` state is *server-triggered* — Google decides a tag has been separated
(~≥30 min) and a nearby Android device flips it. A freshly-separated stock tag is
therefore still rotating its EID (~every 1024 s) and MAC together and is **not
passively re-linkable** until flipped to `0x41`, at which point the MAC freezes for
24 h. VIGIL keys FMDN identity on the MAC, valid within the separated epoch.

### 3.3 Samsung Galaxy SmartTag / SmartTag2

**Signature.** BLE service data under UUID `0xFD5A` (the Samsung company id
`0x0075` is emitted by all Samsung gear and is not tag-unique; the service UUID is
the anchor). A connectable/setup tag also exposes a `smarttag` device name.

**Separated state.** The first service-data byte encodes a 3-bit state (bits 5–7):
`2` = lost (after 15 min), `3` = "overmature-lost" (after 24 h; triggers Samsung's
own anti-stalking), `4`–`6` = paired/connected. VIGIL treats states 2–3 as
separated. In overmature state the rotating privacy id becomes daily-static,
giving a ~24 h re-link window; in the first 24 h everything rotates every 15 min
and is not passively re-linkable.

### 3.4 Tile

**Signature.** BLE service data under `0xFEED` (activated), `0xFEEC`
(pre-activation), or the legacy `0xFE84`.

**Separated state.** *None.* A Tile emits no separated/lost-state beacon — it is
"always findable," advertising identically whether with its owner or lost.

**Identity.** Tile's decisive property: the **BLE MAC is static and never
rotates**, in any state. This makes Tile the easiest ecosystem to correlate (an
indefinite persistent key) but the one with no separated flag, so VIGIL treats
every Tile as a live candidate and relies entirely on persistence + co-movement.
Notably, Tile's "Anti-Theft Mode" — which hides a Tile from Tile's *own*
Scan-and-Secure and from platform alerts — changes nothing at the BLE layer, so a
third-party scanner such as VIGIL detects an anti-theft Tile identically to a
normal one, closing a documented stalking gap.

### 3.5 DULT (unified, emerging)

**Signature.** BLE service data under UUID `0xFCB2`.

**Separated state.** The near-owner bit is the least-significant bit of byte 14
(`1` = near owner, `0` = separated); a Network-ID byte identifies the vendor
network. VIGIL parses this for forward compatibility as trackers migrate to the
unified format.

### 3.6 Partner tags and summary

Chipolo, Pebblebee, eufy, Motorola, Jio, and Rolling Square do **not** carry a
brand-specific signature: each SKU advertises as the *network* it was provisioned
to (Apple `0x004C`/`0x12` or Google FMDN `0xFEAA`). VIGIL detects the network, not
the brand; legacy proprietary SKUs (classic Chipolo, original JioTag) join no
crowd network and are out of scope.

| Ecosystem | Signature | Separated signal | MAC rotation (separated) | Re-link window |
|---|---|---|---|---|
| Apple Find My | mfg `0x004C`, type `0x12` | status "maintained" bit cleared | ~24 h (re-roll 04:00), MAC = key | ~24 h |
| Google FMDN | svc data `0xFEAA`, frame `0x41` | cleartext frame `0x41` (server-gated) | 24 h once `0x41`; else ~1024 s | ~24 h once separated |
| Samsung SmartTag | svc data `0xFD5A` | state byte 2/3 (lost/overmature) | 24 h once overmature; else 15 min | ~24 h once overmature |
| Tile | svc data `0xFEED`/`0xFEEC` | none (always findable) | **none — static MAC** | indefinite |
| DULT (unified) | svc data `0xFCB2` | byte-14 LSB = 0 | ~24 h separated | ~24 h |

---

## 4. The temporal co-movement model

### 4.1 The reframing

A tracker being *near* a user is uninformative — modern environments are saturated
with them. The stalking signal is **persistence across the user's own changing
locations**: because the phone is (almost) always on the user, counting a
tracker's presence across the user's *distinct places* over time *is* the
co-movement measure, and it needs no second trajectory.

### 4.2 The test

Each parsed sighting is geotagged with a coarse fused-location fix and written to
an on-device store (`data/db/VigilDatabase.kt`) as `(trackerId, timestamp, rssi,
separated, lat, lon, geohash7)`, retained 14 days. Over the trailing 24 h a
tracker is scored on:

- **Effective sightings** — raw sightings debounced to at most one per 15 min, so a
  2 s-interval beacon cannot trivially inflate the count. Require ≥ 3.
- **Distinct places** — the number of distinct **geohash-7 cells** (~153 m) among
  its sightings. Require ≥ N, with N = 2/3/4 by sensitivity (high/medium/low).
- **Span** — first-to-last minutes. Require ≥ T, with T = 30/45/90 min.
- **RSSI proximity gate** — the smoothed peak RSSI must at least once cross an
  on-body/in-bag floor (−90/−85/−80 dBm by sensitivity). **This is the piece
  AirGuard omits**, and it is what distinguishes a tracker *on* the user from one
  that merely shared a road with them at two lights.

A device escalates `OBSERVED → SUSPICIOUS → ALERTING` (`detect/CoMovementEvaluator.kt`).
ALERTING requires all four conditions; SUSPICIOUS requires repeated close sightings
without yet enough spatial/temporal spread. Non-separated (near-owner) sightings
never escalate. These thresholds are adapted from AirGuard's field-tuned model
(≥3 sightings, N distinct locations ≥150 m apart, T minutes) with the added RSSI
gate.

### 4.3 The learned baseline and the allowlist

Two trust signals suppress the dominant benign class — the trackers that *belong*
in the user's life.

- **Allowlist.** The user marks a tracker "This is mine"; it never alerts again.
- **Learned baseline** (`detect/BaselineManager.kt`). VIGIL counts location-tagged
  sightings per geohash-6 cell; a well-visited cell becomes an **anchor** (home,
  work). A tracker seen at an anchor on ≥ 3 distinct calendar days is auto-marked
  *baseline-safe* and excluded from alerting. This learns "the AirTag that is
  always in my house" without a server and without the user labelling anything.
  (The current visit-count anchor heuristic is a v1; the roadmap replaces it with
  stay-point/dwell clustering.)

---

## 5. The rotation-clone presence engine

This section addresses the attack class that defeats every deployed detector, and
is the paper's core modeling contribution. The full design is in
`docs/detection-rotation-clone.md`; we summarise the argument here.

### 5.1 The attack and why identity detectors fail

The *Find You* clone is one physical ESP32 radio that broadcasts a pool of ~2,000
Apple Find My public keys, cycling to a new one every ~30 s. To any identity-keyed
detector each key is a new device seen once, so the "same identifier ≥ 3 times"
counter never accumulates and the detector stays silent — measured at zero alerts
over five days.

### 5.2 The exploitable invariant

The defence begins with a standards fact: DULT, Apple, and Google **mandate ~24 h
rotation in the separated state**. A legitimate separated tracker therefore holds
one identity for a full day; a clone rotating every 30 s runs **~2,880× faster
than any specification-compliant device**. This is not a heuristic "that seems
suspicious" — it is a *categorical* violation of a standardised invariant, giving
a clean anomaly baseline.

### 5.3 Presence, not identity

VIGIL stops tracking *who* is present and starts tracking *whether one radio is
continuously present*. A rotating clone, to function as a tracker, must emit an
**unbroken stream of separated-state beacons at roughly stable close-range RSSI
that moves with the victim across locations where the ambient tracker population
fully turns over.** We formalise three identity-agnostic quantities:

- **Novel-identifier churn rate** `λ_novel` — the rate of never-before-seen
  separated identities (over a 5-min window against a 30-min novelty set). A real
  separated tracker ≈ 0.0007/min; the clone ≈ 2/min.
- **Presence continuity** — the duty cycle with which *some* separated beacon
  occupies the close band (RSSI ≥ ~−65 dBm), and the longest unbroken run.
- **Seamless-novel-handover chain** — the number of times the close-band identity
  *changes* to a **novel** id with **no RSSI discontinuity** (`|Δrssi| ≤ 8 dB`)
  and **no time gap** (`Δt ≤ 6 s`). One physical radio produces a long chain of
  such seamless handovers; a crowd of many radios at many distances produces
  gappy, RSSI-discontinuous handovers. This chain is the tell no amount of identity
  churn can fake while remaining a functioning tracker.

The physics that make co-movement a hard discriminator: a static tag or an
independently-moving passer can remain in the close band (radius R ≈ 10 m) for at
most `2R / v_rel` — ≈ 1.5 s at driving speed. Only a co-moving emitter (relative
velocity ≈ 0) has unbounded dwell. So a close-band presence sustained across ≥ 3
distinct cells while the user is moving *cannot* be explained by any single
ambient source.

### 5.4 The pipeline and the squeeze

A three-stage streaming pipeline (all O(1)-ish per sighting, on-device): a **CUSUM
change-point** on `λ_novel` versus a rolling personal baseline *triggers* an
identity-agnostic **presence-track confirmer** (counting seamless novel handovers
and RSSI coherence), which alarms only behind a hard **co-movement gate** (net
displacement ≥ 500 m across ≥ 3 cells while moving).

The robustness argument is the **rotation-rate squeeze.** VIGIL runs the classic
identity detector (which catches any identity persisting > ~3–5 min) *and* the
churn detector (which catches sustained novel-churn above ~0.5–1/min)
simultaneously:

```
rotation period:  30 s ─── 2 min ─── 5 min ──────────── 24 h
                  └ churn path catches ┘
                          └ overlap ┘
                                └────── identity path catches ──────┘
```

**No rotation period evades both.** Fast rotation is caught by churn; slow rotation
by identity; the middle by both. Moreover the presence-continuity path is
rotation-*rate*-agnostic — slowing rotation lowers `λ_novel` but does nothing to
the unbroken coherent co-moving track. The adversary's only real lever is
*continuity*, not rate.

### 5.5 False positives

The engine's viability rests on dense-urban and transit false positives. Four
discriminators, strongest first: (1) the **seamless-handover chain** — a crowd is
many radios and cannot fake one continuous `(t, rssi)` track across 500 m; (2)
**co-movement across turnover** — bounded ambient dwell means a presence spanning
≥ 3 non-adjacent cells is not any single source; (3) **RSSI coherence** — one
radio yields a smooth RSSI random-walk, a crowd a high-variance cloud; (4)
**stationary suppression** — no motion, no alarm, which removes the entire
apartment/at-home class. The genuinely hard case is **live rush-hour transit**,
where boarding churn, vehicular co-movement, and continuous occupancy align. The
resolution is a **mode-change gate**: a transit crowd cannot follow the victim
*off the train and down the street*, so escalation to a hard alert is withheld
until the coherent co-moving presence survives a detected context transition. This
trades **latency** for transit-FP suppression — a deliberate, disclosed choice,
not a false alarm.

### 5.6 The honest floor

Every evasion degrades the adversary's own tracker (slower/duty-cycled rotation
and reduced TX power mean fewer, coarser location fixes). Below some duty cycle — a
few randomly-timed, random-power beacons per 15 min — the emitter becomes
information-theoretically indistinguishable, *within a single session*, from sparse
ambient pass-bys, and detection must move to **cross-session recurrence** (the same
anomalous weakly-co-moving presence recurring day after day along the victim's
routes), which costs **days of latency** and requires opt-in persistent storage.
This is the honest floor: a patient, low-duty-cycle adaptive adversary forces
VIGIL from minutes-latency single-session detection to days-latency multi-session
detection. VIGIL states this rather than claiming an impossible guarantee.

---

## 6. Implementation

VIGIL is a native Android/Kotlin app (min SDK 26), reusing the scanning and
service architecture of OVERWATCH.

```
scan/TrackerSignatures.kt   BLE hex signatures for every ecosystem
scan/TrackerParser.kt       ScanResult -> TrackerObservation (five wire formats)
scan/BleTrackerScanner.kt   hardware-filtered scan (screen-off capable)
service/ScanService.kt      foreground service; geotags, persists, alerts, vibrates
data/db/VigilDatabase.kt    Room: trackers, 14-day sightings, baseline places
data/TrackerRepository.kt   ingest + baseline + evaluate on each sighting
detect/CoMovementEvaluator  the co-movement test + RSSI proximity gate
detect/BaselineManager.kt   anchor-place learning -> auto-trust household tags
detect/PresenceEngine.kt    (next) the rotation-clone engine of §5
```

**Privacy properties.** The manifest declares **no `INTERNET` permission**; VIGIL
cannot open a socket. All state — trackers, sightings, baseline, inference — lives
in an on-device SQLite database and never leaves the phone. `BLUETOOTH_SCAN` is
declared *without* `neverForLocation`, because detection is intentionally
location-correlated (and because that flag would filter out the very beacon-shaped
advertisements VIGIL parses). VIGIL only listens: it never advertises, probes, or
connects to a tracker on the detection path.

---

## 7. Proposed evaluation

VIGIL is a prototype; the following methodology is specified but **not yet
executed**, and no detection-rate claims are made here.

- **Red-team emitter.** A parameterised OpenHaystack/*Find You* ESP32 clone with
  sweepable rotation period (30 s … 24 h), TX-power variance, and duty cycle. Carried,
  it is a real co-moving emitter — ground-truth positive without endangering anyone.
- **Ambient baselines.** Raw sighting logs across environment classes (rural drive,
  suburban, dense-urban walk, bus, rush-hour subway, highway, apartment block,
  crowd), each with paired emitter-on/off runs.
- **Record/replay harness.** The presence engine is a pure
  `List<Sighting> → List<ScoredEvent>` function; ambient logs are recorded once and
  replayed to tune thresholds deterministically and offline in Kotlin, and
  attack-in-context scenarios are synthesised by merging clean and emitter-only
  traces.
- **Metrics.** True-positive rate at a fixed false-positive budget (headline:
  TPR at ≤ 1 FP per active-carry-day, per class); detection latency
  (attach → first alert); ROC/AUC; robustness curves versus rotation period, TX
  power, and duty cycle; and ablations isolating each discriminator.

---

## 8. Comparison to prior art

| Capability | Apple Tracker Detect | iOS / Android built-in | AirGuard | **VIGIL** |
|---|---|---|---|---|
| Cross-ecosystem | Find My only | AirTag + FMDN + DULT partners (not Tile) | yes | yes |
| Background / automatic | no (manual scan) | yes | yes | yes |
| Fully on-device / no account | yes | yes | yes | **yes (no network permission)** |
| RSSI proximity gate on alerts | no | undisclosed | **no** | **yes** |
| Learned baseline (auto-trust) | no | no | manual ignore only | **yes** |
| Detects rotating-key clones | no | no | no | **designed (§5)** |
| Covers Tile anti-theft | no | no | yes (static MAC) | yes |
| Survivor-grade evidence export | no | no | limited | roadmap |

Cross-ecosystem, offline operation, and temporal co-movement are *not* novel —
AirGuard has them. VIGIL differentiates on the pieces AirGuard's architecture
forecloses: the RSSI gate, the learned baseline, and above all the identity-agnostic
presence engine that targets the clone attack.

---

## 9. Privacy and ethics

VIGIL is a defensive, survivor-oriented tool. It maps and reasons about
*trackers*, never about people, and holds no network to which anything could be
exfiltrated. The learned baseline is a privacy *feature* — it exists so the app
does not need to phone home to know which tags are "normal." The dual-use surface
(BLE parsing that could in principle be repurposed for tracking) is mitigated by
the passive-only, no-transmit, no-network design. As with all anti-stalking tools,
VIGIL should be paired with survivor-safety guidance: a detected tracker can
indicate an abuser with physical access, and "make it ring / remove the battery"
advice must be given with situational-safety caveats.

---

## 10. Limitations

- **Single-session floor (§5.6).** A patient low-duty-cycle adaptive adversary is
  only detectable across sessions.
- **Near-owner and freshly-separated tags** are not passively re-linkable (Apple
  near-owner; default FMDN before the `0x41` flip; Samsung in the first 24 h).
- **Wire-format offsets** are drawn from published reverse-engineering and, for
  SmartTag2 and 2024+ Tile, inferred from older captures; they require empirical
  validation before production trust.
- **Background scan latency** is bounded by Android's ~15-min background floor
  absent a persistent foreground service; motion-triggered scanning (roadmap)
  reduces it.
- **Not yet evaluated.** §7 is a plan, not a result.

---

## 11. Related work

Heinrich et al. reverse-engineered Apple Find My ("Who Can Find My Devices?", PETS
2021) and built AirGuard ("Protecting Android Users from Stalking Attacks by Apple
Find My Devices", WiSec 2022), later measuring real-world stalking prevalence and
detector efficacy ("Please Unstalk Me", PETS 2024). Mayberry/Shafqat et al.
("Who Tracks the Trackers?" / "Track You", PETS 2023) analysed AirTag anti-stalking
timing. Yu et al. (USENIX Security 2024) reverse-engineered Samsung SmartTag, and
Georgia Tech (2025) analysed Tile's static-MAC linkability. Bräunlein/Positive
Security demonstrated the rotating-key clone ("Find You"). Naturalistic evaluations
("Stop Following Me!", EuroUSEC 2024) found deployed detectors rarely useful. The
Apple/Google **DULT** IETF effort standardises the separated-state signalling and a
baseline detection algorithm. VIGIL builds directly on this line and extends it to
the identity-rotating adversary that all of it currently misses. Change-point
detection (Page 1954; Basseville & Nikiforov 1993) and bounded-memory distinct
counting (Datar et al.; Flajolet et al.) underpin the presence engine; the
identity-free "sustained close presence" reasoning is anticipated by
contact-tracing designs (DP-3T; Google/Apple Exposure Notification).

---

## 12. Conclusion

The anti-stalking detectors people rely on are spatial where the threat is
temporal, and identity-bound where the adversary can rotate identities. VIGIL
reframes detection as temporal co-movement, adds the proximity gate and learned
baseline that make that reframing practical on-device and private, and introduces
a presence engine that detects the rotating-key clone by the one property it cannot
hide. The rotation-rate squeeze shows the combination leaves no safe rotation rate;
the honest floor shows where even this stops. We release VIGIL as a working
prototype and an open design, and invite the empirical evaluation §7 lays out.

---

## References

1. A. Heinrich, M. Stute, T. Kornhuber, M. Hollick. "Who Can Find My Devices? Security and Privacy of Apple's Crowd-Sourced Bluetooth Location Tracking System." *PoPETs* 2021. https://petsymposium.org/popets/2021/popets-2021-0045.pdf
2. A. Heinrich, N. Bittner, M. Hollick. "AirGuard — Protecting Android Users from Stalking Attacks by Apple Find My Devices." *ACM WiSec* 2022. https://arxiv.org/pdf/2202.11813 · code: https://github.com/seemoo-lab/AirGuard
3. A. Heinrich, L. Würsching, M. Hollick. "Please Unstalk Me: Understanding Stalking with Bluetooth Trackers and Democratizing Anti-Stalking Protection." *PoPETs* 2024. https://petsymposium.org/popets/2024/popets-2024-0082.pdf
4. N. Shafqat et al. "Track You: A Deep Dive into Safety Alerts for Apple AirTags." *PoPETs* 2023. https://petsymposium.org/popets/2023/popets-2023-0102.pdf
5. T. Yu et al. "Analyzing the Security of Samsung SmartTag." *USENIX Security* 2024. https://arxiv.org/pdf/2210.14702
6. Kumar, Raymaker, Specter. Tile protocol analysis. 2025. https://arxiv.org/html/2510.00350v1
7. F. Bräunlein / Positive Security. "Find You: Building a stealth AirTag clone." https://positive.security/blog/find-you · https://github.com/positive-security/find-you
8. A. Catley. "AirTag reverse engineering." https://adamcatley.com/AirTag.html
9. IETF DULT WG. "Detecting Unwanted Location Trackers" (accessory-protocol; threat-model). https://datatracker.ietf.org/wg/dult/
10. Google. "Find My Device network (Fast Pair FMDN) specification." https://developers.google.com/nearby/fast-pair/specifications/extensions/fmdn
11. SEEMOO-Lab. "OpenHaystack." https://github.com/seemoo-lab/openhaystack
12. "Stop Following Me! Evaluating the Effectiveness of Anti-Stalking Features." *EuroUSEC* 2024. https://arxiv.org/abs/2312.07157
13. E. S. Page. "Continuous Inspection Schemes." *Biometrika* 41, 1954. (CUSUM.)
14. M. Basseville, I. Nikiforov. *Detection of Abrupt Changes: Theory and Application.* 1993.
15. M. Datar, A. Gionis, P. Indyk, R. Motwani. "Maintaining Stream Statistics over Sliding Windows." *SODA* 2002.

*This working paper accompanies the VIGIL reference implementation. The rotation-clone
engine (§5) is fully specified in `docs/detection-rotation-clone.md` and is designed
but not yet wired into the shipping build.*