A developer spent $500 on a Google Ads campaign for RACE, a native macOS terminal multiplexer written in Rust, and Google suspended the account for "Malicious software" and "Compromised Site." The application was signed and notarized. The site behind it is a static Bridgetown page served from Cloudflare, with downloads in Cloudflare R2 and, at submission time, only Cloudflare Analytics as third-party JavaScript. There is no server-side application running anywhere in the stack.
So Przemysław Alexander Kamiński, who built RACE, started checking. Google Safe Browsing reported no unsafe content for both race-term.com and downloads.race-term.com, status updated 9 September 2026. Google Search Console's Security Issues report showed no issues for either domain. VirusTotal flagged nothing in the distributed DMG, and Google's own scan found no malware in the file. File signatures and notarization verified valid. Raw and bundled JavaScript reviewed, with nothing injected or obfuscated. Cloudflare logs checked, in case Google had bounced off a captcha or anti-bot guard. Accessibility tested under different user agents. Every result came back clean.
None of it moved the suspension. The appeals were rejected one after another. Google told him to submit new information, suggested deleting the account if he had none, and pointed him toward EU redress options. One appeal got the account blocked for a week. At no point did Google say what was malicious, what was compromised, or why the evidence he supplied failed to address either charge.
That opacity is what matters to anyone running distribution or ad accounts. Kamiński drew the line himself: a clean Safe Browsing result "establishes what Safe Browsing reported for those addresses. It does not establish what Google Ads detected, or whether the two systems use the same criteria." Safe Browsing, Search Console, VirusTotal, and the Ads malware classifier are separate systems with separate inputs. A clean verdict from three of them is not a clearance from the fourth. He asked for a manual re-review; each appeal came back rejected.
There is one plausible trigger in the application itself. RACE is a terminal multiplexer, so by design it launches and manages background shell processes and keeps sessions alive across application restarts. Its configuration documents three persistence backends: a native PTY host, external dtach, or no persistence. Subprocess management that outlives the parent process is exactly the sort of behavior malware heuristics look for, even though here it is the documented core function of the tool. Kamiński shipped version 1.0.39 with a cleanup step that runs after the application is deleted (now gated behind a user prompt, since silent cleanup is poor UX) to reduce that surface, and submitted it.
The suspension was eventually reversed. By the developer's account, the account was reinstated after the situation got attention on Hacker News. There was still no explanation of what had triggered it.
A few things follow for anyone distributing software whose legitimate behavior overlaps with malware heuristics. Keep the evidence chain you will be resubmitting over and over: file hashes, the VirusTotal permalink, notarization logs, and the Safe Browsing and Search Console status for every domain in the funnel, the download host included. Treat each platform signal as narrow; a clean Safe Browsing or Search Console result tells you what that one system reported, not how an ad or store classifier will rule. If your software spawns persistent background processes, assume a classifier will notice, so document the behavior, make persistence opt-in, and clean up on uninstall. RACE already documented its backends and was flagged anyway, which puts documentation in the necessary-but-not-sufficient column. And the reinstatement came from publicity, not from the appeal path, which produced rejections, a week-long block, and a pointer to EU redress, but never a review that engaged with the evidence.
Top comments (0)