- Los sitios desaparecen de la búsqueda de Google y desaparecen en el olvido
- Videos de Youtube desmonetizados y los creadores están perdiendo ingresos
- Las aplicaciones de Android desaparecen de Google Play y no pueden llegar a sus usuarios
- Los precios de las API aumentan bruscamente o simplemente están desactualizadas
- Por último, pero no menos importante, una contraparte personal de todo lo anterior: las personas pierden el acceso a sus cuentas de Gmail y toda su vida digital.
¡Te juro que leí las preguntas frecuentes!
Todo va según un escenario. Al principio, las empresas utilizan deliberadamente los servicios de Google de una manera que depende completamente de ellos para su supervivencia. Luego, el gigante automatizado de Google hace su trabajo: cambia ligeramente la posición de su trasero en una silla de cuero del tamaño de un planeta y, sin darse cuenta, destruye una miríada de empresas (relativamente) pequeñas del tamaño de una hormiga en el proceso. Y, finalmente, las empresas del tamaño de una hormiga están desesperadas por decirle a Google que están aplastadas, pero solo pueden comunicarse con un formulario de sugerencia automatizado.
A veces, un CEO del tamaño de una hormiga conoce a alguien en Google porque eran compañeros de la universidad, o un CTO escribe una publicación que de alguna manera termina en la portada de Hacker News. Entonces Google se da cuenta del problema y, en ocasiones, lo considera digno de una solución, generalmente por temor a las implicaciones regulatorias que podría tener la revolución de las hormigas.
Por esta razón, la sabiduría convencional de las hormigas dicta que no debe confiar demasiado en los servicios de Google. Y si logras evitar esta adicción, todo debería ir bien.
¡Una superficie azul tan plana con un techo rojo fresco! ¡Muy conveniente!
¿Qué hay de nuevo bajo la luna?
En la serie de hoy "Internet no es lo que era antes", hablaremos sobre una nueva forma en que Google puede abrumar inadvertidamente a su startup. No requiere que use los servicios de Google de ninguna manera (intencional) .
¿Sabía que Google puede incluir sus dominios en una lista negra sin ningún motivo específico, y que esta lista negra no solo la utiliza Google Chrome, sino también varios otros proveedores de software y hardware? ¿Sabía que estos otros proveedores sincronizan la lista con tiempos e interpretaciones que cambian enormemente, por lo que resolver cualquier problema se vuelve extremadamente estresante e impredecible? Al mismo tiempo, ¿los plazos para procesar las quejas sobre la lista negra en Google se miden en semanas?
Así es como se ve su sitio o aplicación SaaS.
Esta "función" de la lista negra se llama Navegación segura de Google , y en la imagen de arriba puede leer el mensaje que ven los visitantes de su sitio si uno de los dominios está incluido en la base de datos de Navegación segura. Los textos de advertencia van desde "Sitio falso" hasta "El sitio contiene malware" (lista completa aquí ), pero todos se colocan sobre un fondo rojo igualmente aterrador que intenta evitar que el usuario acceda al sitio tanto como sea posible.
La primera vez que nos enteramos del problema se debió a un aumento en las quejas de los clientes que encontraron esta advertencia roja al intentar usar nuestra aplicación SaaS. La segunda vez, estamos mejor preparados, por lo que ya tenemos tiempo libre para escribir este artículo.
Nuestra empresa InvGate es una plataforma SaaS para departamentos de TI que trabaja en AWS. Sirve a más de 1000 clientes corporativos y millones de usuarios finales. Las empresas utilizan el producto para gestionar tickets y solicitudes de sus usuarios. Puede imaginar la reacción de los administradores de TI cuando, de repente, su sistema de tickets comienza a mostrar a los usuarios finales advertencias de seguridad tan ominosas.
Cuando nos encontramos con este problema por primera vez, estábamos desesperados por entender qué estaba pasando y comprender cómo funciona la Navegación segura de Google (GSB), mientras que el soporte técnico intentaba hacer frente al flujo de solicitudes de los clientes. Rápidamente nos dimos cuenta de que la URL de la CDN de Amazon Cloudfront , desde la que estábamos proporcionando recursos estáticos (CSS, Javascript, etc.), ingresó a la base de datos de GSB , y esto provocó que toda la aplicación fallara para los clientes que usaban esta CDN en particular. Un vistazo rápido al sistema etiquetado mostró que todo se ve bien.
Mientras el equipo de Devops trabajaba apresuradamente para configurar una nueva CDN y prepararse para mover clientes a un nuevo dominio, encontré en la documentación de Google que a través de Google Search Console(GSC) puede obtener explicaciones adicionales sobre las razones por las que el sitio está marcado en la base de datos. No lo aburriré con los detalles, pero para acceder a esta información, debe demostrar que es el propietario del sitio , para hacer esto, configurar un registro DNS personalizado o cargar algunos archivos en la raíz del dominio. Lo hicimos, y en 20 minutos recibimos un informe sobre nuestro sitio.
El informe se veía así:
Esto ... no es particularmente informativo
El informe también tenía un botón Solicitar revisión en el que hice clic rápidamente sin realizar ninguna acción en el sitio, ya que no había información sobre el supuesto problema. Envié una solicitud con la nota de que no tenía URL maliciosas en la lista, aunque la documentación indica que Google siempre proporciona URL de muestra para ayudar a los webmasters a identificar problemas.
¡Multa! Una solicitud para verificar un informe no válido puede hacer que las verificaciones futuras se vuelvan aún más lentas.
Aproximadamente una hora después, el sitio se eliminó de la base de datos de GSB, ni siquiera terminamos de retirar clientes de esta CDN. Aproximadamente dos horas después, llegó un correo electrónico automático confirmando que la verificación se realizó correctamente. No se aclara qué causó el problema.
Que paso despues
Durante la semana siguiente al incidente, continuamos recibiendo informes periódicos de problemas de acceso de los clientes.
Google Safe Browsing proporciona dos API diferentes para su uso en productos comerciales y no comerciales. En nuestro caso, el problema fue reproducible en al menos algunos usuarios de Firefox, así como en algunos dispositivos antivirus y de seguridad de red. Etiquetaron nuestro sitio y bloquearon el acceso a él muchos días después .
Continuamos migrando todos los clientes de la antigua CDN a la nueva, por lo que terminamos solucionando el problema para siempre. Realmente nunca descubrimos la razón y culpamos a una IA drogada en la sede de Google.
Cómo evitar que la Navegación segura de Google etiquete su sitio
Si tiene una empresa SaaS y les promete a los clientes disponibilidad garantizada, la inclusión en Google Safe Browsing sin ningún motivo específico es un riesgo comercial muy real.
Desafortunadamente, dado el mecanismo puramente opaco de Google para etiquetar y ver sitios, es poco probable que se garantice que esto se evitará. Pero ciertamente puede diseñar su aplicación y procesos para minimizar la probabilidad de que esto suceda, reducir el impacto de las listas negras reales y minimizar el tiempo que lleva resolver el problema.
Estos son los pasos que estamos tomando y que puedo recomendar:
- . , GSB . , . , company.om , app.company.net , eucdn.company.nt , useastcdn.company.nt . .
- . - , SaaS . , , . , , . , companyusercontent.cm .
- Google Search Console. , , . , , .
- Esté preparado para cambiar su dominio si es necesario . Esto es lo más difícil de hacer, pero es la única herramienta eficaz contra las listas negras: diseñar sistemas para que los nombres de dominio de servicio se puedan cambiar fácilmente (mediante scripts o herramientas de orquestación). Por ejemplo, suponga que eucdn.company2.net tiene un registro CNAME para eucdn.company.net y, si el primero está bloqueado, actualice la configuración de la aplicación para cargar recursos desde un dominio alternativo.
Qué hacer si su aplicación SaaS o su sitio web están incluidos en la lista negra de Navegación segura de Google
Esto es lo que recomendaría:
- Si puede cambiar su aplicación de manera fácil y rápida a otro dominio, esta es la única forma de resolver el incidente de manera confiable, rápida y supuestamente finalmente . Si puede, hágalo. Eso es todo.
- , , Google Search Console. , , .
- , (, ), . Safe Browsing , , .
- , , , . .
Unos meses después del primer incidente, recibimos un correo electrónico de Search Console informándonos que uno de nuestros dominios estaba nuevamente en la lista negra. Unas horas más tarde, como administrador de dominio de G Suite, recibí otro correo electrónico interesante, que puede leer a continuación.
La "sc" en sc-noreply@google.com significa Search Console.
Permítanme explicar en mis propias palabras qué es, porque es simplemente alucinante. Esta es una advertencia por correo electrónico de Search Console sobre la inclusión en la lista negra. Este segundo correo electrónico dice que el filtro de correo electrónico de phishing automático de G Suite considera que este correo electrónico de Google Search Console es falso . Por supuesto que no lo es .porque nuestro dominio ha sido incluido en la lista negra. Por tanto, Google ni siquiera puede decidir si sus propias alertas de phishing son phishing . (¿Lol?)
Algunos pensamientos desagradables sobre el futuro de Internet
Para cualquiera en la industria de la tecnología, está bastante claro que los grandes gigantes tecnológicos son prácticamente los guardianes de Internet. Pero antes lo interpreté en un sentido libre y metafórico. El incidente de Navegación segura descrito aquí dejó muy claro que Google literalmente controla quién puede acceder a su sitio, sin importar dónde y cómo lo opere. Dado que Chrome representa aproximadamente el 70% del mercado, y Firefox y Safari utilizan hasta cierto punto la base de datos GSB, Google puede hacer que cualquier sitio sea casi inaccesible en Internet con un movimiento de un dedo.