Google hat seine Social-Media-Plattform Google+ am 2. April 2019 geschlossen. Es ist schwierig, einen technischen Artikel zu finden, in dem das Ende der Ära der sozialen Netzwerke von Google nicht erwähnt wird. Ein hohes Maß an Konsistenz in der Konnektivität innerhalb der Dienste des Unternehmens hatte jedoch kaum Beachtung gefunden. In diesem Artikel möchte ich meine Gedanken über die interne Art und Weise der Konsistenz von Google-Diensten und deren Bedeutung für Google API-Nutzer beim Herunterfahren von Google+ mitteilen.
Aus Sicht eines Kunden sollten die Verwendung von Google Mail-Fotos und eine weitere Verlagerung auf Textdateien so klar wie möglich sein. Auf den ersten Blick sind diese Dienste unabhängig und auf einer Plattform zusammengefasst, die als Zugangspunkt namens accounts.google.com fungiert . Als Entwickler wissen wir jedoch, dass die Begriffe „Herunterfahren“, „Übernahme“ und „Integrieren“ für die Personen, die an diesem Prozess teilnehmen, eine große Bedeutung haben (und auch funktionieren). Schauen wir uns also einen genaueren Prozess der Übernahme von externen Diensten durch Google an und was mit der übernommenen Dienst-API und der Google-API los ist.
Konto und Benutzer-ID
Neben Nutzern, die Google Mail verwenden und möglicherweise von Google Plus gehört haben, gibt es auch eine Vielzahl von APIs für Entwickler, die beispielsweise Konto-IDs und die berüchtigte Benutzer-ID enthalten. Die Benutzer-ID ist die interne ID von Google. Dies hilft den Google-Diensten zu verstehen, wer wer ist. Es erschien in vielen APIs und wir sehen, dass es sich nicht von Dienst zu Dienst geändert hat.
Chaos
Offensichtlich können Sie für die Implementierung von SSO in dem neu aufgenommenen Dienst nicht einfach Konten von der alten Basis auf die neue "Google-Kontenbasis" übertragen. Ich denke, so etwas gibt es einfach nicht - es gibt viele miteinander verflochtene Dienste, Interaktionsebenen, Verantwortungsketten und Service-Management-Dienste. Im Ernst, wenn Sie darüber nachdenken, muss es viele, viele, viele Ebenen von Verbindungen zwischen Google-Diensten geben, damit alles funktioniert. Aber dann läuft nicht alles so reibungslos - um G + bekannt zu machen, wurde die Benutzer-ID von Benutzern verwendet, die Teil des globalen SSO-Dienstes sind.
Kommen wir zurück zur These. Es ist erforderlich, Änderungen an der vorhandenen API sowohl von der absorbierten Seite der API als auch von anderen Diensten vorzunehmen, die jetzt mit dem neuen Dienst arbeiten können. Es scheint nichts sehr Komplexes zu sein - die vorhandene Nutzerbasis des Dienstes an "allgemeine Google" -Dienste anzupassen, Interaktionspunkte mit anderen Diensten zu schaffen, damit diese den neuen Dienst für ihre eigenen Zwecke nutzen können. Hier geht es jedoch nicht um kleine Projekte - ein Unternehmen des Guten verschwendet keine Zeit mit Kleinigkeiten und absorbiert Unternehmen im Wert von mehreren Millionen Dollar, die höchstwahrscheinlich bereits eine Infrastruktur aufgebaut haben - andernfalls könnten sie nicht in ihrem Umfang wachsen. Es ist daher sinnvoll, die Codebasis oder vielmehr den Kern des Dienstes zu verlassen und die Eingabe- / Ausgabekanäle der Links des Dienstes zu wiederholen, damit sie mit Google kompatibel werden. Dann wird der Dienst zu einem Google-Dienst. Nehmen wir an, dass es zu diesem Zeitpunkt bereits getestet wurde und von den für die Integration verantwortlichen Personen von Google als sehr vertrauenswürdig eingestuft wird. Hier ist der interessanteste Teil: Der Dienst kann in andere Dienste integriert und / oder von Dienst zu Dienst übertragen werden. Im Allgemeinen wäre es nicht beängstigend, wenn Google nicht die Tendenz hätte, die Registrierung von Diensten zu ändern. Nehmen Sie zum Beispiel Fotos auf.
Picasa-Desktopanwendung (2002) => Picasa-Webalben - Google erwirbt Picasa (2004) => In Google Plus aufgenommenes Picasa (2011) => Google Fotos ist von Google+ (2015) getrennt => ...
In Anbetracht der Trägheit des Integrationsprozesses unterstützt Google bei den meisten Produkten immer noch sehr alte APIs. Zum Zeitpunkt der Veröffentlichung des Artikels funktioniert die Picasa-API immer noch so wie damals, als Picasa ein separates Produkt war. Dies bringt uns zu dem Schluss, dass Google bei der Integration von Picasa als nächstem Dienst eine „Filiale“ aus dem Originalprodukt erstellt und die alte „Filiale“ dem Schicksal überlassen hat, die API jedoch nicht heruntergefahren hat.
Und dann ist es Zeit, sich an den Grund für das Schließen von G + zu erinnern. Dies geschah aufgrund eines gemeldeten Sicherheitsproblems, aber in Wirklichkeit kann es aufgrund von Inkonsistenzen in verschiedenen APIs noch mehr Sicherheitsprobleme geben.
Proof of Concept
Zum Beispiel gab es einen Dienst namens PicasaWeb - den Vorgänger von Google Fotos . Es ist seit 2016 nicht mehr verfügbar, aber laut dem Hinweis am Ende eines Beitrags funktioniert seine API immer noch. Das Enddatum dieser API ist der 15. März 2019 . Dieser Dienst war bemerkenswert, da er die Übereinstimmung von E-Mail und interner Benutzer-ID ermöglichte. Wie wäre es nützlich?
Für den Fall, dass wir einen E-Mail-Validator entwickeln . In diesem Fall wäre diese API ein Manna vom Himmel. Wenn wir eine Konto-ID von G + kennen, können wir den Namen eines Benutzers, ein Foto und sogar zusätzliche Informationen abrufen. Der Trick ist, dass Sie keine Benutzer-ID erhalten können, wenn sich dieser Benutzer nie auf unserer Website angemeldet hat. Trotzdem konnten Benutzer Bilder in Webalben veröffentlichen, die mit alten PicasaWebAlbums mit E-Mails verknüpft waren. Dies deutete darauf hin, dass die alte API das Aufrufen des Benutzerkontos mithilfe der Benutzer-ID oder der E-Mail-Adresse des Benutzers ermöglicht.
Überprüfen wir Folgendes: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ - Endpunkt der API;
nosov@nodeart.io - E-Mail des Benutzers zur Überprüfung (wie wir sehen können, müssen nicht nur Google Mail-E-Mails verwendet werden). Benutzer haben Google Apps-Konten (diese Tatsache hilft, dass die Überprüfung bei der Lead-Generierung hilfreich ist). Benutzer mit Google+ Konten haben diese ebenfalls (indem sie zuvor eine E-Mail eines Drittanbieters verknüpfen), z. B. Yandex.ru
deprecation-extension = true - die Angabe über einen bevorstehenden API-Endpunkt.
Wenn wir versuchen, nicht vorhandene E-Mails weiterzuleiten , erhalten wir eine klar interpretierte Antwort: „Es kann kein Benutzer mit der E-Mail noname@nodeart.io gefunden werden. Dies führt zu dem Schluss, dass diese E-Mail nicht gültig ist. Und noch mehr - wenn wir versuchen , eine Gruppenpostadresse an die API zu senden, lautet die Antwort "Unbekannter Benutzer". Es wäre dann möglich, den Unterschied zwischen persönlichen G-Suite-E-Mails und Unternehmens-E-Mails zu unterscheiden. Es ist schwer zu sagen, dass wir persönliche Daten auf diese Weise „abfangen“ können, wenn diese Daten nicht vom Benutzer geteilt wurden, aber es war gut für die globale Validierung der Benutzerliste über die API.
Wie hängt diese Ungenauigkeit mit dem Herunterfahren von Google+ zusammen?
Schlussfolgerungen
Der Hauptgrund für das Herunterfahren von Google+ war ein Sicherheitsverlust, genauer gesagt die Möglichkeit, Daten von Google+ von den Diensten abzurufen, die zuvor nicht geplant und beabsichtigt waren.
Neben Google+ werden verschiedene APIs teilweise heruntergefahren. Beispielsweise sollten Sie eine kostenpflichtige Prüfung bestehen, um Zugriff auf gmail.api zu erhalten , wodurch diese API für die überwiegende Mehrheit der Entwickler nicht verfügbar ist.
Zitieren
Die Bewertungsgebühr wird vom Entwickler bezahlt und kann je nach Größe und Komplexität der Anwendung zwischen 15.000 und 75.000 USD (oder mehr) liegen.
Dies gibt uns Anlass zu der Annahme, dass Google in das System der Interaktion zwischen Diensten verwickelt ist, da die Aktionen, die zuvor nur durch Erhalt des erforderlichen Umfangs ausgeführt werden konnten, jetzt eine manuelle Validierung für 15 bis 75.000 USD und eine manuelle Aufnahme in erfordern die Whitelist. Es bleibt nur zu raten, was Sie sonst noch tun können, wenn Sie undokumentierte Funktionen von Googles reichhaltigem Ökosystem der Dienste und insbesondere des SSO-Dienstes verwenden.
Um Mailinglisten qualitativ zu validieren , müssen wir nach neuen, nicht standardmäßigen Methoden für die Verwendung öffentlicher APIs suchen, damit wir weiterhin die Google \ Facebook-API und andere Dienste untersuchen können. (Übrigens hatte Facebook bis vor kurzem eine ähnliche Methode zur E-Mail-Validierung.)