Google anunció el cierre de la red social Google+. Es difícil encontrar una publicación técnica que ni siquiera mencione el final de las ambiciones de las redes sociales de Google. Pero, por desgracia, se presta atención a la alta conectividad de los servicios de una buena empresa. En este artículo, me gustaría expresar mis pensamientos sobre cómo los servicios de Google interactúan internamente y qué podría significar el cierre de G + para los usuarios de la API de Google.
Para el usuario final, la transición de Gmail a Fotos, y de allí a Documentos, debe ser lo más sencilla posible: a primera vista, los servicios son independientes y están unidos por un único punto de entrada de servicio altamente pulido, Single Sign-On accounts.google.com . Pero nosotros, como desarrolladores, sabemos que las palabras "cerrar", "absorber", "integrar" tienen más significado (y más trabajo) para las personas que están desarrollando un producto de lo que parece a primera vista. Examinemos superficialmente cómo se organiza el proceso de absorción de Google de uno de los servicios externos y qué sucede con la API de servicio y la API de Google.
cuentas e ID de usuario
Además de los usuarios que usan Gmail y algunas veces adivinaron la existencia de Google Plus, también hay una gran cantidad de API para desarrolladores que son penetrados a través de conceptos como el identificador de cuenta, el notorio ID de usuario. userID es el identificador interno de Google, lo que permite a los servicios de Google comprender quién es quién y es el que conecta todos los servicios internos entre sí. Aparece en muchas API, y vemos que no ha cambiado de un servicio a otro.
Tomemos un ejemplo de la absorción de un servicio externo por parte de Google
Obviamente, para implementar SSO en un servicio recién absorbido, no puede simplemente tomar y transferir cuentas de la base de datos anterior a la nueva "base de datos 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 bien, debería haber muchos, muchos, muchos niveles de conexiones entre los servicios de Google para que todo funcione.
Pero entonces las cosas no van tan bien: en un esfuerzo por popularizar G +, utilizó usuarios de ID de usuario que son parte del servicio global de SSO.
De vuelta 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 complicado adaptar la base de usuarios existente del servicio a los servicios "General Google", para crear puntos de interacción con otros servicios para que puedan usar el nuevo servicio para sus propios fines. Pero no se trata de proyectos pequeños: la corporación del bien no es pequeña y absorbe empresas multimillonarias que, muy probablemente, ya han establecido infraestructura, de lo contrario no podrían crecer a su tamaño. 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 los de Google.
A continuación, el servicio se convierte en un servicio de Google. Digamos que en este punto ya se ha probado y se considera que son personas bastante confiables de Google, responsables de la integración. La diversión comienza: el servicio puede integrarse en otros servicios y / o transferirse de un servicio a otro.
En general, esto no daría miedo si no fuera por la tendencia de Google a cambiar el registro de los servicios.
Tome por ejemplo fotografías.
Aplicación de escritorio Picasa (2002) => Álbumes web de Picasa - Google adquiere Picasa (2004) => Google Plus incorpora Picasa (2011) => Google Photos está separado de G + (2015) => ...
Dada la inercia de los procesos de integración, Google aún admite API muy antiguas en la mayoría de los productos. En el momento de la publicación de este artículo, la API de Picasa todavía se está ejecutando desde el momento en que Picasa era un producto independiente. Es decir, concluimos que cuando Google integró Picasa con su próximo servicio, "creó una rama" a partir del original y dejó el antiguo "brunch" en sus propios dispositivos, pero no cerró su API.
Y luego es hora de recordar el motivo del cierre de G +. Problemas de seguridad informados, de hecho, puede haber problemas de seguridad aún más probables debido a la inconsistencia de diferentes API.
prueba de concepto
Por ejemplo, una vez que hubo un servicio PicasaWeb , un antepasado de las modernas fotos de Google . Se apagó en 2016 . Pero de acuerdo con la posdata al final de la publicación, la API de servicio ha seguido funcionando hasta ahora. Ya hay una fecha de finalización para que esta API funcione : 15 de marzo de 2019 . Este servicio es notable porque le permite obtener la correspondencia del correo electrónico y el ID de usuario interno. ¿Cómo puede sernos útil?
Por ejemplo, somos un servicio de verificación de correo electrónico . En este caso, esta API es simplemente maná del cielo para nosotros. Al conocer la ID de la cuenta de Google de G +, podemos obtener un nombre de usuario, una foto y, a menudo, una variedad de información adicional. La pregunta es que generalmente es imposible conocer el ID de usuario de una persona si, por ejemplo, no inicia sesión en nuestro sitio.
Pero en los viejos PicasaWebAlbums, las personas podían publicar fotos en álbumes web que se vinculaban a un correo electrónico. En realidad, de esto se deduce que la API anterior le permite obtener el perfil de una persona por ID de usuario o correo electrónico de 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/ : en realidad, el punto final en el que vive la API;
- nosov@nodeart.io - el correo electrónico del usuario para verificar, como vemos, no tiene que ser gmail aquí. Los usuarios de Google Apps tienen perfiles (lo que hace que tal verificación sea muy útil para la generación de leads), así como las personas que han creado un perfil en Google+ al vincularlo a un buzón personal de un tercer servicio, por ejemplo, Yandex.ru;
- deprecation-extension = true: una indicación de lo que sabemos sobre el final inminente de la API.
Si intentamos transferir un correo electrónico inexistente , obtendremos una respuesta claramente interpretada. No se puede encontrar al usuario con el correo electrónico noname@nodeart.io, del cual podemos concluir inequívocamente que no existe dicho correo electrónico. Y aún más: si intentamos enviar la dirección del grupo de distribución a la API , la respuesta cambiará a Usuario desconocido. De esta forma, puede distinguir los buzones personales en G Suite de los reenviadores de correo corporativo.
Esto no quiere decir que sea posible extraer la información personal de una persona si no la publicó explícitamente, pero para la validación masiva de las listas de correo, tal API era muy apropiada.
¿Cómo se relaciona este agujero de oportunidad con el cierre de G +? Conclusiones
Google llama a la razón principal para el cierre de los problemas de seguridad de G +, o más bien, la capacidad de los servicios de terceros para recibir información de G + de formas que inicialmente no están totalmente previstas y planificadas por Google.
Ahora, además de cerrar G +, hay un cierre parcial de diferentes API. Por ejemplo, para acceder a gmail.api ahora debe pasar por una auditoría paga de 15 a 75 mil USD , lo que hace que esta API sea inaccesible para la 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 confundió en el sistema de interacción entre servicios, de modo que aquellas acciones que podrían realizarse antes simplemente obteniendo el alcance deseado ahora requieren validación manual por 15-75k USD e inclusión manual en lista blanca Uno solo puede adivinar qué más se puede hacer utilizando características indocumentadas de más de un rico ecosistema de servicios de Google y SSO en particular.
Para validar cualitativamente las listas de correo, aún tendremos que buscar nuevas aplicaciones no estándar de API públicas, por lo que continuaremos estudiando la API de Google \ Facebook y otros servicios. (Por cierto, hasta hace poco, Facebook tenía una forma similar de validar correos electrónicos).