Google Plus stops working. So what?

Google announced the closure of the social network Google+. It’s hard to find a technical publication that doesn’t even mention in passing the end of Google’s social media ambitions. But, alas, attention is paid to the high connectivity of the services of a good company. In this article, I would like to express my thoughts on how Google services interact inside and what the closure of G + for users of the Google API services may mean.

For the end user, the transition from Gmail to Photos, and from there to Docs should be as seamless as possible - at a glance the services are independent and united by a single, highly polished service-entry point Single Sign-On accounts.google.com . 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. Let us examine superficially how the process of Google absorption of one of the external services is arranged and what happens with 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 that are penetrated through concepts such as account identifier, the notorious userID. userID is Google’s internal identifier, the very thing that allows Google services to understand who is who, and is the one that connects all internal services to each other. It appears in many APIs, and we see that it is unchanged from service to service.

Let's take an example of the absorption of an external service by Google

Obviously, for the implementation of SSO in a newly absorbed service, you can’t just take and transfer accounts from the old database to the new “Google Accounts database” - I think there’s just no such thing — there are many intertwined services, levels of interaction, chains of responsibility, service management services. Seriously, if you think about it, there should be many, many, very many levels of connections between Google services in order for everything to work.

But then things do not go so smoothly - in an effort to popularize G +, it used userID users who are part of the global SSO service.

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 that it’s nothing super complicated to adapt the existing user base of the service to the “General 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 - the corporation of good is not small and absorbs multimillion-dollar companies, which, most likely, have already established infrastructure, otherwise they could not grow to their size. 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’s.

Next, the service becomes a Google service. Let’s say that at this point it’s already tested and considered to be quite trustworthy people from Google, responsible for integration. The fun begins - the service can be integrated into other services and / or transferred from service to service.
In general, this would not be scary if it were not for Google’s tendency to change the registration of services.
Take for example photographs.

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

Given the inertia of integration processes, Google still supports very old APIs in most products. At the time of publication of this article, the Picasa API is still running from the time Picasa was a standalone 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 its own devices, but did not close its API.

And then it's time to remember the reason for the closure of G +. Reported security problems, in fact, there may be even more likely security problems due to the inconsistency of different APIs.

proof of concept

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

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

But in the old PicasaWebAlbums, people could post photos to web albums that tied to an email. Actually, it follows from this that the old API allows you to get a person’s 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 the endpoint on which the API lives;
- nosov@nodeart.io - the user email to check, as we see, does not have to be gmail here. Google Apps users have profiles (which makes such a check very useful for lead generation), as well as people who have created a profile on Google+ by linking to it a personal mailbox of a 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 transfer a non-existent email , we will get a clearly interpreted response Unable to find user with email noname@nodeart.io, from which we can unequivocally conclude that there is no such email. And even more - if we try to send the distribution group address to the API , the response will change to Unknown user. In this way, you can distinguish personal mailboxes in G Suite from corporate mail forwarders.

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

How does this opportunity hole relate to closing G +? conclusions

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

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

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.

In fact, this gives us reason to think that Google got confused in the system of interaction between services, so that those actions that could be performed earlier by simply getting the desired scope now require manual validation for 15–75k USD and manual inclusion in whitelist. One can only guess what else can be done using undocumented features of more than a rich ecosystem of Google services and SSO service in particular.

In order to qualitatively validate mailing lists, we will still need to look for new non-standard applications of public APIs, so we will continue to study the Google \ Facebook API and other services. (By the way, until recently, Facebook had a similar way to validate emails.)