Skip to content

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

Closed
parawanderer wants to merge 1 commit into
mainfrom
docs/the-503-was-never-ours
Closed

parawanderer wants to merge 1 commit into
mainfrom
docs/the-503-was-never-ours

Conversation

@parawanderer

Copy link
Copy Markdown
Owner

Four places — AGENTS.md rule 11, both identity.py docstrings, and AdiDeviceIdentity.LEGACY_SERIAL — named the shared constant serial as the leading suspect for #168, #176 and #181, and called the per-install serial the cheap way to confirm it. All of that was written before anyone tested it.

It was tested today against an account Apple was actively refusing, and eliminated in stages. Each of these was refused with 503:

Varied Result
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 — no serial parameter at all, sends X-Apple-I-SRL-NO: 0 503

Three independent implementations reported it within days:

Our reports start 2026-08-29, ahead of upstream's, which fits a gradual rollout rather than a separate cause.

The per-install serial stays. One serial arriving from thousands of installs against thousands of machine identities is a shape no real hardware produces, and that argument never rested on the 503s. What goes is the claim that it fixes them — stated explicitly in each file, so the next reader does not re-derive the hypothesis from the paragraph above it.

What this project can actually do is rule 15: say plainly that Apple declined and stop sending people to the bug tracker. That shipped in #177.

Interactively co-authored by Claude Code and @parawanderer

`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.
@parawanderer

Copy link
Copy Markdown
Owner Author

Superseded by #194. This branch corrected the serial claim but replaced it with a different wrong conclusion — that the 503s were an unfixable Apple-side change. They were Apple refusing the com.apple.dt.Xcode client identifier, which is fixed in #194 along with the same corrections, stated accurately this time.

Drafted by Claude Code

@parawanderer
parawanderer deleted the docs/the-503-was-never-ours branch September 13, 2026 14:36

This branch was successfully deployed

1 active deployment
Android Build — f053387f Deployed Sep 13, 2026 by parawanderer via build #241
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant