Google a annoncé la fermeture du réseau social Google+. Il est difficile de trouver une publication technique qui ne mentionne même pas en passant la fin des ambitions de Google sur les réseaux sociaux. Mais, hélas, l'attention est portée à la haute connectivité des services d'une bonne entreprise. Dans cet article, je voudrais exprimer mes réflexions sur la façon dont les services Google interagissent à l'intérieur et ce que la fermeture de G + pour les utilisateurs des services de l'API Google peut signifier.
Pour l'utilisateur final, la transition de Gmail à Photos, et de là à Docs devrait être aussi transparente que possible - à première vue, les services sont indépendants et unis par un seul point d'entrée de service très sophistiqué Single Sign-On accounts.google.com . Mais nous, les développeurs, savons que les mots «fermer», «absorber», «intégrer» ont plus de sens (et plus de travail) pour les personnes qui développent un produit qu'il n'y paraît à première vue. Examinons superficiellement comment le processus d'absorption par Google d'un des services externes est organisé et ce qui se passe avec l'API de service et l'API de Google.
comptes et ID utilisateur
En plus des utilisateurs qui utilisent Gmail et ont parfois deviné l'existence de Google Plus, il existe également un grand nombre d'API pour les développeurs qui sont pénétrées par des concepts tels que l'identifiant de compte, l'ID utilisateur notoire. userID est l'identifiant interne de Google, ce qui permet aux services Google de comprendre qui est qui, et c'est celui qui relie tous les services internes les uns aux autres. Il apparaît dans de nombreuses API et nous constatons qu'il est inchangé d'un service à l'autre.
Prenons un exemple d'absorption d'un service externe par Google
Évidemment, pour implémenter l'authentification unique dans un service nouvellement absorbé, vous ne pouvez pas simplement prendre et transférer des comptes de l'ancienne base de données vers la nouvelle "base de données des comptes Google" - je pense qu'il n'y a rien de tel - il existe de nombreux services entrelacés, niveaux d'interaction, chaînes de responsabilité, services de gestion de services. Sérieusement, si vous y réfléchissez, il devrait y avoir de nombreux, très, très nombreux niveaux de connexions entre les services Google pour que tout fonctionne.
Mais alors les choses ne se passent pas si bien - dans un effort pour populariser G +, il a utilisé des utilisateurs userID qui font partie du service SSO mondial.
Retour à 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 à fonctionner avec le nouveau service. Il semblerait que rien de très compliqué d’adapter la base d’utilisateurs existante du service aux services «Général Google», de créer des points d’interaction avec d’autres services afin qu’ils puissent utiliser le nouveau service à leurs propres fins. Mais nous ne parlons pas de petits projets - une société de bien n'est pas petite et absorbe des entreprises de plusieurs millions de dollars, qui, très probablement, ont déjà mis en place une infrastructure, sinon elles ne pourraient pas atteindre leur taille. 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 ceux de Google.
Ensuite, le service devient un service Google. Disons qu'à ce stade, il est déjà testé et considéré comme des personnes assez fiables de Google, responsables de l'intégration. Le plaisir commence - le service peut être intégré à d'autres services et / ou transféré d'un service à l'autre.
En général, cela ne serait pas effrayant sans la tendance de Google à modifier l'enregistrement des services.
Prenez par exemple des photographies.
Application de bureau Picasa (2002) => Picasa Albums Web - Google acquiert Picasa (2004) => Google Plus intègre Picasa (2011) => Google Photos est séparé de G + (2015) => ...
Étant donné l'inertie des processus d'intégration, Google prend toujours en charge de très anciennes API dans la plupart des produits. Au moment de la publication de cet article, l'API Picasa était toujours en cours d'exécution à partir du moment où Picasa était un produit autonome. Autrement dit, nous concluons que lorsque Google a intégré Picasa à son prochain service, il a "créé une branche" à partir de l'original et laissé l'ancien "brunch" à ses propres appareils, mais n'a pas fermé son API.
Et puis il est temps de se rappeler la raison de la fermeture de G +. Problèmes de sécurité signalés, en fait, il peut y avoir des problèmes de sécurité encore plus probables en raison de l'incohérence des différentes API.
preuve de concept
Par exemple, une fois qu'il y avait un service PicasaWeb , un tel ancêtre de Google Photos moderne. Il a été désactivé en 2016 . Mais selon le post-scriptum à la fin de l'article, l'API de service a continué à fonctionner jusqu'à présent. Il existe déjà une date de fin pour que cette API fonctionne - le 15 mars 2019 . Ce service est remarquable en ce qu'il vous permet d'obtenir la correspondance de l'e-mail et de l'ID utilisateur interne. Comment cela peut-il nous être utile?
Par exemple, nous sommes un service de vérification des e-mails . Dans ce cas, cette API est simplement une manne céleste pour nous. Connaissant l'ID de compte Google de G +, nous pouvons obtenir un nom d'utilisateur, une photo et souvent une variété d'informations supplémentaires. La question est qu'il est généralement impossible de connaître l'ID utilisateur d'une personne si, par exemple, il ne se connecte pas à notre site.
Mais dans les anciens PicasaWebAlbums, les gens pouvaient publier des photos dans des albums Web liés à un e-mail. En fait, il en résulte que l'ancienne API vous permet d'obtenir le profil d'une personne par ID utilisateur ou par e-mail 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/ - en fait le point de terminaison sur lequel l'API réside;
- nosov@nodeart.io - l'e-mail de l'utilisateur à vérifier, comme nous le voyons, n'a pas besoin d'être gmail ici. Les utilisateurs de Google Apps ont des profils (ce qui rend une telle vérification très utile pour la génération de leads), ainsi que les personnes qui ont créé un profil sur Google+ en y associant une boîte aux lettres personnelle d'un troisième service, par exemple, Yandex.ru;
- deprecation-extension = true - une indication de ce que nous savons de la fin imminente de l'API.
Si nous essayons de transférer un e -mail inexistant , nous obtiendrons une réponse clairement interprétée Impossible de trouver l'utilisateur avec l'e-mail noname@nodeart.io, à partir duquel nous pouvons sans équivoque conclure qu'il n'y a pas un tel e-mail. Et encore plus - si nous essayons d'envoyer l'adresse du groupe de distribution à l'API , la réponse passera à Utilisateur inconnu. De cette façon, vous pouvez distinguer les boîtes aux lettres personnelles dans G Suite des redirecteurs de messagerie d'entreprise.
Cela ne veut pas dire qu'il est possible de retirer les informations personnelles d'une personne si elle ne les a pas explicitement publiées, mais pour la validation de masse des listes de diffusion, une telle API était très appropriée
Comment ce trou d'opportunité est-il lié à la fermeture de G +? Conclusions
Google appelle la principale raison de la fermeture des problèmes de sécurité G +, ou plutôt, la capacité des services tiers à recevoir des informations de G + d'une manière qui n'est pas entièrement prévue et planifiée initialement par Google lui-même.
Maintenant, en plus de fermer G +, il y a une fermeture partielle de différentes API. Par exemple, pour accéder à gmail.api maintenant, vous devez passer par un audit payant d'une valeur de 15 à 75 000 USD , ce qui rend cette API inaccessible à la plupart 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 des raisons de penser que Google s'est confondu dans le système d'interaction entre les services, de sorte que les actions qui pourraient être effectuées plus tôt en obtenant simplement la portée souhaitée nécessitent maintenant une validation manuelle pour 15 à 75 000 USD et une inclusion manuelle dans liste blanche. On ne peut que deviner ce qui peut être fait d'autre en utilisant des fonctionnalités non documentées de plus qu'un riche écosystème de services Google et de service SSO en particulier.
Afin de valider qualitativement les listes de diffusion, nous devrons toujours rechercher de nouvelles applications non standard d'API publiques, nous continuerons donc d'étudier l'API Google \ Facebook et d'autres services. (Soit dit en passant, jusqu'à récemment, Facebook avait un moyen similaire de valider les e-mails.)