Google shut down their social media platform Google+ on April 2, 2019. It’s hard to find some technical article that hasn’t mentioned the end of Google’s social network era. But, a high level of consistency in connectivity within services of the company had received scant attention. In this article I would like to share my thoughts on the internal way of Google services consistency and what it means for Google API users when it comes to a Google+ shutdown.
Google于2019年4月2日关闭了其社交媒体平台Google+。很难找到一些尚未提及Google社交网络时代结束的技术文章。 但是，公司服务内部连接的高度一致性受到关注。 在本文中，我想分享一下我对Google服务一致性的内部方式以及Google+关闭时对Google API用户的意义。
From a client’s point of view, the use of Gmail Photos and a further shift to Docs should be as clear as possible — at first glance, these services are independent and united within one platform that is a point of access called accounts.google.com. But as developers, we know, that terms “shutdown”, “takeover”, “integrate” involve great meaning (and also work) for those people, who take part in this process. So, let’s take a closer look at a process of Google’s one of the external services takeovers, and what’s going on with taken-over service API and Google API.
从客户的角度来看，应该尽可能清楚地使用Gmail照片以及进一步迁移到Google文档-乍一看，这些服务是独立的，并且在一个称为accounts.google.com的访问点的平台内统一在一起。 。 但是作为开发人员，我们知道，“停工”，“接管”，“整合”这两个术语对于参与此过程的人们而言具有巨大的意义(并且也可以工作)。 因此，让我们仔细看一下Google进行的一项外部服务收购的流程，以及接管服务API和Google API的情况。
帐号和用户ID (Account and userID)
Beside users who use Gmail and may heard of Google Plus, there is also a huge number of APIs for developers that include such things as account identifiers, the notorious userID. The userID is Google’s internal ID, this is the thing that helps Google services understand who is who. It appeared in many APIs, and we see that it has not changed from service to service.
除了使用Gmail并可能听说过Google Plus的用户外，还为开发人员提供了大量的API，其中包括诸如帐户标识符，臭名昭著的userID之类的东西。 userID是Google的内部ID，可以帮助Google服务了解谁是谁。 它出现在许多API中，并且我们发现它在服务之间并没有改变。
让我们仔细看看Google进行的外部收购的另一个示例 (Let’s take a closer look at another example of an external takeover performed by Google)
Chaos
混沌
Obviously, for the implementation of SSO in the newly absorbed service, you cannot simply take and transfer accounts from the old base to the new “Google accounts base”. I think there is simply no such thing — there are many intertwined services, levels of interaction, chains of responsibility, service management services. Seriously, if you think about it, then there must be many, many, many levels of connections between Google services for everything to work. But then everything goes not so smoothly — in an effort to popularize G+ it used the userID of users who are part of the global SSO service.
显然，为了在新吸收的服务中实施SSO，您不能简单地将帐户从旧基础帐户转移到新的“ Google帐户基础”。 我认为根本没有这样的东西-有许多相互关联的服务，交互级别，责任链，服务管理服务。 认真地说，如果您考虑一下，那么Google服务之间必须有很多很多层次的连接才能使所有功能正常工作。 但是随后一切都变得不太顺利-为了普及G +，它使用了属于全球SSO服务的用户的userID。
Let’s get back to the thesis. There is a need to make changes to the existing API from both the absorbed side of the API and from other services that can now start working with the new service. It would seem like nothing super complex — to adapt the existing user base of the service to “common google” services, to create points of interaction with other services so that they can use the new service for their own purposes. But this is not about small projects — a corporation of good does not waste time on trifles and absorbs multimillion-dollar companies, which, most likely, have already established infrastructure — otherwise, they could not grow to their scale. So, it makes sense to leave its code base, or rather, the core of the service, and redo the input-output channels of the service’s links so that they become compatible with Google. Then the service becomes a Google service. Let’s Suppose that at this moment it has already been tested and is considered to be quite trustworthy by the people from Google who are responsible for the integration. Here is the most interesting part — the service can be integrated into other services and/or transferred from service to service. In general, it would not be scary if it were not for Google’s tendency to change the registration of services. Take for example photos.
让我们回到本文。 有必要从API的吸收方面以及现在可以开始使用新服务的其他服务进行更改。 看起来没有什么超级复杂的-使服务的现有用户群适应“通用google”服务，创建与其他服务的交互点，以便他们可以将新服务用于自己的目的。 但这不是关于小项目的事情-一家好公司不会浪费时间在琐事上，而是吸收数百万美元的公司，而这些公司很可能已经建立了基础设施-否则，它们就无法发展到规模。 因此，保留其代码库(或更确切地说，服务的核心)并重做服务链接的输入输出通道以使其与Google兼容是有意义的。 然后该服务成为Google服务。 假设目前，它已经过测试，并且由负责集成的Google员工认为非常值得信赖。 这是最有趣的部分-服务可以集成到其他服务中和/或在服务之间转移。 通常，如果不是因为Google改变服务注册的趋势，那将不会令人恐惧。 以照片为例。
Picasa desktop application (2002) => Picasa Web Albums — Google acquires Picasa (2004) => Google Plus incorporated Picasa (2011) => Google Photos is separated from Google+ (2015) => …
Picasa桌面应用程序(2002)=> Picasa网络相册-Google收购了Picasa(2004)=> Google Plus合并了Picasa(2011)=> Google相册与Google+(2015)分离=>…
Considering the inertia of the integration process, in the majority of products, Google still supports very old APIs. At the time of publication of the article, the Picasa API is still working the way it did back to the time when Picasa was a separate product. That brings us to the conclusion that when Google integrated Picasa as their next service, they created a “branch” from the original product and left the old “branch” to the mercy of fate, but did not shut down its API.
考虑到集成过程的惯性，在大多数产品中，Google仍然支持非常古老的API。 在本文发表时，Picasa API仍可以像回到Picasa单独产品时那样工作。 这使我们得出以下结论：当Google将Picasa集成为他们的下一项服务时，他们从原始产品创建了一个“分支”，而将旧的“分支”交给了命运，但没有关闭其API。
And then it’s time to recall the reason for closing G +. It happened due to a reported security issue, but in reality, there can be even more security issues due to inconsistency in different APIs.
然后是时候回顾关闭G +的原因了。 发生这种情况的原因是报告了一个安全性问题，但实际上，由于不同的API不一致，可能还会出现更多的安全性问题。
Proof of concept
概念证明
For instance, there was a service called PicasaWeb — the predecessor of Google Photos. It is unavailable since 2016 but according to the note at the end of a post — its API still operates. The end date of this API is March 15, 2019. This service was noteworthy because it allowed getting email and internal userID match. How would it be useful?
例如，有一项名为PicasaWeb的服务-Google Photos的前身。 自2016年以来一直无法使用，但根据帖子末尾的注释-其API仍在运行。 该API的结束日期为2019年3月15日 。 该服务值得注意，因为它允许电子邮件和内部用户ID匹配。 有什么用？
In case we develop an email validator. In this case, this API would be a manna from heaven. Knowing an Account ID from G+ we can get the name of a user, photo, and even additional information. The trick is that you can’t get userID if this user never logged in to our website. But despite this, users were able to post pictures at web-albums that were linked with email using old PicasaWebAlbums. That suggested that old API allows getting to user’s account using userID or user’s email.
如果我们开发了一个电子邮件验证器 。 在这种情况下，此API可能是天堂里的甘露。 通过G +了解帐户ID，我们可以获得用户的姓名，照片甚至其他信息。 诀窍是，如果该用户从未登录过我们的网站，则无法获得userID。 但是尽管如此，用户仍可以使用旧的PicasaWebAlbums在与电子邮件链接的网络相册中发布图片。 这表明旧的API允许使用userID或用户的电子邮件访问用户的帐户。
Let’s check: https://picasaweb.google.com/data/feed/api/user/[email protected]?deprecation-extension=true
让我们检查一下： https : //picasaweb.google.com/data/feed/api/user/[email protected]?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ — API’s endpoint; [email protected] — user’s email for verification (as we can see, it is not required to use Gmail emails only). Users have Google Apps accounts (this fact helps to be the verification is useful concerning lead generation), users with Google+ accounts also have this (by linking a third-party email beforehand), for example, Yandex.ru deprecation-extension=true — the indication about an imminent API endpoint. If we will try to pass nonexistent email, we’ll get clear interpreted response: “Unable to find a user with email [email protected], that leads to the conclusion that this email is not valid. And even more — if we will try to send a group mailing address to the API the answer be “Unknown user”. It would then be possible to distinguish the difference between personal G-Suite emails and corporate emails. It’s hard to say that we can “catch” personal data this way if this data wasn’t shared by the user, but it was good for the global validation of user list via API.
https://picasaweb.google.com/data/feed/api/user/-API的端点； [email protected]用于验证的用户电子邮件(如我们所见，不需要仅使用Gmail电子邮件)。 用户拥有Google Apps帐户(这一事实有助于进行潜在客户验证)，拥有Google+帐户的用户也拥有此帐户(通过预先链接第三方电子邮件)，例如Yandex.ru deprecation-extension = true —有关即将到来的API端点的指示。 如果我们尝试传递不存在的电子邮件 ，则会得到清晰的解释响应：“无法找到电子邮件地址为[email protected]的用户，这将导致该电子邮件地址无效的结论。 甚至更多-如果我们尝试将群组邮寄地址发送到API ，答案将是“未知用户”。 这样就可以区分个人G-Suite电子邮件和公司电子邮件。 很难说，如果用户不共享这些数据，我们可以通过这种方式“捕获”个人数据，但这对于通过API对用户列表进行全局验证很有用。
那么，这种不精确性如何与Google+关闭相关联？ (So, how is this imprecision linked to Google+ shutting down?)
结论 (Conclusions)
The key reason to shut down Google+ was security lapse, more precisely, the ability to get data from Google+ by the services that weren’t planned and intended beforehand.
关闭Google+的主要原因是安全漏洞，更确切地说，是通过事先未计划和计划的服务从Google+获取数据的能力。
Besides Google+, partial shut down of various APIs is performed. For instance, you should pass payed audit to get access to gmail.api which makes this API unavailable for the vast majority of developers.
除Google+之外，还将部分关闭各种API。 例如， 您应该通过付费审核才能访问gmail.api ，这使绝大多数开发人员都无法使用此API。
Citation
引文
The assessment fee is paid by the developer and may range from $15,000 to $75,000 (or more) depending on the size and complexity of the application.
评估费由开发人员支付，视应用程序的大小和复杂性而定，可能在15,000美元至75,000美元(或更多)之间。
In fact, this gives us a reason to think that Google has become entangled in the system of interaction between services since the actions that previously could be performed simply by obtaining the required scope, now require manual validation for 15–75k USD and manual inclusion in the whitelist. It remains only to guess what else you can do using undocumented features of Google’s rich ecosystem of the services and the SSO service in particular.
实际上，这使我们有理由认为Google已纠缠于服务之间的交互系统，因为以前只需通过获取所需范围即可执行的操作，现在需要人工验证(需支付17.5万美元至7.5万美元)并包含在其中白名单。 只是猜测您可以使用Google丰富的服务生态系统(尤其是SSO服务)的未记录功能还能做什么。
In order to qualitatively validate mailing lists, we will need to look for new non-standard ways of public APIs usage, so we will continue to explore the Google \ Facebook API and other services. (By the way, Facebook until recently had a similar way of email validation.)
为了定性验证邮件列表 ，我们将需要寻找使用公共API的新的非标准方式，因此我们将继续探索Google \ Facebook API和其他服务。 (顺便说一下，直到最近，Facebook都采用了类似的电子邮件验证方式。)