O Google anunciou o fechamento da rede social Google+. É difícil encontrar uma publicação técnica que não seja mencionada ao passar pelo fim das ambições de mídia social do Google. Mas, infelizmente, é dada atenção à alta conectividade dos serviços de uma boa empresa. Neste artigo, gostaria de expressar meus pensamentos sobre como os serviços do Google interagem internamente e o que pode significar o fechamento do G + para usuários da API do Google.
Para o usuário final, a transição do Gmail para o Fotos e de lá para o Google Docs deve ser o mais perfeita possível - à primeira vista, os serviços são independentes e unidos por um único ponto de entrada de serviço altamente polido, o Logon único accounts.google.com . Mas nós, como desenvolvedores, sabemos que as palavras "fechar", "absorver", "integrar" têm mais significado (e mais trabalho) para as pessoas que estão desenvolvendo um produto do que parece à primeira vista. Vamos examinar superficialmente como o processo de absorção do Google por um dos serviços externos é organizado e o que acontece com a API de serviço e a API do Google.
contas e userID
Além dos usuários que usam o Gmail e às vezes adivinharam a existência do Google Plus, também há um grande número de APIs para desenvolvedores que são penetradas por conceitos como identificador de conta, o notório userID. userID é o identificador interno do Google, exatamente o que permite que os serviços do Google entendam quem é quem e é o que conecta todos os serviços internos. Ele aparece em muitas APIs e vemos que não é alterado de serviço para serviço.
Vamos dar um exemplo da absorção de um serviço externo pelo Google
Obviamente, para implementar o SSO em um serviço recém absorvido, você não pode simplesmente transferir e transferir contas do banco de dados antigo para o novo "banco de dados de Contas do Google" - acho que não existe isso - existem muitos serviços entrelaçados, níveis de interação, cadeias de responsabilidade, serviços de gerenciamento de serviços. Sério, se você pensar bem, deve haver muitos, muitos, muitos níveis de conexões entre os serviços do Google para que tudo funcione.
Mas então as coisas não correm tão bem - em um esforço para popularizar o G +, ele usou usuários de userID que fazem parte do serviço global de SSO.
De volta à tese. É necessário fazer alterações na API existente do lado absorvido da API e de outros serviços que agora podem começar a trabalhar com o novo serviço. Parece que não é nada super complicado adaptar a base de usuários existente do serviço aos serviços do "Google Geral", criar pontos de interação com outros serviços para que eles possam usar o novo serviço para seus próprios fins. Mas não se trata de pequenos projetos - a corporação do bem não é pequena e absorve empresas multimilionárias, que, provavelmente, já estabeleceram infraestrutura, caso contrário, não poderiam crescer em tamanho. Portanto, faz sentido deixar sua base de códigos, ou melhor, o núcleo do serviço e refazer os canais de entrada e saída dos links do serviço, para que se tornem compatíveis com o Google.
Em seguida, o serviço se torna um serviço do Google. Digamos que, neste momento, ele já tenha sido testado e considerado uma pessoa bastante confiável do Google, responsável pela integração. A diversão começa - o serviço pode ser integrado a outros serviços e / ou transferido de serviço para serviço.
Em geral, isso não seria assustador se não fosse a tendência do Google de alterar o registro de serviços.
Tome, por exemplo, fotografias.
Aplicativo de desktop do Picasa (2002) => Álbuns da web do Picasa - O Google adquire o Picasa (2004) => O Google Plus incorpora o Picasa (2011) => o Google Fotos é separado do G + (2015) => ...
Dada a inércia dos processos de integração, o Google ainda suporta APIs muito antigas na maioria dos produtos. No momento da publicação deste artigo, a API do Picasa ainda estava em execução a partir do momento em que o Picasa era um produto independente. Ou seja, concluímos que, quando o Google integrou o Picasa com seu próximo serviço, ele "criou uma ramificação" a partir do original e deixou o antigo "brunch" para seus próprios dispositivos, mas não fechou sua API.
E então é hora de lembrar o motivo do fechamento do G +. Problemas de segurança relatados, de fato, pode haver problemas de segurança ainda mais prováveis devido à inconsistência de diferentes APIs.
prova de conceito
Por exemplo, uma vez que havia um serviço PicasaWeb , um ancestral do moderno Google Fotos . Foi desativado em 2016 . Mas, de acordo com o postscript no final da postagem, a API de serviço continuou funcionando até agora. Já existe uma data final para esta API funcionar - 15 de março de 2019 . Este serviço é digno de nota, pois permite obter a correspondência do email e do ID do usuário interno. Como isso pode ser útil para nós?
Por exemplo, somos um serviço de verificação de e - mail . Nesse caso, essa API é simplesmente um maná do céu para nós. Conhecendo o ID da Conta do Google no G +, podemos obter um nome de usuário, uma foto e muitas vezes uma variedade de informações adicionais. A questão é que geralmente é impossível conhecer o ID do usuário de uma pessoa se, por exemplo, ele não fizer login no nosso site.
Porém, no antigo PicasaWebAlbums, as pessoas podiam postar fotos em álbuns da web vinculados a um e-mail. Na verdade, segue-se que a API antiga permite que você obtenha o perfil de uma pessoa por ID do usuário ou email do usuário.
Vamos verificar:
https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
- https://picasaweb.google.com/data/feed/api/user/ - na verdade, o ponto de extremidade em que a API vive;
- nosov@nodeart.io - o e-mail do usuário para verificar, como vemos, não precisa ser o gmail aqui. Os usuários do Google Apps têm perfis (o que torna essa verificação muito útil para geração de leads), além de pessoas que criaram um perfil no Google+, vinculando a ele uma caixa de correio pessoal de um terceiro serviço, por exemplo, Yandex.ru;
- deprecation-extension = true - uma indicação do que sabemos sobre o fim iminente da API.
Se tentarmos transferir um email inexistente , obteremos uma resposta claramente interpretada. Não foi possível encontrar o usuário com o email noname@nodeart.io, do qual podemos concluir inequivocamente que esse email não existe. E ainda mais - se tentarmos enviar o endereço do grupo de distribuição para a API , a resposta será alterada para Usuário desconhecido. Dessa maneira, você pode distinguir caixas de correio pessoais no G Suite de encaminhadores de email corporativos.
Isso não quer dizer que é possível extrair informações pessoais de uma pessoa se ela não as publicou explicitamente, mas para a validação em massa das listas de discussão, essa API foi muito apropriada.
Como esse buraco de oportunidade está relacionado ao fechamento do G +? Conclusões
O Google chama o principal motivo do fechamento dos problemas de segurança do G +, ou melhor, a capacidade de serviços de terceiros de receber informações do G + de maneiras que não são totalmente planejadas e planejadas inicialmente pelo próprio Google.
Agora, além de fechar o G +, há um fechamento parcial de diferentes APIs. Por exemplo, para acessar o gmail.api agora, você precisa passar por uma auditoria paga no valor de 15 a 75 mil dólares , o que torna essa API inacessível para a maioria dos desenvolvedores. Citação:
A taxa de avaliação é paga pelo desenvolvedor e pode variar de US $ 15.000 a US $ 75.000 (ou mais), dependendo do tamanho e da complexidade do aplicativo.
De fato, isso nos dá motivos para pensar que o Google ficou confuso no sistema de interação entre serviços, de modo que as ações que poderiam ser executadas anteriormente pela simples obtenção do escopo desejado agora exigem validação manual por 15 a 75 mil dólares e inclusão manual em lista de permissões. Só podemos adivinhar o que mais pode ser feito usando recursos não documentados de mais do que um rico ecossistema de serviços do Google e serviços de SSO em particular.
Para validar qualitativamente as listas de endereçamento, ainda precisamos procurar novos aplicativos não padronizados de APIs públicas, por isso continuaremos estudando a API do Google \ Facebook e outros serviços. (A propósito, até recentemente, o Facebook tinha uma maneira semelhante de validar e-mails.)