Google宣布关闭社交网络Google+。 很难找到甚至没有提及结束Google社交媒体野心的技术出版物。 但是，可惜的是，注意力集中在了一家优秀公司的服务之间的高度连接上。 在本文中，我想就Google服务如何在内部进行交互以及对Google API服务的用户关闭G +表示我的看法。
对于最终用户，从Gmail到照片，再从那里到文档的过渡应该尽可能无缝-乍一看，这些服务是独立的，并由一个高度修饰的服务入口点Single Sign-On account.google.com统一。 但是，作为开发人员，我们知道对于开发产品的人来说，“关闭”，“吸收”，“集成”一词的含义（和工作量）更多，乍一看似乎没有。 让我们从表面上研究一下Google吸收外部服务之一的过程是如何安排的，以及服务API和Google API的情况。
帐户和用户ID
除了使用Gmail且有时会猜测存在Google Plus的用户外，还为开发人员提供了大量的API，这些API会渗透到帐户标识符，臭名昭著的userID等概念中。 userID是Google的内部标识符，它可以使Google服务了解谁是谁，并且是将所有内部服务相互连接的用户。 它出现在许多API中，并且我们发现每个服务对它来说都没有改变。
让我们以Google吸收外部服务为例
显然，要在新吸收的服务中实施SSO，您不能仅将帐户从旧数据库中转移到新的“ Google帐户数据库”中-我认为没有这种东西-许多相互关联的服务，互动程度，责任链，服务管理服务。 认真地考虑一下，Google服务之间应该有很多很多层次的连接，以便一切正常。
但是事情进展得并不顺利-为了普及G +，它使用了属于全球SSO服务的userID用户。
回到论文。 有必要从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不一致，甚至可能存在更多的安全问题。
概念证明
例如，一旦有了PicasaWeb服务，便是现代Google Photos的祖先。 它于2016年关闭。 但是根据帖子末尾的帖子，到目前为止，服务API仍然可以正常工作。 该API的有效日期已经截止-2019年3月15日 。 该服务值得注意，因为它允许您获取电子邮件和内部用户ID的对应关系。 这对我们有什么用？
例如，我们是电子邮件验证服务 。 在这种情况下，对于我们来说，此API简直就是天堂。 从G +知道Google帐户ID后，我们可以获得用户名，照片以及各种其他信息。 问题是，例如，如果某人未登录到我们的网站，通常是不可能知道该人的userID的。
但是在旧的PicasaWeb相册中，人们可以将照片发布到与电子邮件绑定的网络相册中。 实际上，由此得出的结论是，旧的API允许您通过userID或用户电子邮件获取某人的个人资料。
让我们检查一下：
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）链接到Google+在个人资料上创建个人资料的人；
-deprecation-extension = true-表明我们对API即将结束的了解。
如果我们尝试传输不存在的电子邮件 ，则会得到明确解释的响应。找不到电子邮件为noname@nodeart.io的用户，从中我们可以明确地断定没有此类电子邮件。 甚至更多-如果我们尝试将通讯组地址发送到API ，则响应将变为“未知用户”。 这样，您可以将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仍采用类似的方式来验证电子邮件。）