The 503s were never ours, and four files said otherwise

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

app/src/main/java/dev/wander/android/opentagviewer/anisette/AdiDeviceIdentity.java

@@ -109,13 +109,23 @@ public AdiDeviceIdentity(String uniqueDeviceIdentifier, String adiIdentifier,
      * <p><b>Why this stopped being the only one.</b> It was a constant, so every install of this
      * app anywhere presented Apple the same serial while presenting a <i>different</i> 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.
      *
-     * <p>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.
+     * <p><b>It does not explain the 503s, and this file used to claim it did.</b> 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.
+     *
+     * <p>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.
+     *
+     * <p><b>So do not tell an affected user a new serial will help them</b>, 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";
 

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

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