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
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
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:
mmeFMIPTokenmmeFMIPAppTokenmmeFMIPSiriTokenSee
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:
those already — see rule 11 in
AGENTS.md, and note that whatever this sends has to be thesame device identity, not a second one)
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:
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
mmeFMIP*tokens, already returned and already unusedsecureLocationsSharedSecretis the iDevice's secondary secretstableIdentifierholds the hardware serialWhere the app draws the line today
BeaconInformation.isOwnDevice()— the classifier, two signals, mirroringopentagviewer_export.hardware.is_own_deviceTagVisibility— one rule deciding both what is shown and what is searched forUserSettings.showAppleDevices— the setting, off by defaultA 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