Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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.
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 Single Sign-On 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.
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.
Letâs take a closer look at another example of an external takeover performed by GoogleChaos
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.
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.
Picasa desktop application (2002) => Picasa Web AlbumsâââGoogle acquires Picasa (2004) => Google Plus incorporated Picasa (2011) => Google Photos is separated from 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.
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.
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?
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.
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/âââAPIâs endpoint;
- nosov@nodeart.ioâââ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 noname@nodeart.io, 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.
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.
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.
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.
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.
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.)
Google+ is Dead. So what? was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.