El caso: US$500 en Ads y una suspensión que nadie explica
Przemysław Alexander Kamiński, desarrollador conocido como xlii, creó RACE, un multiplexor de terminal nativo para macOS escrito en Rust. La aplicación permite redimensionar y reposicionar terminales librement en lugar de encajarlas en una grilla rígida, y conserva sesiones de shell entre reinicios. Es, en esencia, una herramienta para desarrolladores. El 9 de septiembre de 2026, Kamiński publicó un post detallado contando cómo Google Ads suspendió su cuenta tras gastar 500 dólares en una campaña, alegando "Malicious software" y "Compromised Site", según recoge su propio blog en xlii.space.
Lo singular del caso no es la suspensión en sí, sino la ausencia total de explicación: Google rechazó sus apelaciones sin indicar qué archivo, recurso o fragmento de código se consideraba malicioso, mientras múltiples herramientas de Google y de terceros confirman que la app y el sitio están limpios.
Por qué RACE fue marcada como sospechosa
RACE es, por diseño, una aplicación que lanza y gestiona procesos de shell en segundo plano. Esa conducta —gestionar subprocesos persistentes— es técnicamente idéntica a la que exhibe cierto software malicioso que esconde procesos tras instalarse. El propio Kamiński documenta este comportamiento en su blog: el comportamiento de multiplexación está descrito en la documentación de la app, y los usuarios pueden configurar dtach como backend alternativo.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad"This subprocess-management behavior is an essential part of the application's functionality and may resemble behavior sometimes associated with security-sensitive software, but it is neither hidden nor malicious." — Fragmento de la apelación documentada en xlii.space
En la versión 1.0.39 añadió además una limpieza explícita al desinstalar para reducir la huella de procesos persistentes. Ni así Google cambió el veredicto.
Qué comprobó el desarrollador antes de apelar
Antes de presentar cada recurso, Kamiński ejecutó un protocolo completo de verificación que publicó punto por punto en su blog:
- Google Safe Browsing: resultados "No unsafe content found" tanto para
race-term.comcomo paradownloads.race-term.com. - Google Search Console — Security Issues: "No issues detected" en ambos dominios.
- VirusTotal sobre el DMG distribuido: el archivo (hash
84d082f6a5d3ab75b30e532bf60b406ce12ecc3550bc3f2c6904f34d08ba5e9f) aparece limpio. - Firma y notarización del DMG y del binario verificadas externamente.
- Revisión del JavaScript del sitio: archivos fuente, bundles generados, nada ofuscado ni inyectado.
- Logs de Cloudflare: sin anomalías.
- Accesibilidad probada con distintos User Agents.
El propio escaneo interno de Google sobre el DMG no reportó malware. Aun así, las cuatro apelaciones formales fueron rechazadas con respuestas genéricas, y la última vino acompañada de un bloqueo de una semana.
El catch-22 que describe el desarrollador
En su publicación, Kamiński resume la frustración con una cita al programa satírico Radio Erywan —"¿Es verdad que dan autos en la Plaza Roja?"— donde cada palabra se corrige hasta vaciar de contenido la afirmación original. La analogía apunta al núcleo del problema:
"Who knows. That road might be out forever. […] No idea what I can do now, I'll appeal until oblivion, …or maybe I'll try EU court case. Cause it seems like that's the only road forward." — xlii.space
Para cualquier founder técnico, el patrón es reconocible: el appealedero es opaco, los formularios de revisión no permiten saber qué se está evaluando, y no existe un canal para mostrar la evidencia adicional sin repetir el mismo formulario genérico.
¿Por qué este caso importa a tu startup?
Aunque la app de Kamiński no esté en tu stack, su historia señala un riesgo infravalorado para cualquier startup que monetiza descargas, extensiones de navegador, plugins de IDE o cualquier software que toque el sistema. El ecosistema publicitario de Google castiga con la misma etiqueta al malware real y al software legítimo cuya firma heurística coincide con patrones sensibles. No necesitas hacer nada "malo" para caer: basta con que tu binario arranque procesos en segundo plano, abra puertos locales o modifique archivos del sistema en la instalación/desinstalación.
Si tu roadmap incluye distribuir software de escritorio, extensiones o ejecutables, conviene que el plan de marketing asuma que Google Ads puede caerte en el peor momento.
¿Qué significa esto para tu startup?
- Diversifica canales de adquisición antes de lanzar. No apoyes el crecimiento de un producto descargable solo en Google Ads. Combina con Product Hunt, Hacker News, Reddit (en subreddits relevantes), LinkedIn Ads, newsletters especializadas, SEO técnico y partnerships con influencers del nicho. La regla práctica: ningún canal debería representar más de 40% de tus nuevas instalaciones.
- Documenta tu comportamiento técnico en una "security explainer" pública. Si tu producto abre puertos, crea procesos persistentes o modifica el sistema, publica una página
/securityen tu sitio explicando para qué sirve cada comportamiento, enlazando a tu documentación. Cuando una revisión manual llegue, entregar ese enlace reduce fricción. El propio Kamiński tuvo que escribir esa defensa a posteriori en cada apelación. - Guarda evidencia verificable con fecha. Capturas de Google Safe Browsing, resultados de VirusTotal, informes de Search Console, hashes SHA-256 de tus binarios y logs de tu CDN. Cuando el primer aviso llegue, responder con un dossier de 2 páginas cuadra mejor que rellenar un formulario genérico.
- Ten un plan B de soporte de pago. Si tu unidad de negocio depende de Ads, separa presupuesto de contingencia para人民法院 o instancias regulatorias. La vía EU redress que el propio Kamiński menciona es real, pero lenta y costosa: no se aborda el primer día ni sin asesoría legal.
- Piensa en el atacante, pero también en el falso positivo. Las heurísticas automáticas de Google usan señales como persistencia tras desinstalación, creación de procesos en background y manipulación del sistema de archivos. Diseñar la desinstalación para ser彻底 (limpieza de launch agents, daemons y plists) reduce el riesgo de coincidencia con malware real.
Conclusión
El caso de RACE no es el primero ni será el último: un desarrollador indie con app firmada, notarizada y verificada por las propias herramientas de Google termina atrapado en un bucle de apelaciones genéricas, sin ruta clara para revertir una decisión algorítmica. La historia es una llamada de atención operativa: construye tu embudo de adquisición asumiendo que el canal publicitario más grande del mundo puede cerrarte la puerta sin explicación. Quien mejor sobrevive a estos falsos positivos es quien había diversificado canales y tenía preparada una "security explainer" antes de necesitarla.
Fuentes
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
