Skip to content

Locate the owner's own Apple devices properly, via the Find My iPhone service #131

Description

@parawanderer

The app can already find the owner's own iPhones, iPads and Macs — they sit in the Find My
zone alongside the tags, they carry key material, and FindMy.py locates them the same way it
locates an AirTag. What it cannot do is keep them up to date, and that gap is invisible from
the outside.

Why a device in this app looks broken when it isn't

An AirTag has no network of its own. It broadcasts a rolling public key over Bluetooth, some
passing iPhone hears it, and that stranger's phone uploads an encrypted report. Reading those
reports is what this app does, and for a tag it is the only mechanism — so this app and
Apple's own app are doing the same thing and get the same answer.

A phone is not like that. It has a network connection, and it reports its own position to iCloud
directly and continuously. Apple's Find My app reads that. The crowd-sourced beacon path still
exists for a device — which is why one shows up here at all — but it only produces a report when
the device is broadcasting and a stranger walks past, which for something in the owner's pocket
is rare and arbitrary.

So a device shown in this app updates hours or days late, or not at all, while the real Find My
app has it live. Users read that as "your app is broken", and there is no way to tell from
the screen that it isn't.

Because of that, the owner's own devices are hidden by default as of the "Show my Apple
devices" setting, which says plainly what turning them on gets you. This issue is about closing
the gap for real.

What implementing it actually means

Speaking the Find My iPhone service, which is a different Apple service from the search-party
one this project is built on.

The tokens are already in hand. The MobileMe delegate response — Stage 2, which the app
already performs on every sign-in — returns eleven service tokens, and three of them are the
Find My iPhone family:

Token
mmeFMIPToken service
mmeFMIPAppToken application
mmeFMIPSiriToken Siri

See docs/findmy-export/02-mobileme-delegate.md §5 — Tokens.
The spec's advice there was to keep all of them rather than guess which a later stage wants;
this is the later stage. Nothing in the app reads any of the three today.

What is not established anywhere in the spec, and is the actual research work:

  • Which of the three variants the device-location endpoint wants
  • The endpoint itself, its request shape, and how a device list comes back
  • Whether it needs the same Anisette / device-identity headers as Stage 1 and 2 (the app has
    those already — see rule 11 in AGENTS.md, and note that whatever this sends has to be the
    same device identity, not a second one)
  • Whether refreshing a device's location is a separate call from listing devices, and what
    rate limits apply

That last point matters more here than for tags: this is a service that can make somebody's
phone play a sound.

The hard constraint: this only ever works for a linked account

It cannot go in an export. A bundle is a set of beacon keys — the recipient locates a tag by
reading crowd-sourced reports with those keys, needing nothing from the owner's account. A
device's live position is not derivable from key material at all; it lives in the owner's iCloud
account and comes back only to someone authenticated as them.

So:

  • Signed-in account → possible, for that person's own devices
  • Exporter-only install (someone handed a zip, no Apple account) → not possible, ever

That asymmetry should be visible in whatever UI this produces. Anyone who imported a zip must
not be shown a feature that cannot work for them.

There is also a privacy line already drawn in the spec that this sits next to. Devices carry
private keys, so they can be written into a bundle — and
§5.1 / "So an export can contain the owner's phone"
argues at length that they should never be in one handed to somebody else, because a zip is a
set of keys and the recipient can follow whatever is in it for as long as they stay valid. That
argument is unaffected by this issue and should not be weakened by it: making the owner's phone
locatable by the owner is the feature; making it locatable by a zip recipient is not.

Relevant spec sections

Section For
02-mobileme-delegate §5 — Tokens the mmeFMIP* tokens, already returned and already unused
02-mobileme-delegate §5.1 — Lifetime and refresh ~weekly token lifetime, and the chain needed to renew one
06-output §2.3 — secureLocationsSharedSecret is the iDevice's secondary secret how a device is told apart from an accessory in the first place
06-output §2.4 — stableIdentifier holds the hardware serial the serial, likely how a beacon record is matched to a device the FMIP service lists
01-authentication §2.2 the client identity any Apple service call has to present consistently

Where the app draws the line today

  • BeaconInformation.isOwnDevice() — the classifier, two signals, mirroring
    opentagviewer_export.hardware.is_own_device
  • TagVisibility — one rule deciding both what is shown and what is searched for
  • UserSettings.showAppleDevices — the setting, off by default

A device is currently not merely hidden, it is not fetched at all, precisely because the
crowd-sourced search costs a slot in the batch and almost never returns anything for one. Any
implementation of this issue will want to revisit that: with a real service behind it, a device
becomes worth asking about again — just through a different call.


🤖 Written by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    @appIssues regarding the OpenTagViewer Android appenhancementNew feature or requesthelp wantedExtra attention is needed

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions