O Google acaba de publicar os primeiros resultados do Project Strobe, uma revisão de acesso de desenvolvedores a dados de contas Google e de dispositivos Android. O encerramento planejado do Google+ para consumidores chama atenção, mas a decisão mais relevante para tecnologia é outra: a empresa reconhece que permissões amplas, consentimento pouco granular e baixa visibilidade operacional criam um risco estrutural em APIs de plataforma.1
O caso envolvia um bug em uma das APIs People do Google+. Aplicativos podiam acessar campos de perfil compartilhados com o usuário, mas não marcados como públicos. O Google afirmou que corrigiu o problema em março de 2018, que os dados eram limitados a campos estáticos e opcionais e que não encontrou evidência de abuso. Ainda assim, a análise indicou potencial exposição de perfis de até 500 mil contas e uso da API por até 438 aplicações.1
A falha era também de desenho de produto
Incidentes de privacidade raramente são apenas bugs isolados. No caso do Google+, a baixa adoção do produto, a complexidade das APIs e a dificuldade de manter controles compreensíveis se somaram. Quando uma rede social não tem uso intenso, mas conserva integrações com dados sensíveis, o custo de governança cresce enquanto o valor percebido pelo usuário diminui.
Para equipes de produto, a lição é direta: superfície de API precisa acompanhar uso real, manutenção e clareza de consentimento. Um endpoint antigo pode continuar funcional por anos, mas isso não significa que continue justificável. Toda permissão concedida a terceiros vira dívida de segurança, documentação e auditoria.
Consentimento granular vira requisito de confiança
O Project Strobe também anuncia mudanças em permissões de contas Google. Em vez de agrupar várias solicitações em uma única tela, o Google passa a apresentar permissões de forma mais granular, permitindo que o usuário aceite uma e recuse outra. Essa mudança parece pequena na interface, mas altera a relação entre aplicativo, plataforma e usuário.
Consentimento agregado favorece a instalação rápida. Consentimento granular favorece entendimento. Em ambientes corporativos, a diferença é crítica: integrações de CRM, calendário, e-mail e arquivos devem pedir o mínimo necessário e explicar por que precisam de cada escopo.
APIs precisam de governança contínua
O anúncio também restringiu casos de uso permitidos para Gmail e reduziu o acesso a SMS, Call Log e dados de interação de contatos no Android.1 O padrão é claro: plataformas maduras caminham para escopos menores, revisão mais dura e menos tolerância a aplicativos que coletam dados por conveniência.
Para empresas que constroem software sobre plataformas externas, isso exige arquitetura resiliente a mudanças de política. Integrações devem prever revogação de permissões, revisão periódica de escopos, logs de consentimento e fallback quando uma API deixa de permitir determinado acesso.
O Project Strobe sinaliza uma mudança cultural. O modelo em que crescimento de ecossistema justifica acesso amplo passa a perder espaço para uma abordagem mais restritiva, auditável e centrada em confiança. Para times seniores, a pergunta deixa de ser apenas “a API permite?” e passa a ser “esse acesso ainda merece existir?”.