www.google.com – La página está en blanco cuando se accede
Un error de *user-agent* del lado del servidor hizo que la página principal de Google se mostrara en blanco en Firefox para Android, aparentemente para todas las versiones de Firefox ≥65, mientras que otros navegadores y las búsquedas desde la barra de direcciones seguían funcionando. Los comentaristas debaten si esto refleja fricción deliberada contra un competidor con poca cuota o simple negligencia amplificada por las prácticas de pruebas centradas en Chrome de Google, y señalan que Mozilla responde anulando el *user-agent* para Google en Firefox. El incidente reaviva las críticas al *UA sniffing* en general, las preocupaciones sobre el dominio de Chrome y la interoperabilidad web, y la frustración de que los proveedores de navegadores tengan que publicar soluciones específicas para sitios de grandes plataformas.
Causa técnica y alcance
- El error se rastreó hasta un User-Agent sniffing del lado del servidor en www.google.com.
- Firefox para Android con versión ≥65 recibe un documento HTML que contiene solo un doctype (página en blanco); ≤64 funciona.
- La combinación problemática es “Android” + “Firefox”; al eliminar esos tokens de la cadena UA, la página se carga normalmente.
- El problema afecta a la página principal de búsqueda, no a las búsquedas desde la barra de direcciones, y desaparece cuando Firefox se pone en “modo escritorio” (UA diferente).
Prácticas de pruebas y QA
- Muchos comentaristas sostienen que Google probablemente no prueba en Firefox Android en absoluto, y se centra en Chrome (escritorio/móvil), Safari, Edge y quizá Firefox de escritorio.
- Algunos describen el modelo de despliegue de Google (lanzamientos por porcentajes en fases más métricas) y dicen que la pequeña cuota de Firefox Android significa que las regresiones quizá nunca activen los umbrales de despliegue.
- Otros encuentran sorprendente la falta de pruebas automatizadas que cubran Firefox móvil dada la escala de Google.
Intención vs. negligencia
- Un bando ve esto como parte de un patrón de larga data de fallos “accidentales” de Google que afectan a Firefox (YouTube, Maps, puntuaciones deportivas, tiempo, búsqueda de imágenes).
- Argumentan que incidentes repetidos de “ups” y la falta de soporte equivalen de facto a sabotaje, o al menos a negligencia anticompetitiva.
- Otro bando piensa que el sabotaje deliberado es poco probable: la existencia de Firefox ayuda a la imagen antimonopolio de Google, y explicaciones más plausibles son la baja prioridad y una cultura interna centrada en Chrome.
- Varios señalan que, desde la perspectiva del impacto en el usuario, negligencia versus malicia no cambia el daño.
Soluciones provisionales de Mozilla/navegador
- Firefox mantiene shims de compatibilidad (
about:compat) que incluyen sustituciones de UA, scripts inyectados y excepciones para el bloqueo de rastreadores. - Mozilla parece dispuesta a publicar un parche de emergencia que anule el UA para Google; algunos lo llaman “insano”, otros señalan que los sistemas operativos y los navegadores suelen llevar hacks específicos para apps/sitios con el fin de que los servicios populares sigan funcionando.
Debate sobre el User-Agent sniffing
- Muchos critican el UA sniffing por ser frágil e innecesario para algo tan básico como una página de búsqueda; se prefiere la detección de características.
- Otros defienden un manejo limitado basado en UA para errores conocidos de navegadores, ajustes de rendimiento o particularidades específicas de versiones, aunque advierten contra listas blancas/negras amplias.
- Se señala la ironía de que Google también ha impulsado el congelamiento de la cadena UA, pero luego se ve afectado por el análisis del UA.
Alternativas y comportamiento de los usuarios
- Varios usuarios dicen que no lo notaron porque ya usan motores de búsqueda alternativos (Kagi, DuckDuckGo, Brave Search).
- La discusión incluye pros y contras de estos servicios y técnicas de usuario como los “bangs” de DDG y el bloqueo de dominios.
Meta: HN y rastreadores de incidencias
- El issue de GitHub se bloqueó una vez que llegó a HN; los mantenedores subrayaron que los rastreadores de errores son lugares de trabajo, no foros de discusión.
- En general, los comentaristas coinciden en que que grandes comunidades externas se amontonen en los rastreadores de incidencias añade ruido y justifica el bloqueo.