Google kündigte die Schließung des sozialen Netzwerks Google+ an. Es ist schwer, eine technische Publikation zu finden, die nicht einmal das Ende der Social-Media-Ambitionen von Google erwähnt. Leider wird jedoch auf die hohe Konnektivität der Dienste eines guten Unternehmens geachtet. In diesem Artikel möchte ich meine Gedanken darüber zum Ausdruck bringen, wie Google-Dienste im Inneren interagieren und was die Schließung von G + für Benutzer der Google API-Dienste bedeuten kann.
Für den Endbenutzer sollte der Übergang von Google Mail zu Fotos und von dort zu Dokumenten so nahtlos wie möglich sein. Auf den ersten Blick sind die Dienste unabhängig und durch einen einzigen, hochglanzpolierten Service-Einstiegspunkt vereint. Single Sign-On accounts.google.com . Wir als Entwickler wissen jedoch, dass die Wörter „schließen“, „absorbieren“, „integrieren“ für Menschen, die ein Produkt entwickeln, mehr Bedeutung (und mehr Arbeit) haben, als es auf den ersten Blick erscheinen mag. Lassen Sie uns oberflächlich untersuchen, wie der Prozess der Google-Absorption eines der externen Dienste angeordnet ist und was mit der Dienst-API und der Google-API geschieht.
Konten und Benutzer-ID
Neben Nutzern, die Google Mail verwenden und manchmal die Existenz von Google Plus erraten haben, gibt es auch eine Vielzahl von APIs für Entwickler, die von Konzepten wie der Konto-ID und der berüchtigten Benutzer-ID durchdrungen werden. userID ist die interne Kennung von Google, mit der Google-Dienste verstehen können, wer wer ist, und die alle internen Dienste miteinander verbindet. Es erscheint in vielen APIs und wir sehen, dass es von Dienst zu Dienst unverändert ist.
Nehmen wir ein Beispiel für die Übernahme eines externen Dienstes durch Google
Um SSO in einem neu aufgenommenen Dienst zu implementieren, können Sie natürlich nicht einfach Konten von der alten Datenbank in die neue "Google-Kontodatenbank" übertragen. Ich denke, das gibt es einfach nicht. Es gibt viele miteinander verflochtene Dienste, Interaktionsebenen, Verantwortungsketten. Service-Management-Services. Im Ernst, wenn Sie darüber nachdenken, sollte es viele, viele, sehr viele Ebenen von Verbindungen zwischen Google-Diensten geben, damit alles funktioniert.
Aber dann läuft es nicht so reibungslos - um G + bekannt zu machen, wurden Benutzer-ID-Benutzer verwendet, die Teil des globalen SSO-Dienstes sind.
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 nicht sehr kompliziert zu sein, die vorhandene Nutzerbasis des Dienstes an die "Allgemeinen Google" -Dienste anzupassen und Interaktionspunkte mit anderen Diensten zu erstellen, damit diese den neuen Dienst für ihre eigenen Zwecke nutzen können. Wir sprechen aber nicht über kleine Projekte - ein Unternehmen der Güte ist nicht klein und absorbiert Unternehmen im Wert von mehreren Millionen Dollar, die höchstwahrscheinlich bereits eine Infrastruktur aufgebaut haben, sonst könnten sie nicht zu ihrer Größe heranwachsen. Es ist daher sinnvoll, die Codebasis bzw. den Kern des Dienstes zu verlassen und die Eingabe- / Ausgabekanäle der Links des Dienstes zu wiederholen, damit sie mit denen von Google kompatibel werden.
Als nächstes wird der Dienst zu einem Google-Dienst. Nehmen wir an, dass es zu diesem Zeitpunkt bereits getestet wurde und als ziemlich vertrauenswürdige Personen von Google angesehen wird, die für die Integration verantwortlich sind. Der Spaß beginnt - der Service kann in andere Services integriert und / oder von Service zu Service übertragen werden.
Im Allgemeinen wäre dies 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) => Google Plus enthält Picasa (2011) => Google Fotos ist von G + (2015) getrennt => ...
Angesichts der Trägheit von Integrationsprozessen unterstützt Google in den meisten Produkten immer noch sehr alte APIs. Zum Zeitpunkt der Veröffentlichung dieses Artikels läuft die Picasa-API noch, seit Picasa ein eigenständiges Produkt war. Das heißt, wir kommen zu dem Schluss, dass Google bei der Integration von Picasa in seinen nächsten Dienst aus dem Original einen Zweig erstellt und den alten Brunch seinen eigenen Geräten überlassen hat, die API jedoch nicht geschlossen hat.
Und dann ist es Zeit, sich an den Grund für die Schließung von G + zu erinnern. Gemeldete Sicherheitsprobleme Tatsächlich können Sicherheitsprobleme aufgrund der Inkonsistenz verschiedener APIs sogar noch wahrscheinlicher sein.
Proof of Concept
Zum Beispiel gab es einmal einen PicasaWeb- Dienst, einen solchen Vorfahren moderner Google Fotos . Es wurde bereits 2016 ausgeschaltet . Laut dem Postscript am Ende des Posts hat die Service-API bisher jedoch weiter funktioniert. Es gibt bereits ein Enddatum für die Funktionsweise dieser API - den 15. März 2019 . Dieser Dienst ist insofern bemerkenswert, als Sie die Korrespondenz der E-Mail und der internen Benutzer-ID abrufen können. Wie kann dies für uns nützlich sein?
Zum Beispiel sind wir ein E-Mail-Bestätigungsdienst . In diesem Fall ist diese API für uns einfach ein Manna vom Himmel. Wenn wir die Google-Konto-ID von G + kennen, können wir einen Benutzernamen, ein Foto und häufig eine Vielzahl zusätzlicher Informationen erhalten. Die Frage ist, dass es normalerweise unmöglich ist, die Benutzer-ID einer Person zu kennen, wenn sie sich beispielsweise nicht auf unserer Website anmeldet.
In den alten PicasaWebAlbums konnten Benutzer jedoch Fotos in Webalben veröffentlichen, die an eine E-Mail gebunden waren. Daraus folgt, dass Sie mit der alten API das Profil einer Person per Benutzer-ID oder Benutzer-E-Mail abrufen können.
Lassen Sie uns überprüfen:
https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
- https://picasaweb.google.com/data/feed/api/user/ - tatsächlich der Endpunkt, auf dem die API lebt;
- nosov@nodeart.io - Die zu überprüfende Benutzer-E-Mail muss, wie wir sehen, hier nicht Google Mail sein. Google Apps-Nutzer haben Profile (was eine solche Prüfung für die Lead-Generierung sehr nützlich macht) sowie Personen, die ein Profil auf Google+ erstellt haben, indem sie ein persönliches Postfach eines dritten Dienstes, z. B. Yandex.ru, damit verknüpft haben.
- deprecation-extension = true - ein Hinweis darauf, was wir über das bevorstehende Ende der API wissen.
Wenn wir versuchen, eine nicht vorhandene E-Mail zu übertragen , erhalten wir eine klar interpretierte Antwort. Benutzer mit E-Mail noname@nodeart.io kann nicht gefunden werden, woraus wir eindeutig schließen können, dass es keine solche E-Mail gibt. Und noch mehr: Wenn wir versuchen , die Verteilergruppenadresse an die API zu senden , ändert sich die Antwort in Unbekannter Benutzer. Auf diese Weise können Sie persönliche Postfächer in G Suite von Mail-Weiterleitungen von Unternehmen unterscheiden.
Dies bedeutet nicht, dass es möglich ist, persönliche Informationen einer Person abzurufen, wenn sie diese nicht explizit veröffentlicht hat. Für die Massenvalidierung von Mailinglisten war eine solche API jedoch sehr geeignet
Wie hängt dieses Opportunitätsloch mit dem Schließen von G + zusammen? Schlussfolgerungen
Google nennt den Hauptgrund für die Schließung von G + -Sicherheitsproblemen genauer gesagt die Fähigkeit von Drittanbieterdiensten, Informationen von G + auf eine Weise zu empfangen, die ursprünglich nicht vollständig von Google selbst beabsichtigt und geplant wurde.
Zusätzlich zum Schließen von G + werden jetzt verschiedene APIs teilweise geschlossen. Um beispielsweise jetzt auf gmail.api zugreifen zu können, müssen Sie eine kostenpflichtige Prüfung im Wert von 15 bis 75.000 USD durchführen , wodurch diese API für die meisten Entwickler unzugänglich ist. Zitat:
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 im System der Interaktion zwischen Diensten verwirrt war, sodass die Aktionen, die früher ausgeführt werden konnten, indem einfach der gewünschte Umfang erreicht wurde, jetzt eine manuelle Validierung für 15 bis 75.000 USD und eine manuelle Aufnahme in erfordern Whitelist. Man kann nur raten, was mit undokumentierten Funktionen von mehr als einem reichen Ökosystem von Google-Diensten und insbesondere SSO-Diensten noch getan werden kann.
Um Mailinglisten qualitativ zu validieren, müssen wir noch nach neuen nicht standardmäßigen Anwendungen öffentlicher APIs suchen, daher werden wir weiterhin die Google \ Facebook-API und andere Dienste untersuchen. (Übrigens hatte Facebook bis vor kurzem eine ähnliche Möglichkeit, E-Mails zu validieren.)