Google Plus stops working. So what?

Google announced the closure of the social network Google+. It is difficult to find a technical publication that would not have mentioned, at least briefly, the end of Google’s ambitions in the field of social networks. But, alas, attention is paid to the high connectivity of the company's good services. In this article, I’d like to express my thoughts on how Google’s services interact inside and what can mean the closure of G + for users of the Google Services API.

For the end user, the transition from Gmail to Photos, and from there to Docs, should be as seamless as possible - at first glance, the services are independent and combined with a single, single-polished Single Sign-On accounts.google.com entry point. But we, as developers, know that the words “close”, “absorb”, “integrate” carry more meaning (and more work) for people who are developing a product than it might seem at first glance. We’ll sort out superficially how the process of Google’s absorption of one of the external services is arranged and what happens to the service API and the Google API.

accounts and userID

In addition to users who use Gmail and sometimes guessed about the existence of Google Plus, there is also a huge number of APIs for developers, which are imbued with such concepts as account identifiers, the notorious userID. The userID is the internal identifier of Google, the very thing that makes Google services understand who is who, and is the one that binds all internal services together. It appears in many APIs, and we see that it is unchanged from service to service.

Take the example of the absorption of external service by Google

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 “base of Google accounts” - 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.

Let's return 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, nothing supercomplex - to adapt the existing user base of the service to “common-law” 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 good corporation 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. 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. The most interesting begins - 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.

Picasa desktop app (2002) => Picasa Web Albums - Google acquires Picasa (2004) => Google Plus incorporates Picasa (2011) => Google Photos is separated from G + (2015) => ...

Given the inertia of the integration process, in most products, Google still supports very old APIs. At the time of publication of the article, the Picasa API is still working from the time when Picasa was a separate product. That is, we conclude that when Google integrated Picasa with its next service, it “created a branch” from the original and left the old “brunch” to the mercy of fate, but did not close its API.

And then it's time to recall the reason for closing G +. A security issue has been reported, but in reality there can be even more likely security issues due to inconsistency in different APIs.

proof of concept

For example, once there was a PicasaWeb service, such an ancestor of modern Google Photos . He turned off in 2016, the year . But according to the postscript at the end of the post - the service API has continued its work even now. There is already an end date for this API to work - March 15, 2019 . This service is noteworthy because it allowed us to get email and internal userID correspondence. How can this be useful to us?

For example, we are the email verification service . In this case, the API for us is simply manna from heaven. We, knowing the Google Account ID from G +, can get a username, a photo, and often a variety of additional information. The question is that it’s usually impossible to find out the person’s userID if he, for example, does not log in to our website.

But in the old PicasaWebAlbums, people could post photos in web albums that were tied to an email. Actually, it follows from this that the old API allows you to get a person profile by userID or user email.

Let's check:
https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
- https://picasaweb.google.com/data/feed/api/user/ - actually endpoint on which the API lives;
- nosov@nodeart.io - user email for verification, as we see, there is not necessarily gmail. Google Apps users have profiles (which makes such a check very useful for lead generation), as well as people who have created a Google+ profile for themselves, linking to it a personal box of the third service, for example, Yandex.ru;
- deprecation-extension = true - an indication of what we know about the imminent end of the API.

If we try to send a non-existent email , we get a quite clearly interpretable answer Unable to find user with email noname@nodeart.io, from which one can definitely come to the conclusion that there is no such email. And even more - if we try to send the address of the distribution group to the API , the answer will change to Unknown user. In this way, personal suite in G Suite can be distinguished from corporate inbox mailboxes.

This is not to say that it is possible to pull out a person’s personal information if he has not explicitly published it, but such an API was very appropriate for mass validation of mailing lists.

How does this hole opportunity relate to the closure of G +? findings

Google calls the main reason for the closure of G + security problems, more precisely, the ability of third-party services to receive information from G + in ways not entirely intended and planned by Google itself.

Now, besides closing G +, there is a partial closure of different APIs. For example, to access gmail.api, you now need to undergo a paid audit costing from 15 to 75k USD , which makes this API inaccessible to most developers. Quote:

The appraisal fee can be paid from $ 15,000 to $ 75,000 (or more) depending on the size and complexity of the application.

In fact, this gives us a reason to think that Google has become entangled in the system of interaction between services, in order for those actions that previously could be performed simply by obtaining the required scope, now require manual validation for 15–75k USD and manual inclusion in whitelist It remains only to guess what else you can do using undocumented features of the more than Google-rich ecosystem of the services and the SSO service in particular.

In order to qualitatively validate the mailing lists, we still need to look for new non-standard applications of public APIs, 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.)