Spike, and openly the lowest-priority thing in this repository. Nobody has asked for it. It is recorded because it is a real asymmetry in what this app does, and because somebody curious might want it.
The asymmetry
Every location this app shows was uploaded by a stranger's iPhone. An AirTag has no network of its own: it broadcasts a rotating public key over BLE, some passing Apple device hears it, works out where it is, encrypts that to the tag's key and hands it to Apple. This app reads those reports.
It has never produced one. Every OpenTagViewer user takes from the Find My network and gives nothing back. That is not a bug — the app had no Bluetooth at all until recently — but it is worth being honest that "we depend entirely on other people's phones doing the thing we don't do".
@ubrt's local Bluetooth scanning (#48, #139) changes the prerequisite: once the app can hear offline-finding advertisements at all, the radio half of this is largely solved. It listens for your tags today. Hearing everyone else's is the same listening.
What is already known
More than for #166, because the report format is not a mystery — FindMy.py already decrypts these reports, and encryption is the same construction run the other way:
- the advertisement carries a rotating P-224 public key, reassembled from the manufacturer-data payload
- a finder derives a shared secret against it with an ephemeral key, and encrypts its own position under that
- the tag's owner, holding the private key, is the only party who can read it — including Apple, who cannot
So the parts this project would have to invent are the ones around the crypto, not the crypto.
It is almost certainly zero-knowledge, which is what makes it tractable
A finder needs two things and no third: the BLE advertisement, and Apple's endpoint.
It does not know whose tag it heard. It cannot know — the advertised key rotates, and resolving it to an owner requires the private key, which only the owner has. It encrypts its own position to the tag's key, so the party it is reporting to is the owner and nobody else. Apple stores the result opaquely and cannot read it either.
So there is no identity to establish and nothing to be trusted with. That is the strong reason to expect this is buildable: unlike registering a tag (#166), there is no obvious place for Apple to require an attestation, because there is nothing a finder is being trusted with.
What is missing
- The submit endpoint. FindMy.py fetches; nothing here has ever posted a report. Its URL, payload shape and error behaviour are unknown to this project.
- What, if anything, authenticates a submission. Per the above, likely little — but "likely" is doing work in that sentence, and it may still want Anisette headers or a device identity for anti-abuse rather than for trust. This is the question that decides how much work the rest is.
- Whether Apple accepts one at all from a client that is not an Apple device, and what rate limits or plausibility checks apply. A server that silently discards reports from unknown clients looks identical to success — so the spike needs a way to confirm a submitted report comes back out of a fetch, which is straightforward here: submit for your own tag and then fetch it.
- What a report must contain to be useful — position, accuracy, timestamp, status byte, and how much of that is checked.
Unknown 3 has a clean test, and it should be the first thing done: place your own tag, hear it on the Android device, submit a report for it, then fetch that report back through the existing path. Round-tripping through Apple is the only evidence that means anything.
Before any of that: should it be built?
Less alarming than it first looks, but not nothing.
What actually leaks, precisely
Not the user's location to Apple — the position is encrypted to the tag's key before it is submitted. What Apple gets is an IP address submitting reports for particular key hashes at particular times, which over enough submissions is a movement trace by IP even without a single decrypted coordinate.
The larger and more often forgotten exposure is the other direction: the tag's owner learns the finder's precise position, because that is literally the report. That is inherent to the design and equally true of every iPhone that has ever done this. It is worth stating on the toggle rather than in a changelog.
So if this is built:
- opt-in, off by default, with the trade stated plainly
- never folded into a "background scanning" setting that sounds like it is only about the user's own tags
- and if unknown 2 turns out to need a signed-in account after all, that changes the analysis completely and should be re-decided rather than shipped
It is other people's tags
A report is data about somebody else's property, and in the stalking case, about somebody being tracked without consent. Apple's network has anti-stalking machinery layered on top of it. A third-party contributor that helps locate tags while implementing none of that is not automatically a net good — though it is also no worse than the iPhones already doing it, which is the honest counter-argument.
It probably sits outside Apple's terms
Reading your own account's data is defensible. Volunteering into the crowd-sourced network as a non-Apple client is a different argument, and a weaker one.
What a spike would produce
Same shape as the other spikes: a document, not code.
- Answers to the four unknowns above, with
[observed] marking anything actually seen on the wire rather than reasoned about
- A recommendation on the privacy question, informed by what unknown 2 turns out to require
- If it is worth building, it goes upstream to FindMy.py like everything else protocol-shaped — this app is a consumer, not the place for it
A negative — "submission requires an authenticated Apple device identity after all, so every report is attributable and this should not be built" — is a perfectly good outcome and closes the question.
Honest expected value
Roughly zero for users, and that is not false modesty: nobody gains a feature, no issue is closed, and no report gets better. What it buys is the project no longer being a pure consumer of something it depends on, which matters to some people and not to others.
It is genuinely last. Ahead of it are #166 (registering a tag without an iPhone), #131 (locating the owner's own devices properly) and everything already open. Anyone who wants to pick it up should feel free; nobody should feel it is owed.
Written up by Claude Code from a conversation with @parawanderer.
Spike, and openly the lowest-priority thing in this repository. Nobody has asked for it. It is recorded because it is a real asymmetry in what this app does, and because somebody curious might want it.
The asymmetry
Every location this app shows was uploaded by a stranger's iPhone. An AirTag has no network of its own: it broadcasts a rotating public key over BLE, some passing Apple device hears it, works out where it is, encrypts that to the tag's key and hands it to Apple. This app reads those reports.
It has never produced one. Every OpenTagViewer user takes from the Find My network and gives nothing back. That is not a bug — the app had no Bluetooth at all until recently — but it is worth being honest that "we depend entirely on other people's phones doing the thing we don't do".
@ubrt's local Bluetooth scanning (#48, #139) changes the prerequisite: once the app can hear offline-finding advertisements at all, the radio half of this is largely solved. It listens for your tags today. Hearing everyone else's is the same listening.
What is already known
More than for #166, because the report format is not a mystery — FindMy.py already decrypts these reports, and encryption is the same construction run the other way:
So the parts this project would have to invent are the ones around the crypto, not the crypto.
It is almost certainly zero-knowledge, which is what makes it tractable
A finder needs two things and no third: the BLE advertisement, and Apple's endpoint.
It does not know whose tag it heard. It cannot know — the advertised key rotates, and resolving it to an owner requires the private key, which only the owner has. It encrypts its own position to the tag's key, so the party it is reporting to is the owner and nobody else. Apple stores the result opaquely and cannot read it either.
So there is no identity to establish and nothing to be trusted with. That is the strong reason to expect this is buildable: unlike registering a tag (#166), there is no obvious place for Apple to require an attestation, because there is nothing a finder is being trusted with.
What is missing
Unknown 3 has a clean test, and it should be the first thing done: place your own tag, hear it on the Android device, submit a report for it, then fetch that report back through the existing path. Round-tripping through Apple is the only evidence that means anything.
Before any of that: should it be built?
Less alarming than it first looks, but not nothing.
What actually leaks, precisely
Not the user's location to Apple — the position is encrypted to the tag's key before it is submitted. What Apple gets is an IP address submitting reports for particular key hashes at particular times, which over enough submissions is a movement trace by IP even without a single decrypted coordinate.
The larger and more often forgotten exposure is the other direction: the tag's owner learns the finder's precise position, because that is literally the report. That is inherent to the design and equally true of every iPhone that has ever done this. It is worth stating on the toggle rather than in a changelog.
So if this is built:
It is other people's tags
A report is data about somebody else's property, and in the stalking case, about somebody being tracked without consent. Apple's network has anti-stalking machinery layered on top of it. A third-party contributor that helps locate tags while implementing none of that is not automatically a net good — though it is also no worse than the iPhones already doing it, which is the honest counter-argument.
It probably sits outside Apple's terms
Reading your own account's data is defensible. Volunteering into the crowd-sourced network as a non-Apple client is a different argument, and a weaker one.
What a spike would produce
Same shape as the other spikes: a document, not code.
[observed]marking anything actually seen on the wire rather than reasoned aboutA negative — "submission requires an authenticated Apple device identity after all, so every report is attributable and this should not be built" — is a perfectly good outcome and closes the question.
Honest expected value
Roughly zero for users, and that is not false modesty: nobody gains a feature, no issue is closed, and no report gets better. What it buys is the project no longer being a pure consumer of something it depends on, which matters to some people and not to others.
It is genuinely last. Ahead of it are #166 (registering a tag without an iPhone), #131 (locating the owner's own devices properly) and everything already open. Anyone who wants to pick it up should feel free; nobody should feel it is owed.
Written up by Claude Code from a conversation with @parawanderer.