Find My looks like a location-tracking problem and it is, but the interesting half is a paradox: you must locate a device that is offline - powered-off phone, an AirTag with no radio but Bluetooth, a laptop in a stranger’s bag - using a network of a billion other people’s devices, while guaranteeing that the company running the network can never see where any device is, and that the strangers doing the finding can never be identified or turned into a tracking tool. An online device reporting its own GPS is the easy case. The hard case is: a lost AirTag has no GPS, no cellular, no wifi - it can only whisper over Bluetooth. Someone else’s iPhone walks past, hears the whisper, knows its own location, and has to get that location back to the owner - without the passer-by learning what they found, without Apple learning who found what or where, and without a stalker being able to slip an AirTag into your bag and watch you on a map.

That single requirement - crowdsourced, offline finding with end-to-end encryption where the server is a blind relay of ciphertext it cannot read or link to a device - is the spine of this design. Everything hard hangs off it: how a device with no network broadcasts an identity that rotates so it cannot be tracked, how a stranger’s phone encrypts a location so only the owner can read it, how the owner queries for reports about a device whose identifiers keep changing, how the server stores and shards billions of opaque encrypted reports it cannot decrypt, and how you detect a hostile AirTag planted to stalk someone. Let me build it properly.

Functional Requirements (FR)

In scope:

  • Locate my online devices on a map. For a device that is powered on and has network (phone, laptop, iPad, Watch), show its current or last-known location, updated when it moves.
  • Locate my offline devices via the crowd. For a device that is offline or has no network of its own (AirTag, powered-down phone, laptop asleep in a bag), find it through other people’s nearby devices that overhear its Bluetooth beacon and report the location on its behalf.
  • End-to-end encryption. Locations are visible only to the owner. The server operator (Apple / Google) must be technically unable to read a device’s location or to link the stream of reports back to a specific device or person.
  • Actions on a found device. Play a sound, mark as lost (Lost Mode), display a message with a contact number on the lock screen, and remotely erase.
  • Anti-stalking protection. Detect an unknown tracker (someone else’s AirTag) that is traveling with you and alert you, and let you disable it.
  • Finder participation is anonymous and free. Any device in the network can act as a “finder” for any beacon, contributing a report, without the finder learning what it found or being identifiable from the report.

Explicitly out of scope (say this so you own the scope):

  • The maps / tiles / routing layer. Rendering the map, geocoding, turn-by-turn directions to the device are a CDN + maps-service concern, not this design.
  • The pairing / account system. Apple ID / Google account auth, device enrollment, and the initial Bluetooth pairing handshake are upstream. I consume “this device belongs to this iCloud account and here is the shared secret established at pairing” as a given.
  • Firmware and the BLE radio stack. How the chip broadcasts and how power is managed at the silicon level is hardware; I design the protocol and the backend.
  • Family sharing UI, item-sharing. Sharing an AirTag with family is a permissions layer on top; the core is single-owner finding.

The one decision that drives everything: this is a privacy-first, write-heavy system where the server is deliberately a dumb, blind store of encrypted location reports it cannot decrypt or attribute, and all intelligence - key rotation, encryption, matching reports to a device - lives on the owner’s and finder’s client devices. Unlike a normal location system where the server knows where everyone is and answers spatial queries, here the server knows nothing and merely relays ciphertext keyed by opaque, rotating identifiers. That inversion, not a spatial index, is the heart of the design.

Non-Functional Requirements (NFR)

  • Scale: ~2B devices in the finder network worldwide; ~1B findable devices (phones, laptops, tablets, watches, AirPods, AirTags). Hundreds of millions of devices are “away from owner” and being detected by strangers at any moment.
  • Latency: locating an online device should feel near-real-time (last-known within seconds to a minute). Offline finding is inherently not real-time - it depends on a stranger physically walking past - so a found location within minutes to a few hours is the realistic target, and the product promises “last seen” rather than “live.”
  • Availability: 99.9%+ on the report ingest and query path. A missed report is fine - another finder will produce another one. The system self-heals through redundancy of finders.
  • Consistency: eventual consistency everywhere. A location that is a few minutes stale is expected and acceptable. There is no transactional “assign one” operation and no strong-consistency requirement on the hot path. The one property that must hold absolutely is privacy/security: the server must never be able to decrypt a report or link reports to a device, and this is enforced by cryptography, not by policy.
  • Durability: encrypted reports are retained for a bounded window (~7 days) then deleted - long enough to find a lost item, short enough to limit the data at rest. Online devices’ last-known location is kept until overwritten. The device-to-owner shared secret is durable and lives only on the owner’s devices (synced through an end-to-end-encrypted keychain), never on the server in usable form.
  • Security threat model: the server is honest-but-curious at best and potentially compromised. Design so that a full database dump reveals nothing but undecryptable ciphertext keyed by random-looking hashes.

