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. """