Chrome instaló 4 GB de IA en mi máquina sin pedirme permiso: inspeccioné qué hace realmente y no me gusta lo que encontré

¿Por qué Google asume que 4 GB del almacenamiento de tu máquina le pertenecen? Llevaba semanas preguntándomelo cada vez que veía el mismo proceso de Chrome prendido en el monitor de actividad. Hoy lo abrí. Y lo que encontré me cambió la postura sobre algo que, hace no mucho, estaba celebrando con entusiasmo genuino.

Google Chrome AI model install without consent: lo que dice el thread y lo que dice mi disco

El thread de HN llegó a 204 puntos con una denuncia simple: Chrome descarga en silencio un modelo de IA de aproximadamente 4 GB sin ningún diálogo de confirmación, sin notificación visible, sin opción de rechazo durante el setup. El modelo forma parte de la infraestructura de Gemini Nano, el LLM on-device que Google empezó a integrar en Chrome 127+.

Mi postura inicial, cuando cubrí Gemma corriendo en el browser, era de entusiasmo cuidadoso. La IA local tiene sentido arquitectónico: latencia cero, privacidad por diseño, sin API keys. Lo sigo creyendo. Pero hay una diferencia enorme entre implementar bien una idea correcta y tomar decisiones de almacenamiento por el usuario sin preguntar.

Fui a verificarlo en mi propia máquina. Mac con Chrome 137 estable. Esto es lo que encontré:

# Buscá el modelo de Gemini Nano en macOS
# Chrome lo guarda bajo el perfil de usuario, no en /Applications
find ~/Library/Application\ Support/Google/Chrome \
  -name "*.bin" -o -name "*.tflite" -o -name "*.gguf" \
  2>/dev/null | xargs ls -lh 2>/dev/null | sort -k5 -rh | head -20

# También revisá la carpeta específica de componentes
ls -lh ~/Library/Application\ Support/Google/Chrome/Default/GeminiNano/ 2>/dev/null || \
ls -lh ~/Library/Application\ Support/Google/Chrome/OptimizationGuide/ 2>/dev/null

En mi caso, el path relevante vivía bajo OptimizationGuide. El componente se llama optimization_guide_model_store y ahí adentro había archivos que sumaban 3.7 GB en mi instalación.

# Medición exacta en mi máquina
du -sh ~/Library/Application\ Support/Google/Chrome/Default/optimization_guide_model_store/
# Resultado: 3.7G    /Users/juanchi/Library/Application Support/Google/Chrome/Default/optimization_guide_model_store/

# Ver qué hay adentro
find ~/Library/Application\ Support/Google/Chrome/Default/optimization_guide_model_store/ \
  -type f | while read f; do echo "$(ls -lh "$f" | awk '{print $5}')  $f"; done | sort -rh

Lo que encontré eran archivos .pb (Protocol Buffers, el formato de modelo de Google) junto con metadata en JSON. Ninguno tiene extensión .gguf ni .tflite directamente expuesta — Google los envuelve en su propio formato de componentes para que sean más difíciles de inspeccionar con herramientas estándar.

Lo forense: permisos, procesos y consumo real

Mi tesis acá es clara: el problema no es el modelo en sí, es el vector de instalación. Y para entender ese vector, hay que mirar más allá del tamaño del archivo.

Quién lo instala y cuándo

Chrome usa su sistema de Component Updater — el mismo mecanismo que actualiza el browser sin pedirte permiso — para descargar el modelo. No es un installer separado. No hay un .pkg ni un .exe que el sistema operativo te muestre. Es Chrome hablando directamente con update.googleapis.com en background mientras vos estás mirando un video de YouTube.

# En macOS, podés ver las conexiones de Chrome en tiempo real
lsof -i -n -P | grep -i chrome | grep ESTABLISHED | awk '{print $9}' | sort -u

# O con netstat si preferís
netstat -an | grep ESTABLISHED | grep -v "127.0.0.1"
# Filtrá manualmente los IPs de Google (142.250.x.x, 172.217.x.x)

Cuando corrí esto mientras Chrome estaba "inactivo" (sin ninguna pestaña abierta además de about:blank), tenía 11 conexiones establecidas a servidores de Google. Once. Sin que yo hubiera pedido nada.

Qué proceso lo consume

El proceso chrome_crashpad_handler no es el culpable — ese es legítimo. El que me llamó la atención fue el proceso helper sin GPU que aparece en el Monitor de Actividad con nombres como Google Chrome Helper (Renderer) consumiendo entre 180 MB y 400 MB de RAM en idle.

# Ver todos los procesos de Chrome y su consumo
ps aux | grep -i "Google Chrome" | grep -v grep | \
  awk '{printf "PID: %s | CPU: %s%% | MEM: %s KB | %s\n", $2, $3, $6, $11}' | \
  sort -t'|' -k3 -rn | head -10

En mi medición, el consumo agregado de todos los procesos helper de Chrome en idle era de ~620 MB de RAM. No está corriendo inferencias activamente — pero está precalentado, listo.

Los permisos que nadie revisó

Acá está el detalle que más me incomodó. El modelo vive en el perfil del usuario, lo cual significa que:

1. No requiere permisos de administrador para instalarse
2. No aparece en "Configuración > Almacenamiento" del sistema operativo como una app identificable
3. No se puede desinstalar desde el panel de aplicaciones — si eliminás Chrome, los archivos del perfil quedan (en macOS, el uninstaller estándar de Chrome no limpia ~/Library/Application Support/Google/Chrome/)

# Verificá qué pasa si "desinstalás" Chrome sin limpiar manualmente
# Este directorio sobrevive a la desinstalación estándar:
du -sh ~/Library/Application\ Support/Google/Chrome/
# En mi caso: 8.2G — mucho más que 3.7G del modelo solo
# El resto son caché, historial, cookies, logins guardados

8.2 GB que Chrome deja en mi disco cuando "lo desinstalé". El modelo es menos de la mitad de eso.

Los gotchas que el thread de HN no menciona

El thread de 204 puntos está bien, pero le falta profundidad técnica en algunos puntos que me parecen importantes:

Gotcha 1: El modelo no se activa solo... por ahora

Lo que encontré en Chrome 137 es que el modelo está presente pero la API window.ai no está expuesta por defecto. Para usarla necesitás habilitar flags en chrome://flags. Eso cambia el análisis de riesgo: no es que Gemini Nano esté procesando cada página que visitás en este momento. Está descargado, pero dormido detrás de un flag.

El problema es que "por ahora" es la frase más peligrosa en software. Hoy es opt-in para devs. En Chrome 142 podría ser habilitado por defecto sin aviso. Y el modelo ya está en tu disco.

Gotcha 2: La misma crítica aplica a mis propias herramientas

Tengo que ser honesto: cuando hablo de esto, no puedo ignorar que mis propios agentes en Railway hacen algo funcionalmente similar. Cuando configuro un pipeline que descarga dependencias de ML automáticamente al arrancar el contenedor, también estoy tomando espacio de disco sin "preguntarle" al servidor. La diferencia es que yo soy el dueño del servidor y sé lo que estoy haciendo.

Pero esa diferencia es exactamente el punto: el consentimiento informado no es un tecnicismo, es el criterio que separa una herramienta de un parásito.

Gotcha 3: Deshabilitarlo no es obvio

Para evitar que Chrome descargue el modelo, la ruta no es intuitiva:

Pero incluso con eso deshabilitado, el modelo que ya está descargado no se borra solo. Hay que hacerlo manualmente:

# Eliminar el modelo manualmente (macOS)
# ADVERTENCIA: verificá el path exacto en tu versión de Chrome antes de borrar
rm -rf ~/Library/Application\ Support/Google/Chrome/Default/optimization_guide_model_store/

# Verificar que se fue
du -sh ~/Library/Application\ Support/Google/Chrome/Default/optimization_guide_model_store/ 2>/dev/null || \
echo "Directorio eliminado correctamente"

Gotcha 4: La trampa del "on-device privacy"

Google vende Gemini Nano como privacidad mejorada porque corre local. Y técnicamente es verdad: la inferencia no sale de tu máquina. Pero eso no significa que los metadatos de uso no salgan. Chrome sigue reportando a Google qué features usás, con qué frecuencia, cuándo. La IA corre local; la telemetría de comportamiento no.

