Sunday, November 8, 2026

News

aocr.org Traffic in Your Analytics Is a Bot, and tin.computer Traces Its Stack to ByteDance

ResearchPatryk Raba
aocr.org Traffic in Your Analytics Is a Bot, and tin.computer Traces Its Stack to ByteDance
Fot. Patryk Raba, nowosci.ai (Wszelkie prawa zastrzeżone)

An analysis by tin.computer says the visits with an aocr.org referrer come from a crawler whose network fingerprint matches ByteDance's Bytespider, though its operator has not been established. The same pattern shows up on 8 sites run by nowosci.ai's publisher, where the bot generated 388 sessions, 206 of them on November 6.

Contents
  1. What tin.computer Confirmed
  2. What Has Not Been Proven
  3. The Same Pattern Across the Publisher's Sites
  4. Impact and What to Do

The visits with an aocr.org referrer that have been showing up in the analytics of many websites since September are not human. According to an analysis by Ege Demir, published on October 29 on tin.computer, they come from a crawler with a network fingerprint matching Bytespider, ByteDance's declared crawler, running from servers on China Mobile's network in Shanxi province. The same pattern appears in the analytics of 8 sites run by nowosci.ai's publisher.

According to tin.computer, each visit opens a single page and ends there, and the crawler uses a new US proxy address for every page. It presents itself as Chrome 146 on Windows 10, with an 800 x 600 screen and the Asia/Shanghai time zone, and on each page it waits 28 seconds and scrolls. Other site owners have reported such visits since around September 24.

The referrer is forged. The crawler's requests carry a Sec-Fetch-Site header with the value none, which a browser sends when a user types in an address or a program opens the page, whereas a click on a link at aocr.org would produce cross-site. The aocr.org domain belongs to the American Osteopathic College of Radiology (AOCR). According to tin.computer, the organization has nothing to do with this traffic, its site does not link to the visited sites, and there is no sign of a hack. The author asks readers not to contact AOCR about it and admits to having found no reason why the crawler uses this particular domain.

What tin.computer Confirmed

The first finding concerns the network: the crawler sends a TLS ClientHello packet of a different length than real Chrome versions 146 to 157, sets an HTTP/2 priority weight of 256 instead of 16, and lists image/heif in its Accept header. On sites monitored by tin.computer from September 20 to October 29, all three traits together appeared in 199 of 199 crawler requests, 646 of 1,142 requests from declared Bytespider and TikTokSpider crawlers (57%), and 115 of 137,964 other requests (0.08%). The author says Bytespider has used this stack since at least 2024, but earlier crawlers sent no referrer and looked like direct visits, while the current one stands out precisely because of its fake referrer.

The second finding comes from session recordings: the page timing data contains fields named after Forest, ByteDance's internal resource-loading mechanism. Every recording of a crawler visit had them, and none of the 37 recordings of real visitors did; the author concludes that the crawler probably uses a Chromium build prepared by ByteDance. The third concerns the machines: a WebRTC test on clawmessenger.com, one of the monitored sites, revealed during the first seven crawler visits 14 IPv6 addresses from a single /64 subnet and 2 IPv4 addresses, all in AS132510, China Mobile's data center network in Shanxi province. The machines run Linux with Chinese fonts, even though they claim to be Windows computers.

What Has Not Been Proven

The analysis clearly separates these findings from the question of who runs the crawler. The AS132510 network belongs to China Mobile, and according to the author other companies use it as well.

Not proven: who operates it. It can be a ByteDance team or a customer that uses ByteDance's technology. - Ege Demir, tin.computer

As an example of a ByteDance service whose customer could be behind the crawler, the author names the cloud platform Volcano Engine, but does not claim that Volcano Engine runs it. The article also does not say why the crawler fetches pages. The author writes that tin.computer sent its evidence and three questions to ByteDance on October 29, and that as of November 7 the text contained no reply. They promise to add one and to correct the facts if ByteDance shows an error. tin.computer belongs to Emotion Machine, a San Francisco company that promotes its own offering on AI agent visits on the same page.

The Same Pattern Across the Publisher's Sites

In the analytics of the nowosci.ai publisher's sites, run on self-hosted Umami, 388 sessions with an aocr.org referrer were recorded across 8 sites through November 7 (13:22 UTC). Most were on the largest of them (321), followed by nowosci.ai (37), raba.pl (18) and openclaw.com.pl (7), with single sessions on four smaller sites. In the publisher's data the first visits date from September 18, while other site owners have reported them, according to tin.computer, since around September 24. Traffic was sporadic through the end of October, with one spike to 35 sessions on October 29, then rose sharply in November: 16 sessions on November 5, 206 on November 6, and 109 on November 7 by 13:22 UTC.

The analytics parameters match tin.computer's description. Umami recorded an 800 x 600 screen in almost every session (two were 600 x 800), and Chrome, Windows 10 and the en-US language in all of them. 375 of 389 visits (96%) ended on a single page, and the median time between the first and last recorded event of a visit was 23.6 seconds. Three quarters of sessions had an exit address in the US, the rest in places including Germany, Singapore and Brazil.

Logs from the server that hosts the largest of these sites and the Umami counter for all of the publisher's sites show 5,365 requests from October 13 to November 7 with a www.aocr.org referrer and the same User-Agent header that tin.computer reports. The forged referrer appeared in every request, including those for CSS, JS and images and for calls to the analytics server on a different domain, where ordinary Chrome sends the address of the page being visited. This indicates that the header is added by automation. The requests came from 1,020 different IP addresses, only 7 of which appeared on more than one day. The addresses belonged to, among others, each of the seven networks listed in tin.computer's table: Datacamp/CDN77, Web2Objects, M247, Ace Data Centers, NET3, EGIHosting and FDCservers.

Impact and What to Do

Small sites feel it proportionally the most. Since the bot's first visit to a given site, its sessions made up 0.18% of all sessions on the largest site and 0.94% on nowosci.ai, but 8.45% on raba.pl (18 of 213) and 16.3% on openclaw.com.pl (7 of 43). The bot also inflates other numbers: on the largest site it "viewed" partner banners 924 times and sent 321 event requests to PostHog, a product analytics tool.

The simplest step is a referrer filter in the analytics tool: tin.computer recommends excluding www.aocr.org in Plausible, Umami and Fathom, and in GA4 a segment that excludes aocr.org as a source. In the Umami instances of the publisher's sites, the referrer domain is stored as aocr.org, without www. The author advises against blocking IP addresses, because the crawler uses a new address on every visit, and warns that the referrer may change while the network fingerprint will probably stay. Since November 7, the server in front of Umami on the publisher's sites no longer forwards counter calls with this referrer, so the bot is no longer counted there, while the pages themselves remain accessible. A detailed guide to configuring the filters is published separately by vibecoding.pl, a site of the same publisher.

Share: