Google has been fetching /.well-known/assetlinks.json 1275 times over three months and getting a 404 every time: an Android App Links association is declared against pluto and has never verified
Found while triaging an unrelated single-hit 404. This is the LARGEST 404 family pluto has and it is not a scanner. MEASURED: route /.well-known/assetlinks.json, 1276 rows. 1275 of them carry userAgent 'GoogleAssociationService' across 85 distinct IPs, continuously from 2026-07-01 to 2026-09-29, at roughly 60-150 per week every week (67, 68, 125, 59, 101, 95, 112, 147, 77, 74, 141, 115, 81, and 14 in the current partial week). The remaining row is one curl on 09-20. Zero successes are possible: the file is not served, so every one of those 1275 requests got a 404. WHAT IT MEANS: GoogleAssociationService is Google's Digital Asset Links verifier. It only fetches /.well-known/assetlinks.json for a domain that some Android app or TWA/PWA manifest DECLARES. So either (a) an Android app claims this domain and its App Links verification has been failing for three months, which means links to pluto silently open in the browser instead of the app and no user would ever report it as a bug, or (b) a stale declaration points at pluto from an app that no longer matters, in which case the fix is removing the declaration. I cannot tell which from the server side - that is the question for this lane, and it decides the priority. Filed p3 rather than higher precisely because impact depends on (a) vs (b) and I will not inflate it on an assumption. Either way 1275 pointless requests over three months, and the fix is one static file or one manifest removal. NOT part of this row, closed as noise in the same pass: the alerting route /access/api/v1/system/ping is a single hit ever, 2026-09-29 23:34:14.103, IP 20.87.107.130 (Azure range), Windows UA - a cloud-hosted scanner, no pattern, closed. /api/session/properties is 30 of 31 hits from 'metabase-cve-2026-72898-detect/1.0 (benign detection probes)', a self-identifying CVE scanner, also noise. The rest of pluto's 404 population is standard credential-hunting (/.env x88 across 42 UAs, /.git/config x64, /wp-login.php x29 and the usual .env variants).
Activity
-
Investigated pluto's own tree: public/manifest.json is a plain PWA manifest, no related_applications/android package/TWA config. No mention of an Android app, Play Store listing, or TWA anywhere in pm/ or the fleet shared/ docs. Pluto's server side has never declared, built, or served an Android App Links target - the declaration causing GoogleAssociationService's polling must live in an Android app's own manifest (AndroidManifest.xml intent-filter autoVerify) outside this repo, on Google Play Console, which this codebase has no visibility into. Cannot determine (a) vs (b) from code or fleet docs. Needs Elazar: is there a known/historical FOUBA-pensanta Android app or TWA wrapper that ever declared evolutiva.pensanta.com? If yes -> App Links verification has been silently failing 3 months (real, user-invisible bug, links opening in browser not app). If no/unknown -> a stale third-party or abandoned Play Console declaration, nothing pluto can fix server-side beyond confirming the file legitimately 404s (which it already correctly does per WELLKNOWN_BENIGN_RE classification).
-
FOLDED IN from PLUTO-758, which is now canceled as a duplicate of this row. Two lanes found this independently three days apart by different routes - this row 2026-09-29 off an unrelated single-hit 404, 758 on 2026-10-02 off a scanner sweep by censusing page_not_found instead of reading the alert rail. 758's measurement supersedes the count in this title and is the better one: 1285 rows, route='/.well-known/assetlinks.json', action='page_not_found', 2026-07-04T03:48:46Z to 2026-10-02T10:04:46Z, 91 DISTINCT days (every day since it started), 87 distinct IPs, userAgent GoogleAssociationService on 1284 of them, the remaining one a curl/8.14.1 manual probe. detail.alert is FALSE on every row. TWO defects here, not one, and the second is the more general: (1) An Android App Links association is declared against pluto and has never verified. Either the association is intentional and /.well-known/assetlinks.json must be served, or it is stale and whoever declared it should withdraw it - decide which before writing the file, because serving an assetlinks.json for an app nobody meant to associate is worse than the 404. (2) The LARGEST 404 family pluto has, non-scanner, daily for three months, reached nobody - and was then independently rediscovered, which is the measurement of the gap. detail.alert=false on 1285/1285 means the rail's firing condition never evaluated true for this shape. That is the same class as an all-clear with an unreachable threshold: the digest said nothing because of its grouping, not because nothing was there. Whoever takes this reads the rail's predicate for WHY a 91-day daily family is below it, and says whether the answer is a threshold, a userAgent filter, or a route-family rollup that hides steady-state volume behind burst detection. Do not fix (2) by adding this route to an allowlist - that converts a detector gap into a permanently silenced route and is exactly the filter-on-a-self-asserted-field failure.