Escribí sobre esto desde otro ángulo cuando documenté el supply chain attack simulado sobre dependencias de ML — la superficie de ataque no es solo el modelo, es todo el ecosistema alrededor.

FAQ: Google Chrome AI model install without consent

¿Cómo sé si Chrome ya instaló el modelo de 4 GB en mi máquina?

En macOS, corré: du -sh ~/Library/Application\ Support/Google/Chrome/Default/optimization_guide_model_store/. Si el directorio existe y pesa más de 1 GB, el modelo está presente. En Windows, el path equivalente es %LOCALAPPDATA%\Google\Chrome\User Data\Default\optimization_guide_model_store.

¿Puedo borrar el modelo sin romper Chrome?

Sí. Chrome reconstruye el directorio si decidís habilitarlo de nuevo, pero no lo va a volver a descargar automáticamente si deshabilitaste la opción en configuración. El browser funciona normalmente sin el modelo — las features de Gemini Nano simplemente no están disponibles.

¿El modelo de Gemini Nano en Chrome está leyendo lo que escribo?

No de forma continua ni automática con Chrome 137 estable. La API requiere habilitación explícita vía flags. Pero "ahora no" no es la misma garantía que "nunca sin permiso". El modelo físicamente está en el disco y puede activarse en versiones futuras.

¿Esto viola el GDPR o regulaciones de privacidad?

Es una zona gris. El GDPR en Europa y regulaciones similares exigen consentimiento explícito para procesar datos personales, pero instalar software en el dispositivo del usuario cae bajo otras directivas (ePrivacy). Google argumenta que el modelo no procesa datos personales per se, sino que es infraestructura local. La discusión legal está abierta — el thread de HN tiene varios abogados especializados que lo debaten.

¿Firefox o Safari hacen algo similar?

Firefox tiene ambiciones de IA on-device pero nada de esta escala deployado en producción todavía. Safari usa modelos de Apple Intelligence que sí corren localmente en Apple Silicon, pero el mecanismo de instalación es parte del update del SO, no del browser — lo cual le da más visibilidad al usuario. Es una diferencia de diseño que importa.

¿Qué tiene que ver esto con los agentes de IA que ya uso localmente?

Mucho. Cuando escribí sobre DeepClaude combinando Claude Code con DeepSeek o sobre specsmaxxing con YAML para agentes, yo controlaba qué modelos bajaba, cuándo y para qué. La diferencia no es tecnológica — es de agencia. Chrome te sacó esa agencia sin decirte nada.

Mi postura real: celebro la tecnología, no el método

Cuando cubrí la IA on-device con entusiasmo, lo que estaba celebrando era la arquitectura: inferencia local, latencia cero, privacidad por diseño. Sigo creyendo que esa es la dirección correcta. Cuando trabajo en pipelines reales con agentes, el modelo local es la diferencia entre un sistema que depende de una API externa y uno que controlo.

Pero hay una diferencia fundamental entre ofrecer IA on-device y tomarte el disco para instalarla sin preguntar.

Lo incómodo de este caso es que Google tiene razón en la tecnología y está equivocado en el método. Son dos evaluaciones independientes y hay que mantenerlas separadas, porque conflacionarlas lleva a dos errores opuestos: rechazar la IA local por culpa del vector de instalación, o defender el vector de instalación porque la tecnología tiene mérito.

Mi punto concreto: si Gemini Nano fuera opt-in con un diálogo de instalación claro, estaría escribiendo un post completamente diferente. Estaría explicando cómo habilitarlo y por qué vale la pena. En cambio estoy documentando cómo encontrarlo y borrarlo, que es exactamente la fricción que Google quería evitar forzando la instalación silenciosa.

Eso me molesta. Y me molesta más porque sé que van a seguir haciéndolo — Chrome 142, 145, 150 — cada vez con modelos más grandes, cada vez un poco más integrados, hasta que la línea entre "el browser" y "el modelo que vive en el browser" sea imposible de trazar.

Para ese momento, espero que el usuario promedio todavía sepa correr un du -sh y preguntar para qué sirve lo que encuentra.

Fuente original: Hacker News - Google Chrome silently installs a 4 GB AI model on your device without consent