GoogleはソーシャルネットワークGoogle+の閉鎖を発表しました。 Googleのソーシャルネットワーキングの野望の終わりを通過することさえ言及していない技術出版物を見つけることは困難です。 しかし、残念ながら、良い会社のサービスの高い接続性に注意が払われています。 この記事では、Googleサービスが内部でどのように相互作用するか、そしてGoogle APIユーザーにとってG +が終了することを意味する可能性があるという考えを述べたいと思います。
エンドユーザーにとって、GmailからPhotosへ、そしてそこからDocsへの移行は可能な限りシームレスでなければなりません。サービスは一見して独立しており、高度に洗練された単一のサービスエントリポイントSingle Sign-On accounts.google.comによって統合されます 。 しかし、開発者は、「閉じる」、「吸収する」、「統合する」という言葉は、一見すると思われるよりも、製品を開発している人々にとってより多くの意味（およびより多くの作業）を運ぶことを知っています。 Googleが外部サービスの1つを吸収するプロセスがどのように配置され、サービスAPIとGoogle APIで何が起こるかを表面的に調べてみましょう。
アカウントとユーザーID
Gmailを使用し、時にはGoogle Plusの存在を推測するユーザーに加えて、アカウントID、悪名高いuserIDなどの概念を浸透させた開発者向けのAPIも多数あります。 userIDはGoogleの内部識別子であり、Googleサービスが誰が誰であるかを理解できるようにするものであり、すべての内部サービスを相互に接続するものです。 多くのAPIに表示され、サービスごとに変更されていないことがわかります。
Googleによる外部サービスの買収の例をご覧ください
明らかに、新しく吸収されたサービスでSSOを実装するために、古いデータベースから新しい「Googleアカウントデータベース」にアカウントを取得して転送することはできません-私はそのようなことはないと思います-絡み合ったサービス、相互作用のレベル、責任の連鎖、サービス管理サービス。 真剣に考えてみれば、すべてが機能するためには、Googleサービス間に多くの、そして多くのレベルの接続があるはずです。
しかし、事態はそれほどスムーズに進みません。G+を普及させるために、グローバルSSOサービスの一部であるuserIDユーザーを使用しました。
論文に戻りましょう。 APIの吸収側と、新しいサービスでの作業を開始できる他のサービスの両方から、既存のAPIに変更を加える必要があります。 サービスの既存のユーザーベースを「一般的なGoogle」サービスに適合させ、他のサービスとのやり取りのポイントを作成して、新しいサービスを独自の目的で使用できるようにすることは、それほど複雑ではないようです。 しかし、これは小さなプロジェクトに関するものではありません。善良な企業は小さくはなく、おそらく数百万ドル規模の企業を吸収します。 そのため、コードベースまたはサービスのコアをそのままにして、サービスのリンクの入出力チャネルを再実行して、Googleとの互換性を確保することは理にかなっています。
次に、サービスはGoogleサービスになります。 この時点ですでにテストされており、統合を担当するGoogleの非常に信頼できる人々であると考えられているとしましょう。 楽しみが始まります-サービスを他のサービスに統合したり、サービス間で転送したりできます。
一般的に、Googleがサービスの登録を変更する傾向がなければ、これは怖くないでしょう。
例えば写真を撮ってください。
Picasaデスクトップアプリケーション（2002）=> Picasaウェブアルバム-GoogleがPicasaを買収（2004）=> Google PlusにPicasa（2011）を組み込む=> GoogleフォトはG +（2015）から分離されました=> ...
統合プロセスの慣性を考えると、ほとんどのGoogle製品は依然として非常に古いAPIをサポートしています。 この記事の公開時点では、Picasaがスタンドアロン製品であった頃からPicasa APIが実行されています。 つまり、GoogleがPicasaを次のサービスと統合すると、元の「ブランチ」を作成し、古い「ブランチ」を独自のデバイスに残したが、APIを閉じなかったと結論付けます。
そして、G +が閉じられた理由を思い出します。 報告されたセキュリティ問題は、実際には、異なるAPIの不整合により、セキュリティ問題がさらに発生する可能性があります。
概念実証
たとえば、かつては最新のGoogleフォトの祖先であるPicasaWebサービスがありました。 2016年にオフにされました。 しかし、投稿の最後にある追記によると、サービスAPIはこれまでのところ機能し続けています。 このAPIの動作終了日は既に2019年3月15日です 。 このサービスは、電子メールと内部ユーザーIDの通信を取得できるという点で注目に値します。 これはどのように役立つのでしょうか？
たとえば、私たちはメール検証サービスです。 この場合、このAPIは単に私たちにとって天国からのマナです。 G +からGoogleアカウントIDを知っていれば、ユーザー名、写真、そして多くの場合さまざまな追加情報を取得できます。 問題は、たとえば、彼が私たちのサイトにログインしていない場合、通常、その人のユーザーIDを知ることは不可能だということです。
しかし、古いPicasaWebAlbumsでは、人々はメールに関連付けられたウェブアルバムに写真を投稿できました。 実際、このことから、古いAPIでは、ユーザーIDまたはメールユーザーごとに個人のプロファイルを取得できます。
確認しましょう：
https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
-https://picasaweb.google.com/data/feed/api/user/-実際にはAPIが存在するエンドポイント。
-nosov@nodeart.io-確認するユーザーのメールは、ここでgmailである必要はありません。 Google Appsユーザーには、プロファイル（リード生成に非常に役立つチェック）と、Yandex.ruなどの3番目のサービスの個人用メールボックスにリンクしてGoogle+でプロファイルを作成したユーザーがいます。
-deprecation-extension = true-APIの差し迫った終了についてわかっていることを示します。
存在しない電子メールを転送しようとすると、明確に解釈された応答が返されます。電子メールnoname@nodeart.ioでユーザーが見つかりません。このような電子メールがないことを明確に結論付けることができます。 さらに- 配布グループのアドレスをAPIに送信しようとすると、応答はUnknown userに変わります。 このようにして、G Suiteの個人用メールボックスと企業メールフォワーダーを区別できます。
これは、明示的に公開しなかった場合、個人の個人情報を引き出すことが可能であると言うことではありませんが、メーリングリストの一括検証には、このようなAPIが非常に適切でした
この機会の穴は、G +の閉鎖とどのように関係していますか？ 結論
Googleは、G +セキュリティの問題が解消された主な理由、より正確には、サードパーティのサービスがGoogle自体によって完全に意図および計画された方法ではない方法でG +から情報を受信する能力を呼び出します。
現在、G +を閉じることに加えて、異なるAPIの部分的な終了があります。 たとえば、gmail.apiにアクセスするには、 15〜75k USDの価値のある監査を受ける必要があり 、ほとんどの開発者はこのAPIを利用できません。 引用：
評価料は開発者によって支払われ、アプリケーションのサイズと複雑さに応じて15,000ドルから75,000ドル（またはそれ以上）の範囲で変動します。
実際、これはGoogleがサービス間の相互作用のシステムで混乱したと考える理由になります。そのため、単に目的のスコープを取得するだけで前に実行できるアクションは、15〜75k USDの手動検証とホワイトリスト。 豊富なGoogleエコシステムサービスと特にSSOサービスのドキュメント化されていない機能を使用して、他に何ができるかを推測することしかできません。
メーリングリストを定性的に検証するために、パブリックAPIの新しい非標準アプリケーションを探す必要があります。そのため、Google \ Facebook APIおよびその他のサービスの調査を続けます。 （ところで、最近まで、Facebookには電子メールを検証する同様の方法がありました。）