Google объявила о закрытии социальной сети Google+. Трудно найти техническое издание, которое бы не упомянуло хотя бы вскользь о конце амбиций Google в области социальных сетей. Но, увы, вниманием обходится высокая связность сервисов компании добра. В этой статье я хотел бы выразить свои размышления на тему того, как взаимодействуют сервисы гугла внутри и что может означать закрытие G+ для пользователей API сервисов Google.
Для конечного пользователя переход от Gmail в Photos, а оттуда в Docs должен быть максимально бесшовным — с первого взгляда сервисы независимы и объединены единым, отполированным до блеска сервисом-точкой входа Single Sign-On accounts.google.com. Но мы как разработчики знаем, что слова «закрыть», «поглотить», «интегрировать» несут за собой больше смысла (и больше работы) для людей, которые занимаются разработкой продукта, чем может показаться на первый взгляд. Разберём поверхностно, как устроен процесс поглощения гуглом одного из внешних сервисов и что происходит с API сервиса и API Google.
accounts и userID
Помимо пользователей, которые пользуются Gmail и иногда догадывались о существовании Google Plus, есть ещё и огромное количество API для разработчиков, которые пронизаны насквозь такими понятиями, как идентификатор аккаунта, пресловутый userID. userID — это внутренний идентификатор Google, именно та вещь, которая даёт сервисам Google понять, кто есть кто, и является тем самым, что связывает все внутренние сервисы между собой. Он появляется во многих API, и мы видим, что он неизменен от сервиса к сервису.
Возьмём пример поглощения внешнего сервиса компанией Google
Очевидно, что для имплементации SSO в только что поглощённом сервисе нельзя просто взять и перенести аккаунты из старой базы в новую «базу аккаунтов Google» — думаю, просто не существует такого понятия, — есть множество переплетённых между собой сервисов, уровней взаимодействия, цепочек ответственности, сервисов по управлению сервисами. Серьёзно, если задуматься, то должно быть много, много, очень много уровней связей между сервисами Google для того, чтобы всё работало.
Но дальше всё идёт не так гладко — в стремлении к популяризации G+ она использовала userID пользователей, которые являются частью глобального SSO сервиса.
Вернёмся к тезису. Возникает потребность внести правки в существующий API со стороны как поглощаемой стороны API, так и со стороны других сервисов, которые теперь могут начать работать с новым сервисом. Казалось бы, ничего сверхсложного — адаптировать существующую базу пользователей сервиса к «общегугловским» сервисам, создать точки взаимодействия с другими сервисами, чтобы они могли использовать новый сервис для своих целей. Но речь идёт не о маленьких проектах — корпорация добра не мелочится и поглощает многомиллионные компании, у которых, вполне вероятно, уже налажена инфраструктура — иначе они не смогли бы вырасти до своих масштабов. Значит, имеет смысл оставить его кодовую базу, вернее, ядро сервиса, и переделать input-output каналы связей сервиса, чтобы они стали совместимыми с гугловскими.
Далее сервис становится сервисом Google. Допустим, что на этот момент он уже оттестирован и считается достаточно благонадёжным людьми из Google, отвечающими за интеграцию. Начинается самое интересное — сервис можно интегрировать в другие сервисы и/или переносить из сервиса в сервис.
В целом это не было бы страшно, если бы не тенденция гугла менять прописку сервисов.
Возьмём к примеру фотографии.
Picasa десктоп приложение (2002) => Picasa Web Albums — Google приобретает Picasa (2004) => Google Plus инкорпорирует Picasa (2011) => Google Photos отделяется от G+ (2015) => ...
Учитывая инертность процессов интеграции, в большинстве продуктов Google до сих пор поддерживает весьма старые API. На момент публикации статьи до сих пор работает API Picasa с тех времён, когда Picasa была отдельным продуктом. То есть мы приходим к выводу, что, когда Google интегрировала Picasa с очередным своим сервисом, она «создавала branch» от оригинала и оставляла на произвол судьбы старый «бранч», но не закрывала его API.
И тут самое время вспомнить о причине закрытия G+. Заявлено о проблемах с безопасностью, на самом же деле вероятных проблем с безопасностью может быть ещё больше, в связи с неконсистентностью разных API.
proof of concept
К примеру, когда-то был сервис PicasaWeb, такой себе предок современных Google Photos. Его выключили ещё в 2016-м году. Но согласно приписке в конце поста — API сервиса продолжило свою работу аж до сих пор. Уже есть конечная дата работы этого API — 15 марта 2019. Этот сервис примечателен тем, что позволял получить соответствие емейла и внутреннего userID. Как нам это может быть полезно?
Например, мы сервис верификации емейлов. В этом случае это API для нас просто манна небесная. Мы, зная Google Account ID из G+, можем получить имя пользователя, фотографию и часто разнообразную дополнительную информацию. Вопрос в том, что обычно узнать userID человека невозможно, если он, к примеру, не залогинится у нас на сайте.
Но в старом PicasaWebAlbums люди могли публиковать фото в веб-альбомах, которые привязывались к емейлу. Собственно, из этого следует вывод, что старое API позволяет получить профиль человека по userID или email пользователя.
Давайте проверим:
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 (что делает подобную проверку очень полезной для лидогенерации), а так же у людей, которые создали себе профиль в Google+, привязав к нему персональный ящик третьего сервиса, к примеру, Yandex.ru;
— deprecation-extension=true — указание о том что мы знаем о скором конце API.
Если мы попробуем передать несуществующий емейл, то получим вполне ясно интерпретируемый ответ Unable to find user with email noname@nodeart.io, из которого однозначно можно прийти к выводу, что такого емейла нет. И даже более — если мы попробуем отправить в API адрес группы рассылки, то ответ изменится на Unknown user. Таким образом можно отличить персональные ящики в G Suite от корпоративных ящиков пересыльщиков.
Нельзя сказать, что так можно вытащить персональную информацию человека, если он явно её не опубликовал, но для массовой валидации списков рассылки такое API было очень даже уместно
Как эта дыра возможность связана с закрытием G+? Выводы
Google называет основной причиной закрытия G+ проблемы безопасности, точнее, возможность сторонним сервисам получать информацию из G+ путями, не совсем предназначенными и запланированными изначально самим Google.
Сейчас, кроме закрытия G+, происходит частичное закрытие разных API. Например, для доступа к gmail.api теперь нужно проходить платный аудит стоимостью от 15 до 75к USD, что делает это API недоступным для большинства разработчиков. Цитата:
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.
По факту, это даёт нам повод подумать, что Google запутался в системе взаимодействия между сервисами, раз для того, чтобы те действия, которые раньше было можно совершать, просто получив нужный scope, теперь требуют ручной валидации за 15–75k USD и ручного включения в whitelist. Остаётся только догадываться, что ещё можно делать, используя недокументированные фичи более чем богатой на сервисы экосистемы Google и сервиса SSO в частности.
Для того, чтобы качественно валидировать списки рассылки, нам по прежнему нужно будет искать новые нестандартные применения публичных API, поэтому мы продолжим изучать API Google\Facebook и других сервисов. (Кстати, у Facebook до недавнего времени был схожий способ валидации емейлов.)
