The CAPTCHA is on the wrong door
I’m building a recommender from public ratings and watch histories. Somehow this turned into a PhD in proving Chromium is Chromium.
JavaScript. Cookies. CAPTCHA. HTTP 200, no ratings. Task failed successfully.
Then I asked the question that should have come first: does it have an app?
On 4 November, four tested app-derived public read paths for IMDb, Letterboxd, Trakt and Serializd returned structured data without a signed-in user session or CAPTCHA.
That does not mean mobile APIs have no protection. There were app-client checks, headers, cursors and probably rate limits I never triggered. Private histories stayed private. These were small tests, not an internet-wide security theorem.
SIMKL kept me humble. Its Android app was a wrapper around the website, so the side door led directly back to the same Cloudflare challenge.
One rating, several wrong answers
IMDb gives you plenty of numbers to collect incorrectly. The community average is not the profile owner’s rating. Neither is the score attached to the current viewer.
The app also had a little trap: one query returned the total number of ratings and zero rows until I matched its sort. Very reassuring. A full profile and an empty profile at the same time.
The working paginated read returned two pages, four titles and personal ratings of 7, 8, 8 and 7. I checked the owner’s field instead of collecting whichever number looked busiest.
It is the same lesson as TV2Play’s desktop resolution cap: before fighting the client in front of you, look at what another client is asking for.
And keep checking the result. Serializd returned 48 rows containing 47 event IDs because one event overlapped between pages. Deduplicate events, not titles. People rewatch things. Follow the real cursor. Do not invent a watch date from an update timestamp.
I would much rather debug that than identify another traffic light.
- Marius, whose browser remains unconvinced it is a browser