Back-of-the-Envelope Estimation (BoE)

Real numbers with the arithmetic, because they dictate the architecture.

The offline-finding report firehose (the number that defines this problem):

Findable devices currently "away from owner" and detectable by strangers
   ≈ 150,000,000 at any given time.
Each away-device is overheard by finders passing within BLE range
   (~10-30m). Out in the world, that is many finders per hour;
   with per-beacon upload throttling, assume ~40 reports/day/device.
Reports/day = 150,000,000 * 40 = 6,000,000,000 reports/day.
Reports/sec (avg) = 6e9 / 86,400 ≈ 70,000 reports/sec.
Peak (daytime, dense urban) ≈ 3x ≈ 200,000 reports/sec.

70K-200K encrypted writes/sec is the ingest firehose. It is smaller than a “live location” system because a beacon does not report itself - it depends on strangers walking by, and finders throttle uploads per beacon. The hard part is not raw volume; it is that every write is opaque ciphertext keyed by a rotating hash the server cannot interpret.

Online-device self-reporting (the lighter path):

Online devices reporting their own encrypted location, on significant
   location change ≈ every ~10-15 min while moving.
Online devices ≈ 800M; assume ~1/3 moving and reporting at once.
Writes/sec ≈ 270,000,000 / 900s ≈ 300,000 reports/sec.

Similar order of magnitude, but these are self-reports (device encrypts its own location to itself), not crowd reports.

Owner query load (reads):

Owners open Find My occasionally (lose something, check on a device).
Assume 1B findable devices, each queried ~a few times/day on average
   across owners actively looking => tens of millions of query bursts/day.
Each offline query must fetch reports for MANY rotating IDs:
   rotation period 15 min => 96 IDs/day; over a 7-day window
   => up to 96 * 7 = 672 id-hashes to look up per device query.
Batched into one request => one request, 672 point lookups server-side.
Read QPS is far below write QPS but each read fans into ~hundreds of KV gets.

Storage:

Report size: id_hash 32B + ECIES payload (~ephemeral pubkey 32B +
   ciphertext+tag ~50B) + timestamp 8B + finder confidence 4B
   ≈ 130B, round to ~250B with overhead/indexing.
Offline reports: ~100,000/sec avg * 250B = 25 MB/sec
   = 2.16 TB/day.  Retain 7 days => ~15 TB live.
Online last-known: 1B devices * ~300B (few recent points) ≈ 300 GB.
Ownership/beacon registry: 1B devices * ~1KB ≈ 1 TB.

Bandwidth:

Ingress reports: ~100K/sec (avg) * 250B ≈ 25 MB/sec inbound, edge-terminated.
Owner fetch egress: bursty; a full 7-day fetch is ~672 * 250B ≈ 170KB per device.

The takeaways: a 70K-200K writes/sec firehose of undecryptable ciphertext; a modest ~15TB of at-rest encrypted reports (small precisely because retention is short and the payload is tiny); a read path where one query fans into hundreds of point lookups by rotating hash; and a total absence of any spatial query on the server, because the server never knows a location. The design driver is the cryptographic protocol and the opaque-keyed report store, not storage volume or spatial indexing.

High-Level Design (HLD)

The architecture has three planes. A beacon/crypto plane that lives entirely on client devices: the lost device broadcasts rotating public keys over BLE, finders encrypt locations to those keys, owners derive the same keys to query and decrypt. A report plane: a blind key-value store of encrypted reports keyed by the SHA-256 of the rotating public key, plus an online-location store for devices reporting themselves. A control plane: device registration/ownership, Lost Mode state, remote actions, and anti-stalking - the only parts where the server holds meaningful (but minimal) metadata.

   OFFLINE FINDING (the hard path)

   ┌───────────────┐   BLE advert every ~2s          ┌──────────────────┐
   │  Lost AirTag   │ ─── public key P_i (rotates ──▶ │ Finder iPhone     │
   │  (no network)  │      every 15 min) ............ │ (stranger nearby) │
   └───────────────┘                                  └────────┬─────────┘
                                                               │ has GPS;
                                                               │ encrypts:
                                                               │ loc -> ECIES(P_i)
                                                               │ id  -> SHA256(P_i)
                                                               ▼
   ┌────────────────────────────────────────────────────────────────────┐
   │            Report Ingest (anonymous, authenticated finder)          │
   │   validates finder is a real device (anti-spam), STRIPS identity,   │
   │   writes {id_hash, ts, ECIES_blob} - cannot read the location       │
   └───────────────────────────────┬────────────────────────────────────┘
                                    │
   ┌────────────────────────────────▼───────────────────────────────────┐
   │   Encrypted Report Store  (sharded KV, key = id_hash = SHA256(P_i)) │
   │   partition by hash(id_hash); TTL 7 days; server holds only cipher  │
   └────────────────────────────────▲───────────────────────────────────┘
                                    │ fetch by id_hashes
   ┌───────────────┐  derives same  │                    ┌──────────────┐
   │ Owner's iPhone │  P_0..P_n from ├── POST /fetch ─────│ Find My app  │
   │ (has master    │  shared secret │   {id_hashes[]}    │  shows dot   │
   │  secret)       │  computes      │◀── ECIES_blobs ────│  on map      │
   │                │  SHA256(P_i)   │   decrypt locally   └──────────────┘
   └───────────────┘

   ONLINE FINDING (the easy path)                CONTROL PLANE
   ┌───────────────┐   self-report          ┌───────────────────────────┐
   │ Online device  │── ECIES(to self) ────▶ │ Ownership/Beacon registry │
   │ (phone/laptop) │   own encrypted loc    │ Lost Mode state, actions, │
   └───────────────┘        │                │ anti-stalking, push (APNs)│
                            ▼                └───────────────────────────┘
                   ┌──────────────────┐
                   │ Online-location   │
                   │ store (last-known,│
                   │ encrypted to self)│
                   └──────────────────┘

Offline finding flow (device is lost, no network):

  1. The lost device continuously broadcasts a BLE advertisement carrying its current rotating public key P_i (derived on-device from a shared secret and a time counter; rotates every ~15 min so the identifier is never static).
  2. A stranger’s device (a finder) in Bluetooth range overhears the advert. The finder has GPS/wifi, so it knows its own location. It encrypts that location to P_i using ECIES (elliptic-curve integrated encryption) and computes the report key id_hash = SHA256(P_i). The plaintext location never leaves the finder.
  3. The finder uploads {id_hash, timestamp, encrypted_blob} to Report Ingest, over an authenticated but unlinkable channel. Ingest confirms the finder is a genuine device (anti-spam) then discards all finder identity, storing only the opaque triple. The server cannot read the location and cannot tell which device the report is about.
  4. Later, the owner opens Find My. The owner’s phone holds the device’s shared secret, so it can re-derive every P_i for the past 7 days, compute each SHA256(P_i), and POST /fetch that list of hashes.
  5. The server returns all encrypted blobs stored under those hashes. The owner’s phone decrypts each locally with the corresponding private key, yielding the finder-observed locations and timestamps, and plots the most recent on the map.

Online finding flow (device has network):

  1. An online device periodically encrypts its own current location to its own public key and uploads it to the online-location store, keyed by the same rotating-hash scheme (or by an authenticated device channel). Same E2E property - the server stores ciphertext.
  2. The owner fetches and decrypts it. Because the device self-reports, this is fresh (seconds to minutes) and needs no crowd.

Control plane: registration binds a device’s beacon material to an owner account (storing only what is needed, never the usable secret in plaintext); Lost Mode, “play sound,” and “erase” are queued as commands delivered via push (APNs/FCM) when the device next has network; anti-stalking runs mostly on the client.

The key insight: the server is a blind relay - it ingests and returns encrypted reports keyed by rotating hashes it cannot interpret, and every meaningful operation (key derivation, encryption, decryption, matching reports to a device) happens on client devices. There is no spatial index and no plaintext location anywhere on the backend.

Component Deep Dive

The hard parts, naive-first then evolved: (1) the offline crowdsourced-finding protocol, (2) rotating keys and end-to-end encryption so the server stays blind, (3) storing and querying billions of opaque reports at scale, (4) anti-stalking and abuse prevention.

1. Offline finding through the crowd

Naive approach: the lost device broadcasts a fixed device ID; any finder uploads {device_id, its_own_lat, its_own_lng} to the server keyed by device_id; the owner queries the server by device_id and gets the locations. Simple, and it works functionally.

Where it breaks:

  • The server sees everyone’s location. Every report is plaintext {device_id, lat, lng}. Apple/Google would hold a real-time map of where a billion items - and by extension their owners - physically are. That is a catastrophic privacy and legal liability, and a single subpoena or breach exposes everyone.
  • A static ID is a stalking beacon. Because the device always advertises the same device_id, anyone with a Bluetooth sniffer can follow that ID around a city and track the owner, with no server access at all. Retailers, abusers, and governments can passively surveil.
  • Finders are exposed. The report ties a finder’s device to a location and time. The network becomes a way to track the good samaritans too.

Every one of these is fatal. The functional problem (get a location from a stranger to an owner) is easy; the entire difficulty is doing it while leaking nothing.

First evolution: encrypt the location so the server cannot read it. The finder encrypts {lat, lng} to a key only the owner holds, and uploads {device_id, ciphertext}. Now the server stores ciphertext - it cannot read locations. Better, but two holes remain: the server (and any BLE sniffer) still sees a static device_id, so linkage and stalking-by-sniffer are unsolved; and the server can still count and correlate all reports for a device even without reading them.

The answer: rotating cryptographic identifiers + end-to-end encryption + anonymous upload, so nothing is static, nothing is readable, and nothing is attributable. Three mechanisms together:

  • Rotating public keys as the broadcast identity. Instead of a fixed device_id, the device broadcasts a public key P_i that changes every ~15 minutes, derived deterministically from a shared secret (deep dive 2). A BLE sniffer sees a fresh random-looking key every 15 minutes and cannot link them, so it cannot follow you. The report key is SHA256(P_i), equally rotating, so the server cannot group a device’s reports either.
  • ECIES encryption to P_i. The finder generates an ephemeral key pair, does ECDH with P_i, derives an AES-GCM key, and encrypts its own location. Only the holder of the private key d_i matching P_i (the owner) can decrypt. The server and the finder-after-upload hold undecryptable ciphertext.
  • Anonymous, deduplicated upload. The finder authenticates as a genuine device (to stop spam) but the report carries no finder identity - the ingest layer authenticates then strips. Multiple finders may report the same beacon; that redundancy is the feature (it self-heals missed reports), and the owner dedups client-side.
FINDER (stranger's phone) overhears advert carrying P_i:
    my_loc = gps()                                  # never leaves this device
    eph_priv, eph_pub = ec_keygen()                 # fresh per report
    shared   = ecdh(eph_priv, P_i)
    aes_key  = kdf(shared)
    blob     = eph_pub || aes_gcm_encrypt(aes_key, my_loc || accuracy)
    id_hash  = sha256(P_i)
    upload({id_hash, ts, blob})                     # anonymous, authenticated device

SERVER: store[id_hash].append({ts, blob})           # cannot read blob or link id_hash

This is the crux: the crowd does the finding, but the protocol guarantees the server learns nothing (ciphertext under rotating keys), the sniffer learns nothing (rotating identity), and the finder retains nothing (encrypted to someone else). The redundancy of a billion finders makes it work despite any single finder being unreliable.

2. Rotating keys and staying in sync without communication

The magic requirement: the lost device (offline, no network, cannot talk to the owner) and the owner’s phone must independently produce the same sequence of key pairs (P_0,d_0), (P_1,d_1), ... so that (a) the device broadcasts P_i, and (b) the owner can later compute SHA256(P_i) to query and d_i to decrypt - with zero communication between them while lost.

Naive approach: a single shared static key pair. At pairing, device and owner agree on one key pair. Device broadcasts P; owner queries SHA256(P) and decrypts with d.

Where it breaks: P is static, so we are back to the stalking-beacon problem - a sniffer follows the constant P. And every report for the whole device lifetime lands under one hash, so the server can trivially count and correlate a device’s activity even without decrypting. Static anything defeats the privacy goal.

First evolution: independent random keys per interval, uploaded to the server. The device makes a new random key pair every 15 min and somehow tells the owner. But the device is offline - it cannot upload its new public keys to the owner. Dead end. This is exactly the constraint that makes the problem interesting: the two sides must derive the same rotating keys deterministically from a shared secret established at pairing, never communicating afterward.

The answer: deterministic key derivation from a shared seed plus a time counter, using EC point arithmetic so the owner can regenerate both the public key (to query) and the private key (to decrypt).

  • At pairing (device online, one time): device and owner establish a shared secret seed SK_0 and agree on the interval length (15 min) and an epoch start t_0. SK_0 is stored only on the owner’s devices, synced through an end-to-end-encrypted keychain - never uploaded to the server in usable form.
  • Symmetric ratchet for unlinkability. For interval i, both sides compute SK_i = KDF(SK_{i-1}) (a one-way hash ratchet). Knowing SK_i does not reveal SK_{i-1}, so a compromise at time i cannot retroactively link earlier intervals - forward secrecy for the identifier stream.
  • Deriving the interval key pair. From SK_i derive a scalar pair (u_i, v_i) = KDF(SK_i). Take a fixed base private key d (from pairing) and base public key P = d*G. The interval keys are:
Interval i:
    SK_i = KDF(SK_{i-1})                      # hash ratchet, one-way
    (u_i, v_i) = KDF("update" || SK_i)        # deterministic scalars
    d_i = u_i * d + v_i        (mod n)         # interval PRIVATE key
    P_i = u_i * P + v_i * G                    # interval PUBLIC key  = d_i * G

Because P_i = u_i*(d*G) + v_i*G = (u_i*d + v_i)*G = d_i*G, the point arithmetic keeps the pair valid. The crucial asymmetry: the offline device only needs the base public P and the scalars to compute P_i for broadcasting - it never needs the base private key d, so even if the AirTag is cracked open, d is not on it (the device holds P and the symmetric material to advance the ratchet and derive P_i; the private d that decrypts lives only with the owner). The owner, holding d, computes d_i to decrypt.

  • Owner query. To locate the device over the last 7 days, the owner advances the ratchet across all 96 * 7 = 672 intervals, computes each P_i and SHA256(P_i), and fetches all of them in one batched request. For each returned blob, the owner reconstructs d_i and decrypts.
  • Clock skew. The device’s real-time clock may drift. The owner queries a window of intervals around each timestamp (a few extra i on each side) so a slightly off device clock still matches. Cheap, since each extra interval is just one more hash to look up.
Scheme Sniffer can track? Server can link reports? Works offline? Notes
Static device ID yes yes (plaintext) yes no privacy at all
Static key pair yes (constant P) yes (one hash) yes encryption only, still trackable
Random keys uploaded no no NO (needs network) impossible for offline device
Ratchet-derived rotating keys no no yes the design - deterministic, no comms

The elegance: a shared seed plus a hash ratchet lets an offline device and its owner independently generate the same unlinkable sequence of rotating key pairs forever, with no communication, so the device broadcasts an identity no one can follow and the owner alone can reconstruct the keys to find and decrypt it.

3. Storing and querying billions of opaque reports

The report store must absorb ~100K writes/sec of {id_hash, ts, blob} and serve owner fetches that each ask for hundreds of id_hash values - where id_hash is a uniformly random 32-byte value the server cannot interpret and that never repeats across intervals.

Naive approach: a relational table reports(device_id, ts, lat, lng) indexed by device_id. This assumes a stable device_id and plaintext coordinates - both of which the privacy model forbids. There is no device_id on a report and no coordinates; there is only a rotating hash and a blob. A relational schema with secondary indexes on device_id/ts buys nothing here.

Where a naive store breaks even if we key by id_hash:

  • No range or spatial query is possible or wanted. The server cannot do “reports near X” (no plaintext location) nor “all reports for device D” (no stable key). Every access is an exact-match point lookup by a random id_hash. A B-tree secondary index is wasted; we want a hash-partitioned KV.
  • Write amplification and hot partitions. 100K/sec of inserts into an indexed relational table with WAL and replication is heavy for data that is deleted in 7 days. And id_hash values are uniformly random, so good news - they shard evenly - but only if we partition on the hash itself.
  • Fan-out reads. One owner query = up to 672 point gets. If those are 672 separate round-trips it is slow; they must be batched and parallelized across shards.

The answer: a horizontally sharded key-value / wide-column store keyed by id_hash, with TTL-based expiry, batched multi-get on the read path, and no secondary indexes.

  • Partition by hash(id_hash). Since id_hash = SHA256(P_i) is already uniform, sharding on it spreads the write firehose perfectly evenly across nodes - no hot shard, because consecutive intervals of the same device land on unrelated shards (that is the point of rotation).
  • Wide-column layout. id_hash is the partition key, ts the clustering key, so the (rare) case of multiple finders reporting the same interval collapses into one partition with several rows, read in one shot.
Table: location_reports          (Cassandra / DynamoDB-style KV)
  id_hash     BLOB(32)   PARTITION KEY     -- SHA256(P_i), uniform random
  ts          BIGINT     CLUSTERING KEY    -- finder observation time
  blob        BLOB       -- ECIES: ephemeral_pubkey || aes_gcm(loc,accuracy)
  confidence  SMALLINT   -- finder-reported location accuracy (meters)
  ttl         set to 7 days -> auto-expiry
  Query: multi-get over [id_hash_0 ... id_hash_671]  (batched, parallel)
  NO secondary index: every access is exact-match by partition key.
  • Batched, parallel multi-get. The owner sends all 672 hashes in one /fetch; the API layer scatters them to the owning shards (grouped by hash(id_hash)), gathers, and returns. Most hashes have zero rows (the device was not near a finder that interval) and return nothing - cheap negative lookups, accelerated by a per-shard bloom filter so absent hashes short-circuit without touching disk.
  • TTL expiry, not deletes. Retention is a hard 7 days; the store auto-expires rows (Cassandra TTL / Dynamo TTL / RocksDB compaction), so ingest never issues deletes and the dataset stays a bounded ~15TB rolling window.
  • Idempotent, dedup-tolerant writes. Two finders reporting the same (id_hash, ts) is fine - both rows are kept (they may have different accuracy); the owner dedups and picks the best-accuracy point after decrypting. No coordination between finders is needed.
  • Separate the online path. Self-reports from online devices go to an online-location store keyed by device (over an authenticated channel) holding just the last-known encrypted point, overwritten in place - a tiny, read-through-cached KV, since there is one current value per device, not a 7-day history.

Why NoSQL KV, emphatically, and never relational on the hot path: there is no join, no transaction, no range scan, no spatial query, and no stable entity key - only exact-match point access by a uniformly random hash, at high write volume, with automatic expiry. That is the textbook shape a hash-partitioned KV/wide-column store is built for, and the uniform key distribution makes sharding trivially even.

4. Anti-stalking and abuse prevention

The same network that finds your lost AirTag can be abused: drop an AirTag in someone’s bag and watch them on a map. And the ingest path invites spam - fake reports to pollute a target’s location or to probe the network. The design must resist both.

Naive approach: trust the client and the reports; detect stalking on the server by noticing one tracker following one person. But the server cannot do this - it has no plaintext locations and no stable device IDs by design, so it cannot see that “tracker T is co-located with person P over time.” The very privacy that protects everyone blinds the server to abuse. Detection therefore cannot be server-side.

Where naive breaks:

  • Server-side stalking detection is impossible given E2E encryption and rotating IDs - the server sees only unlinkable ciphertext.
  • Report spam - an attacker floods id_hashes or fabricates blobs. If any anonymous client can write unlimited reports, they can exhaust storage or, if they know a victim’s current P_i from sniffing, inject bogus locations.
  • Rotating IDs also hide a hostile tracker from its victim at the BLE layer - the whole point of rotation is that a nearby beacon looks different every 15 min, which is exactly what a stalker’s AirTag exploits.

The answer: client-side anti-stalking that watches for a persistent foreign beacon, a “separated” broadcast mode that makes stalkers detectable, and authenticated-but-anonymous rate-limited ingest.

  • Client-side “unknown tracker traveling with you.” Your phone continuously logs the BLE beacons it sees. A tracker that is separated from its owner switches to a distinct advertising mode (and rotates its key far more slowly, or advertises a “separated” flag), so your phone can recognize “the same foreign, owner-separated tracker has been near me across many locations and over time” and alert you - even though a normal, with-its-owner tracker stays private. This is a deliberate privacy/safety trade: a separated tracker is made more linkable specifically so victims and their phones can spot it.
  • Cross-platform detection. Because a stalker’s tracker might follow someone who does not use the same ecosystem, the “separated” advertisement follows an industry spec so both Apple and Google phones can detect an unknown tracker, and users can trigger it to play a sound or read its identifier to disable it.
  • Rate-limited, attested ingest. A finder must present a device-attestation token (proving it is genuine hardware, not a script) to upload, and ingest rate-limits per attested device and per source. The token authenticates that it is a real device without revealing which device is in the stored report - authentication and the stored payload are decoupled, so anonymity holds while spam is throttled.
  • Report validation without decryption. The server cannot check a blob’s contents, but it can enforce structural limits: fixed blob size, valid id_hash length, sane timestamp window, and per-id_hash write caps, so no attacker can balloon a single partition or backdate reports.
  • Owner-side dedup and outlier rejection. After decryption, the owner drops physically impossible jumps (a point 1000km from a cluster in the same minute) as likely spoofed or erroneous, and prefers clustered, high-accuracy, multi-finder-corroborated points.

The point: privacy blinds the server to abuse, so anti-stalking is pushed to the client (which can see the physical beacons), safety is bought by deliberately making a separated tracker more detectable, and ingest integrity is held by attested, rate-limited, structurally validated writes that never break the report’s anonymity.

API Design & Data Schema

Offline reports and fetches are the core APIs; online reporting and actions round it out. All location payloads are ciphertext; the server validates structure, never content.

Finder upload (anonymous, attested)

POST /api/v1/report
  headers: { device-attestation: <token proving genuine hardware> }
  body: {
    id_hash: "<base64 32B = SHA256(P_i)>",
    ts: 1753900000,
    blob: "<base64 ECIES: ephemeral_pubkey || aes_gcm(lat,lng,accuracy)>",
    confidence_m: 12
  }
  -> 202 Accepted            // finder identity is authenticated then discarded
  // rate-limited per attested device; structurally validated; blob opaque

Owner fetch (offline finding)

POST /api/v1/fetch
  auth: owner account + device ownership proof
  body: {
    id_hashes: ["<h0>", "<h1>", ... up to ~672 for a 7-day window],
  }
  -> { reports: [
        { id_hash:"<h_k>", ts:1753900012, blob:"<ECIES>", confidence_m:12 },
        ... only hashes that had reports ...
     ] }
  // server does a batched multi-get; owner decrypts each blob locally

Online device self-report and last-known

POST /api/v1/self-location          // online device reports its own encrypted loc
  auth: device channel
  body: { device_ref:"<opaque>", ts, blob:"<ECIES to self>" }
  -> 202

GET  /api/v1/device/{device_ref}/last-known
  -> { ts, blob:"<ECIES>", source:"self" | "crowd" }   // owner decrypts

Control plane (actions, Lost Mode, registration)

POST /api/v1/device/register
  body: { device_id, base_pubkey P, interval_s:900, epoch_t0 }
  // server stores ownership + PUBLIC beacon material only; never the secret

POST /api/v1/device/{id}/lost-mode   { enabled:true, message, contact }
POST /api/v1/device/{id}/play-sound
POST /api/v1/device/{id}/erase
  // queued as commands, delivered via APNs/FCM when device has network

Data stores - the right tool per plane

1. Encrypted report store - sharded KV / wide-column, keyed by id_hash, TTL 7 days. (Schema in deep dive 3.) The hot, high-write, blind store. No secondary index; partition on the uniform hash; bloom filters for negative lookups; auto-expiry.

2. Online-location store - KV, keyed by device, last-known only. One encrypted current point per online device, overwritten in place, read-through cached. Tiny and fast.

Table: online_location            (KV, key = device_ref)
  device_ref  BLOB   PARTITION KEY   -- opaque, per-device
  ts          BIGINT
  blob        BLOB                   -- ECIES to owner
  overwrite in place; short TTL if device goes quiet

3. Ownership / beacon registry - relational (or KV), by device_id. Slow-changing, authoritative binding of a device to an owner account, plus public beacon parameters (base public key, interval, epoch). Never stores the usable shared secret. Relational is fine here: low write rate, needs the account/device relationships and Lost Mode state, benefits from transactions on registration/transfer.

Table: devices                    (relational)
  device_id     BIGINT   PRIMARY KEY
  owner_id      BIGINT   INDEX
  base_pubkey   BLOB                 -- P (public only)
  interval_s    INT, epoch_t0 BIGINT
  lost_mode     BOOL, lost_message TEXT, lost_contact TEXT
  status        ENUM(active, lost, erased)
  updated_at    TIMESTAMP

4. Command queue - durable queue per device, delivered via push. Play-sound / erase / lost-mode commands wait until the device has network, then are pushed (APNs/FCM) and acknowledged.

5. Shared secret / keychain - client-only, E2E-synced. The SK_0 seed and base private key d live on the owner’s devices and sync via an end-to-end-encrypted keychain. The server never holds them in usable form - this is what makes the whole system undecryptable server-side.

Why NoSQL/KV on the hot report path and relational only for the small control plane: the report path has no relationships, no transactions, no joins, and no stable key - just uniform-hash point access at high write volume with TTL expiry, which is exactly what a hash-partitioned KV excels at. The control plane (ownership, Lost Mode, actions) is low-volume, relationship-rich, and benefits from transactions, so relational fits. The security-critical secrets sit on clients, off the server entirely.

Bottlenecks & Scaling

Where it breaks first, in order, and the fix for each:

1. The report ingest firehose. 70K-200K opaque writes/sec into a store that must also expire them. Fix: hash-partition the report store on the uniform id_hash so writes spread perfectly evenly (rotation guarantees no device concentrates on one shard), use an LSM-tree/wide-column engine tuned for write-heavy inserts, and rely on TTL/compaction for deletion so ingest never issues explicit deletes. Front ingest with a queue (Kafka) to absorb bursts and decouple validation from storage.

2. Owner query fan-out. One offline query expands to up to 672 point lookups, most of them misses. Fix: batched multi-get grouped by shard so it is a handful of parallel scatter-gather round-trips, not 672 serial ones; per-shard bloom filters so the many empty hashes return instantly without disk I/O; and cap the default lookback (e.g. 7 days) so the hash list stays bounded. Cache nothing on the server (values are one-shot and private); parallelism, not caching, is the lever.

3. Hot dense areas - stadiums, transit hubs. Thousands of finders all overhearing the same beacons produce redundant reports. Fix: finder-side per-beacon upload throttling (a finder uploads at most one report per beacon per rotation window), structural per-id_hash write caps at ingest so one partition cannot balloon, and accept redundancy as the self-healing feature it is - the owner dedups. Cell-level rate limits keep a crowd from turning into a write storm.

4. Report spam / abuse. Anonymous writes invite flooding and location poisoning. Fix: device attestation required to upload (genuine-hardware proof) with per-device and per-source rate limits, structural validation (fixed blob size, valid hash length, sane timestamp window), and owner-side outlier rejection of physically impossible points after decryption. Authentication is decoupled from the stored payload so throttling never breaks anonymity.

5. The server as a single point of privacy failure. A breach must reveal nothing. Fix: this is handled by design, not ops - the server holds only ciphertext under rotating hashes and never the secrets, so a full dump is undecryptable noise. Replicate the KV store across zones for availability; the confidentiality guarantee is cryptographic and survives compromise.

6. Key-derivation and clock skew mismatches. A device with a drifting clock advertises P_i for a different i than the owner expects, so the owner queries the wrong hashes and finds nothing. Fix: the owner queries a window of intervals around each timestamp (a few i on each side), which is just a few extra cheap hash lookups; devices resync their clock whenever they briefly get network; keep the interval (15 min) coarse enough that small drift stays within the queried window.

7. Offline-finding latency depends on finder density. In a rural area with few finders, a lost item may go hours without a report. Fix: there is no server fix - it is inherent to crowdsourcing. Mitigate by maximizing finder participation (every device in the ecosystem is a finder by default), by having the device advertise more aggressively when it detects separation, and by clearly surfacing “last seen” with a timestamp rather than promising live tracking. Density is the product’s real scaling axis.

8. Anti-stalking coverage across ecosystems. A tracker can follow someone who uses a different phone platform. Fix: adopt a cross-industry detection spec so a “separated” tracker is detectable by any modern phone, expose it in the OS, and let a detected tracker be made to play a sound and reveal a disable identifier. Safety here is a protocol/standards problem, solved by making separated trackers deliberately more linkable.

9. Global distribution and latency. A billion devices worldwide hitting one region is slow and fragile. Fix: run the ingest and report store per region, routing finders and owners to their nearest region; since a lost device and the finders near it are physically co-located, its reports naturally land in one region, and only a traveling owner querying from afar needs cross-region fan-out (a rare, cheap batched read). The stores are replicated within region; the stateless ingest/API tier scales horizontally behind the queue.

Wrap-Up

The trade-offs that define this design:

  • A blind server over a knowing one. We deliberately make the backend incapable of reading or linking any location - trading away every server-side spatial feature (no “devices near X,” no server-side stalking detection) for a hard cryptographic guarantee that a breach or subpoena yields only undecryptable ciphertext. All intelligence moves to the clients.
  • Rotating ratchet-derived keys over any static identifier. A shared seed plus a hash ratchet lets an offline device and its owner generate the same unlinkable key sequence with zero communication, so the device is untrackable by sniffers and unlinkable by the server, at the cost of the owner querying hundreds of rotating hashes per lookup.
  • Crowdsourced eventual finding over real-time tracking. An offline device is found only when a stranger walks by, so we promise “last seen,” not “live” - trading immediacy for the ability to find things with no radio of their own, and leaning on the redundancy of a billion finders to self-heal missed reports.
  • A hash-partitioned KV firehose over a relational spatial store. With no joins, no transactions, no stable key, and no plaintext location, the hot path is pure uniform-hash point access with TTL expiry, which shards perfectly evenly and needs no index - relational is reserved for the small ownership/actions control plane.
  • Client-side safety over server-side safety. Because privacy blinds the server to abuse, anti-stalking lives on the phone that can see the physical beacons, and safety is bought by deliberately making a separated tracker more detectable - a conscious privacy-for-safety trade.

One-line summary: an offline device broadcasts rotating, ratchet-derived public keys over Bluetooth; any nearby stranger’s phone encrypts its own location to that key and uploads an anonymous, opaque report keyed by the key’s hash; the server is a blind, hash-partitioned KV store that can neither read nor link those reports; and the owner alone re-derives the rotating keys to fetch and locally decrypt them - end-to-end-encrypted, unlinkable, crowdsourced finding where the only thing that must be perfect is that the server learns nothing.