Google cerró su plataforma de redes sociales Google+ el 2 de abril de 2019. Es difícil encontrar algún artículo técnico que no mencione el final de la era de las redes sociales de Google. Pero, un alto nivel de consistencia en la conectividad dentro de los servicios de la compañía había recibido poca atención. En este artículo me gustaría compartir mis pensamientos sobre la forma interna de la coherencia de los servicios de Google y lo que significa para los usuarios de la API de Google cuando se trata de un cierre de Google+.
Desde el punto de vista del cliente, el uso de Gmail Photos y un cambio adicional a Docs debería ser lo más claro posible: a primera vista, estos servicios son independientes y están unidos dentro de una plataforma que es un punto de acceso llamado accounts.google.com . Pero como desarrolladores, sabemos, que los términos "cierre", "toma de control", "integrar" implican un gran significado (y también funcionan) para aquellas personas que participan en este proceso. Entonces, echemos un vistazo más de cerca al proceso de una de las adquisiciones de servicios externos de Google, y lo que está sucediendo con la API de servicios adquiridos y la API de Google.
Cuenta e ID de usuario
Además de los usuarios que usan Gmail y pueden haber oído hablar de Google Plus, también hay una gran cantidad de API para desarrolladores que incluyen cosas como identificadores de cuenta, el notorio ID de usuario. El ID de usuario es el ID interno de Google, esto es lo que ayuda a los servicios de Google a comprender quién es quién. Apareció en muchas API, y vemos que no ha cambiado de un servicio a otro.
Caos
Obviamente, para la implementación de SSO en el servicio recién absorbido, no puede simplemente tomar y transferir cuentas de la base anterior a la nueva "base de cuentas de Google". Creo que simplemente no existe tal cosa: hay muchos servicios entrelazados, niveles de interacción, cadenas de responsabilidad, servicios de gestión de servicios. En serio, si lo piensas, debe haber muchos, muchos, muchos niveles de conexiones entre los servicios de Google para que todo funcione. Pero luego todo no funciona tan bien: en un esfuerzo por popularizar G +, utilizó el ID de usuario de los usuarios que forman parte del servicio global de SSO.
Volvamos a la tesis. Es necesario realizar cambios en la API existente tanto desde el lado absorbido de la API como desde otros servicios que ahora pueden comenzar a funcionar con el nuevo servicio. Parece que no es nada súper complejo: adaptar la base de usuarios existente del servicio a los servicios "comunes de Google", crear puntos de interacción con otros servicios para que puedan usar el nuevo servicio para sus propios fines. Pero esto no se trata de proyectos pequeños: una corporación del bien no pierde tiempo en cosas insignificantes y absorbe empresas multimillonarias que, muy probablemente, ya han establecido infraestructura; de lo contrario, no podrían crecer a su escala. Por lo tanto, tiene sentido dejar su base de código, o más bien, el núcleo del servicio, y rehacer los canales de entrada-salida de los enlaces del servicio para que sean compatibles con Google. Entonces el servicio se convierte en un servicio de Google. Supongamos que en este momento ya se ha probado y las personas de Google que son responsables de la integración consideran que es bastante confiable. Aquí está la parte más interesante: el servicio puede integrarse en otros servicios y / o transferirse de un servicio a otro. En general, no daría miedo si no fuera por la tendencia de Google a cambiar el registro de los servicios. Tomar por ejemplo fotos.
Aplicación de escritorio Picasa (2002) => Álbumes web de Picasa - Google adquiere Picasa (2004) => Google Plus incorporó Picasa (2011) => Google Photos está separado de Google+ (2015) => ...
Teniendo en cuenta la inercia del proceso de integración, en la mayoría de los productos, Google todavía admite API muy antiguas. En el momento de la publicación del artículo, la API de Picasa todavía funciona de la misma manera que antes, cuando Picasa era un producto separado. Eso nos lleva a la conclusión de que cuando Google integró Picasa como su próximo servicio, crearon una "rama" del producto original y dejaron la antigua "rama" a merced del destino, pero no cerraron su API.
Y luego es hora de recordar la razón para cerrar G +. Sucedió debido a un problema de seguridad reportado, pero en realidad, puede haber aún más problemas de seguridad debido a la inconsistencia en diferentes API.
Prueba de concepto
Por ejemplo, había un servicio llamado PicasaWeb , el predecesor de Google Photos . No está disponible desde 2016, pero según la nota al final de una publicación, su API aún funciona. La fecha de finalización de esta API es el 15 de marzo de 2019 . Este servicio fue notable porque permitió que el correo electrónico y el ID de usuario interno coincidan. ¿Cómo sería útil?
En caso de que desarrollemos un validador de correo electrónico . En este caso, esta API sería un maná del cielo. Al conocer una ID de cuenta de G +, podemos obtener el nombre de un usuario, una foto e incluso información adicional. El truco es que no puede obtener la ID de usuario si este usuario nunca inició sesión en nuestro sitio web. Pero a pesar de esto, los usuarios pudieron publicar imágenes en álbumes web que estaban vinculados con el correo electrónico usando viejos álbumes PicasaWeb. Eso sugirió que la antigua API permite acceder a la cuenta del usuario utilizando la ID de usuario o el correo electrónico del usuario.
Vamos a ver: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ : punto final de la API;
nosov@nodeart.io - correo electrónico del usuario para verificación (como podemos ver, no es obligatorio usar solo correos electrónicos de Gmail). Los usuarios tienen cuentas de Google Apps (este hecho ayuda a que la verificación sea útil con respecto a la generación de leads), los usuarios con cuentas de Google+ también tienen esto (al vincular previamente un correo electrónico de un tercero), por ejemplo, Yandex.ru
deprecation-extension = true: la indicación sobre un punto final de API inminente.
Si intentamos pasar un correo electrónico inexistente , obtendremos una respuesta clara e interpretada: “No se puede encontrar un usuario con el correo electrónico noname@nodeart.io, lo que lleva a la conclusión de que este correo electrónico no es válido. Y aún más: si intentamos enviar una dirección de correo grupal a la API, la respuesta será "Usuario desconocido". Entonces sería posible distinguir la diferencia entre correos electrónicos personales de G-Suite y correos electrónicos corporativos. Es difícil decir que podemos "capturar" datos personales de esta manera si el usuario no compartió estos datos, pero fue bueno para la validación global de la lista de usuarios a través de API.
Entonces, ¿cómo se vincula esta imprecisión con el cierre de Google+?
Conclusiones
La razón clave para cerrar Google+ fue la falta de seguridad, más precisamente, la capacidad de obtener datos de Google+ por parte de los servicios que no fueron planificados ni previstos de antemano.
Además de Google+, se realiza el cierre parcial de varias API. Por ejemplo, debe pasar la auditoría pagada para obtener acceso a gmail.api, lo que hace que esta API no esté disponible para la gran mayoría de los desarrolladores.
Cita
El desarrollador paga la tarifa de evaluación y puede variar de $ 15,000 a $ 75,000 (o más) dependiendo del tamaño y la complejidad de la aplicación.
De hecho, esto nos da una razón para pensar que Google se ha enredado en el sistema de interacción entre servicios, ya que las acciones que anteriormente se podían realizar simplemente obteniendo el alcance requerido, ahora requieren validación manual por 15-75k USD e inclusión manual en la lista blanca Solo queda adivinar qué más puede hacer utilizando las funciones no documentadas del rico ecosistema de servicios de Google y el servicio SSO en particular.
Para validar cualitativamente las listas de correo , necesitaremos buscar nuevas formas no estándar de uso de API públicas, por lo que continuaremos explorando la API de Google \ Facebook y otros servicios. (Por cierto, Facebook hasta hace poco tenía una forma similar de validación de correo electrónico).