From f053387fded188d587a4bcc6dd165b4ab55e64cf Mon Sep 17 00:00:00 2001 From: "Shane B." Date: Sun, 13 Sep 2026 14:59:01 +0200 Subject: [PATCH] The 503s were never ours, and four files said otherwise `AGENTS.md` rule 11, both `identity.py` docstrings and `AdiDeviceIdentity.LEGACY_SERIAL` all named the shared constant serial as the leading suspect for #168, #176 and #181, and described drawing a serial per install as the cheap way to confirm it. That was written before anybody tested it. It was tested on 2026-09-13, against an account Apple was actively refusing, and eliminated in stages. Every one of these was refused with 503: | Varied | Result | | --- | --- | | A freshly drawn serial instead of the shared constant | 503 | | Fresh `uid` and `devid` | 503 | | Fresh ADI provisioning | 503 | | Three network locations, including the account's own country | 503 | | A second, unrelated Apple ID | 503 | | A second machine, different OS | 503 | | **Unmodified upstream FindMy.py**, which has no serial parameter and sends `0` | 503 | It is an Apple-side change hitting the whole class of client, and three independent implementations reported it within days of each other: `malmeloo/FindMy.py#268` ("Something changed on Apple's side, not sure what yet"), a Macless Haystack report on `seemoo-lab/openhaystack#63`, and `OpenBubbles/openbubbles-app#267`. Our own reports run from 2026-08-29, ahead of upstream's, which fits a gradual rollout rather than a different cause. The per-install serial is kept. One serial arriving from thousands of installs against thousands of machine identities is a shape no real hardware produces, and that argument never depended on the 503s. What is removed is the claim that it fixes them, and every file now says so explicitly so the hypothesis is not re-derived from the paragraph above it. What this project can actually do about it is rule 15 and `ICloudFailures`: say plainly that Apple declined, and stop sending people to the bug tracker over it. That shipped in #177. --- AGENTS.md | 20 +++++++++++---- .../anisette/AdiDeviceIdentity.java | 22 +++++++++++----- app/src/main/python/identity.py | 4 +-- python/exporter/identity.py | 25 +++++++++++++------ 4 files changed, 50 insertions(+), 21 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 44a57da7..19c183b6 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -258,11 +258,21 @@ Four things follow: leaves out the pairs a person comparing two screens would confuse. **Do not put it back to a constant.** It was one, and that meant a single serial arriving at Apple from thousands of installs, against thousands of different machine identities and Apple IDs, from every continent - at once — a shape no real hardware produces, and the leading suspect for the Grand Slam 503s in - [#168](https://github.com/parawanderer/OpenTagViewer/issues/168), - [#176](https://github.com/parawanderer/OpenTagViewer/issues/176) and - [#181](https://github.com/parawanderer/OpenTagViewer/issues/181), one of whom cleared their - device identity to no effect — which regenerates the ids and not the serial. + at once — a shape no real hardware produces, and worth not sending on that basis alone. +- **It does not fix the Grand Slam 503s, and this rule used to say it probably did.** That claim + was written into three files and a pull request before anyone tested it. On 2026-09-13 it was + tested against an account Apple was actively refusing and eliminated in stages: a drawn serial, + fresh `uid` and `devid`, fresh ADI provisioning, three network locations, a second unrelated + Apple ID, a second machine, and finally **unmodified upstream FindMy.py**, which has no serial + parameter at all and sends `X-Apple-I-SRL-NO: 0`. Every one was refused with 503. + + It is an Apple-side change hitting this whole class of client — + [malmeloo/FindMy.py#268](https://github.com/malmeloo/FindMy.py/issues/268), opened 2026-09-11 + ("Something changed on Apple's side, not sure what yet"), with a matching report against + OpenHaystack, which shares no code with either. **So do not tell a reporter that upgrading + helps**, and do not re-derive the hypothesis from the bullet above: it was reasonable, it was + tested, and it was wrong. `ICloudFailures` and rule 15 are what this project can actually do + about it — say plainly that Apple declined, and do not send anybody to the bug tracker. - **An install that already has one keeps it**, including the installs that predate this and have no stored serial at all: those keep `0PENTAGVIEWR` / `0PENTAGXPORT`. Neither of those can be drawn — both contain a letter the alphabet excludes — so a serial with an `I` or an `O` in it diff --git a/app/src/main/java/dev/wander/android/opentagviewer/anisette/AdiDeviceIdentity.java b/app/src/main/java/dev/wander/android/opentagviewer/anisette/AdiDeviceIdentity.java index 2c06350b..5880d90b 100644 --- a/app/src/main/java/dev/wander/android/opentagviewer/anisette/AdiDeviceIdentity.java +++ b/app/src/main/java/dev/wander/android/opentagviewer/anisette/AdiDeviceIdentity.java @@ -109,13 +109,23 @@ public AdiDeviceIdentity(String uniqueDeviceIdentifier, String adiIdentifier, *

