Google a fermé sa plateforme de médias sociaux Google+ le 2 avril 2019. Il est difficile de trouver un article technique qui n'ait pas mentionné la fin de l'ère des réseaux sociaux de Google. Mais, un haut niveau de cohérence dans la connectivité au sein des services de la société avait reçu peu d'attention. Dans cet article, je voudrais partager mes réflexions sur la manière interne de la cohérence des services Google et ce que cela signifie pour les utilisateurs de l'API Google lorsqu'il s'agit d'un arrêt de Google+.
Du point de vue d'un client, l'utilisation de Gmail Photos et une nouvelle transition vers Docs doivent être aussi claires que possible - à première vue, ces services sont indépendants et réunis au sein d'une seule plateforme qui est un point d'accès appelé accounts.google.com . Mais en tant que développeurs, nous savons que les termes «arrêt», «prise de contrôle», «intégration» impliquent une grande signification (et aussi un travail) pour les personnes qui participent à ce processus. Examinons donc de plus près un processus de prise de contrôle de services externes par Google, et ce qui se passe avec l'API de service repris et l'API Google.
Compte et ID utilisateur
Outre les utilisateurs qui utilisent Gmail et peuvent avoir entendu parler de Google Plus, il existe également un grand nombre d'API pour les développeurs qui incluent des éléments tels que les identifiants de compte, l'ID utilisateur notoire. L'ID utilisateur est l'ID interne de Google, c'est la chose qui aide les services Google à comprendre qui est qui. Il est apparu dans de nombreuses API et nous constatons qu'il n'a pas changé de service en service.
Chaos
De toute évidence, pour la mise en œuvre de l'authentification unique dans le service nouvellement absorbé, vous ne pouvez pas simplement prendre et transférer des comptes de l'ancienne base vers la nouvelle «base de comptes Google». Je pense qu'il n'y a tout simplement pas une telle chose - il existe de nombreux services entrelacés, des niveaux d'interaction, des chaînes de responsabilité, des services de gestion des services. Sérieusement, si vous y réfléchissez, il doit y avoir de très nombreux niveaux de connexions entre les services Google pour que tout fonctionne. Mais alors tout ne va pas si bien - dans un effort pour populariser G +, il a utilisé l'ID utilisateur des utilisateurs qui font partie du service SSO mondial.
Revenons à la thèse. Il est nécessaire d'apporter des modifications à l'API existante à la fois du côté absorbé de l'API et d'autres services qui peuvent désormais commencer à travailler avec le nouveau service. Il semblerait que rien de super complexe - d'adapter la base d'utilisateurs existante du service aux services «google communs», de créer des points d'interaction avec d'autres services afin qu'ils puissent utiliser le nouveau service à leurs propres fins. Mais il ne s'agit pas de petits projets - une société de bien ne perd pas de temps en bagatelles et absorbe des entreprises de plusieurs millions de dollars, qui, très probablement, ont déjà établi une infrastructure - sinon, elles ne pourraient pas croître à leur échelle. Il est donc logique de laisser sa base de code, ou plutôt le cœur du service, et de refaire les canaux d'entrée-sortie des liens du service afin qu'ils deviennent compatibles avec Google. Ensuite, le service devient un service Google. Supposons qu'à ce moment, il ait déjà été testé et soit considéré comme assez fiable par les personnes de Google qui sont responsables de l'intégration. Voici la partie la plus intéressante - le service peut être intégré à d'autres services et / ou transféré de service en service. En général, ce ne serait pas effrayant sans la tendance de Google à modifier l'enregistrement des services. Prenez par exemple des photos.
Application de bureau Picasa (2002) => Picasa Albums Web - Google acquiert Picasa (2004) => Google Plus a incorporé Picasa (2011) => Google Photos est séparé de Google+ (2015) => ...
Compte tenu de l'inertie du processus d'intégration, dans la majorité des produits, Google prend toujours en charge de très anciennes API. Au moment de la publication de l'article, l'API Picasa fonctionnait toujours comme elle le faisait à l'époque où Picasa était un produit distinct. Cela nous amène à la conclusion que lorsque Google a intégré Picasa en tant que prochain service, il a créé une «branche» à partir du produit d'origine et a laissé l'ancienne «branche» à la merci du destin, mais n'a pas fermé son API.
Et puis il est temps de rappeler la raison de la fermeture de G +. Cela s'est produit en raison d'un problème de sécurité signalé, mais en réalité, il peut y avoir encore plus de problèmes de sécurité en raison de l'incohérence dans les différentes API.
Preuve de concept
Par exemple, il y avait un service appelé PicasaWeb - le prédécesseur de Google Photos . Il n'est pas disponible depuis 2016 mais selon la note à la fin d'un post - son API fonctionne toujours. La date de fin de cette API est le 15 mars 2019 . Ce service était remarquable car il permettait d'obtenir des e-mails et une correspondance interne de l'ID utilisateur. En quoi cela serait-il utile?
Dans le cas où nous développons un validateur d'email . Dans ce cas, cette API serait une manne du ciel. Connaissant un ID de compte de G +, nous pouvons obtenir le nom d'un utilisateur, une photo et même des informations supplémentaires. L'astuce est que vous ne pouvez pas obtenir d'ID utilisateur si cet utilisateur ne s'est jamais connecté à notre site Web. Mais malgré cela, les utilisateurs ont pu publier des photos dans des albums Web liés à des e-mails en utilisant d'anciens PicasaWebAlbums. Cela suggère que l'ancienne API permet d'accéder au compte de l'utilisateur à l'aide de l'ID utilisateur ou de la messagerie de l'utilisateur.
Vérifions: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ - point de terminaison de l'API;
nosov@nodeart.io - e-mail de l'utilisateur pour vérification (comme nous pouvons le voir, il n'est pas nécessaire d'utiliser uniquement les e-mails Gmail). Les utilisateurs ont des comptes Google Apps (ce fait aide à être utile pour la vérification de la génération de leads), les utilisateurs avec des comptes Google+ en ont également (en associant au préalable un e-mail tiers), par exemple, Yandex.ru
deprecation-extension = true - l'indication d'un point de terminaison API imminent.
Si nous essayons de transmettre un e - mail inexistant , nous obtiendrons une réponse claire et interprétée: «Impossible de trouver un utilisateur avec l'e-mail noname@nodeart.io, ce qui conduit à la conclusion que cet e-mail n'est pas valide. Et encore plus - si nous essayons d' envoyer une adresse postale de groupe à l'API, la réponse sera «Utilisateur inconnu». Il serait alors possible de distinguer la différence entre les e-mails G-Suite personnels et les e-mails d'entreprise. Il est difficile de dire que nous pouvons «attraper» les données personnelles de cette façon si ces données n'ont pas été partagées par l'utilisateur, mais c'était bon pour la validation globale de la liste des utilisateurs via l'API.
Alors, comment cette imprécision est-elle liée à la fermeture de Google+?
Conclusions
La principale raison de la fermeture de Google+ était la défaillance de la sécurité, plus précisément, la possibilité d'obtenir des données de Google+ par les services qui n'étaient pas prévus et prévus à l'avance.
Outre Google+, un arrêt partiel de diverses API est effectué. Par exemple, vous devez passer un audit payant pour accéder à gmail.api, ce qui rend cette API indisponible pour la grande majorité des développeurs.
Citation
Les frais d'évaluation sont payés par le développeur et peuvent varier de 15 000 $ à 75 000 $ (ou plus) selon la taille et la complexité de l'application.
En fait, cela nous donne une raison de penser que Google est devenu empêtré dans le système d'interaction entre les services, car les actions qui pouvaient auparavant être effectuées simplement en obtenant la portée requise, nécessitent désormais une validation manuelle pour 15 à 75 000 USD et une inclusion manuelle dans la liste blanche. Il ne reste plus qu'à deviner ce que vous pouvez faire d'autre en utilisant les fonctionnalités non documentées du riche écosystème de services de Google et du service SSO en particulier.
Afin de valider qualitativement les listes de diffusion , nous devrons rechercher de nouvelles façons non standard d'utiliser les API publiques, nous continuerons donc à explorer l'API Google \ Facebook et d'autres services. (Soit dit en passant, Facebook avait jusqu'à récemment une méthode similaire de validation des e-mails.)