Why this stopped being the only one. It was a constant, so every install of this * app anywhere presented Apple the same serial while presenting a different machine * identity: one serial against thousands of device ids and thousands of Apple IDs, from every - * continent, at once. Real hardware does not look like that. The 503s from Grand Slam that - * some accounts never recover from - issues #168, #176 and #181 - are consistent with that - * fingerprint being refused, and one reporter cleared their device identity to no effect, - * which is what would happen if the serial were the part being matched on. + * continent, at once. Real hardware does not look like that, and a fingerprint nothing real + * produces is worth not sending whether or not anything is matching on it. * - *

That is a hypothesis and is written down as one. It has not been confirmed against - * Apple, and the cheap way to confirm it is exactly this change. + *

It does not explain the 503s, and this file used to claim it did. Issues #168, + * #176 and #181 were attributed to it while this change was being written. On 2026-09-13 the + * hypothesis was tested against an account Apple was actively refusing and eliminated in + * stages - a drawn serial, fresh {@code uid} and {@code devid}, fresh ADI provisioning, three + * network locations, a second unrelated Apple ID, a second machine, and finally unmodified + * upstream FindMy.py, which cannot send a custom serial at all and sends + * {@code X-Apple-I-SRL-NO: 0}. Every one of them was refused. + * + *

It is an Apple-side change affecting this whole class of client - see + * {@code malmeloo/FindMy.py#268}, opened 2026-09-11, and the matching report against + * OpenHaystack, which shares no code with either. + * + *

So do not tell an affected user a new serial will help them, and do not re-derive + * the hypothesis from the paragraph above: it was reasonable, it was tested, and it was wrong. */ public static final String LEGACY_SERIAL = "0PENTAGVIEWR"; diff --git a/app/src/main/python/identity.py b/app/src/main/python/identity.py index c73763ef..f7b9040e 100644 --- a/app/src/main/python/identity.py +++ b/app/src/main/python/identity.py @@ -55,8 +55,8 @@ pinned equal by `IdentityBridgeTest`; a serial drawn per install cannot be pinned that way, and a second copy of it is exactly what rule 11 is about. `appSerial` asks. See `AdiDeviceIdentity.LEGACY_SERIAL` for why a constant was wrong: one serial against thousands of -machine identities and Apple IDs is not a shape real hardware produces, and it is the leading -suspect for the 503s in issues #168, #176 and #181. +machine identities and Apple IDs is not a shape real hardware produces. It is **not** the cause of +the 503s in #168, #176 and #181 - that was tested and eliminated; see the Java constant. **An install that has one keeps it**, which is why this value still goes out at all: an install from before the change has been presenting it, and drawing it a new serial now would register a diff --git a/python/exporter/identity.py b/python/exporter/identity.py index f8664b23..ef1c5a5b 100644 --- a/python/exporter/identity.py +++ b/python/exporter/identity.py @@ -64,14 +64,23 @@ **Why this stopped being the only one.** It was a constant, so every install of this program, everywhere, presented Apple the same serial while presenting a *different* machine identity: one serial against thousands of device IDs and thousands of Apple IDs, from every continent, at once. -Real hardware does not look like that. A 503 from Grand Slam that some accounts never recover from -- issues #168, #176 and #181 - is consistent with that fingerprint being refused, and one reporter -cleared their device identity to no effect, which is what would happen if the serial were the part -being matched on. - -That is a hypothesis and is written down as one. It has not been confirmed against Apple, and the -cheap way to confirm it is exactly this change: an affected user deleting their identity file now -draws a different serial instead of the same one. +Real hardware does not look like that, and a fingerprint nothing real produces is worth not +sending whether or not anything is currently matching on it. + +**It does not explain the 503s, and it was wrong to say it did.** Issues #168, #176 and #181 were +attributed to this while the change was being written. They are not it. On 2026-09-13 the +hypothesis was tested against an account Apple was actively refusing, and eliminated in stages: a +freshly drawn serial was refused, so were fresh `uid` and `devid`, so was fresh ADI provisioning, +so were three network locations, so was a second unrelated Apple ID, so was a second machine - and +so was **unmodified upstream FindMy.py**, which cannot send a custom serial at all and defaults to +`X-Apple-I-SRL-NO: 0`. + +It is an Apple-side change affecting this whole class of client: +`malmeloo/FindMy.py#268`, opened 2026-09-11 - "Something changed on Apple's side, not sure what +yet" - with a matching report against OpenHaystack, a separate implementation. + +So this change is kept on its own merits and claims nothing about the 503s. Do not tell an +affected user that a new serial will help them. """