Entrar com o Google no gerador de foto: o que ele recebe antes da sua selfie

Três minutos antes de clicar em Continuar com o Google

A tela de consentimento fica na sua frente por poucos segundos e some. Ela é o único momento do fluxo em que você decide alguma coisa: depois dela, o serviço já tem o que pediu, e o que sobra são procedimentos de reparo. Este é o checklist que cabe no tempo em que ela está aberta, com o que fazer quando a resposta for ruim.

1. Leia o nome do app e o domínio no topo da tela. A autorização vale para aquele terceiro específico, não para uma marca ou para um grupo de sites. Se o domínio não é o do serviço em que você estava, feche tudo e volte digitando o endereço à mão.
2. Abra a política de privacidade linkada no pé da tela. A ajuda do Google diz onde ela fica com todas as letras: "Na parte de baixo da tela de permissão na primeira vez que você se conecta ao app usando o Fazer Login com o Google". Procure duas palavras dentro dela: retenção e exclusão. Se a página não abre, ou não fala de prazo, você está aceitando uma retenção que ninguém escreveu.
3. Conte as linhas de permissão. Nome, e-mail e foto do perfil são a base declarada pela ajuda do Google. Qualquer linha além disso, como contatos, agenda, arquivos na nuvem ou histórico de vídeo, é pedido extra de um gerador de imagem e merece um "para quê?" antes do clique.
4. Decida se a sua foto de perfil atual serve de ponto de partida. Num serviço que trabalha com rosto, a imagem que ele recebe no login costuma ser exatamente a que você entrou ali para substituir. Trocar a foto do perfil antes de criar a conta muda o que ele recebe.
5. Anote a data em que você autorizou. É o dado que falta na hora de pedir exclusão meses depois: sem ele, você não sabe qual versão da política valia quando os campos saíram da sua conta.
6. Procure o cadastro com e-mail antes de clicar no botão. Quase sempre ele existe, uma linha abaixo, escrito menor. Quando o login social é a única porta de entrada, isso também é uma informação sobre o serviço.

Os itens 2 e 3 são os que ninguém faz e os únicos que exigem parar. Se você não consegue responder aos dois, o custo de descobrir depois é uma imagem do seu rosto já entregue, com data que você não anotou.

Os campos que saem da sua conta, e um deles é o seu rosto

A página de ajuda que descreve o botão não deixa margem para interpretação. Ela escreve, em português: "Se clicar ou tocar nele, você autoriza o compartilhamento do nome, e-mail e foto do perfil da sua Conta do Google com o terceiro". É a página Como funciona o recurso Fazer Login com o Google, consultada em 23/08/2026.

A página irmã, que explica o compartilhamento por dentro, fecha a lista em três itens e ainda tira de você o poder de recusar um deles: "o Google só compartilha as seguintes informações associadas à sua conta: Seu nome / Seu endereço de e-mail / Sua foto do perfil", e logo abaixo, "Esses dados só são compartilhados com sua permissão. Se você usar o recurso Fazer Login com o Google, não vai poder excluir nenhum deles". A mesma página avisa que, além desses três, "o terceiro pode solicitar acesso a alguns dados da Conta do Google". Três é o piso, não o teto.

E há uma frase, na página sobre compartilhamento seguro de dados, que é o motivo deste artigo existir: "Se você ainda não tiver uma conta com um app ou serviço de terceiros, seu nome e sua foto do perfil poderão ser usados para criar uma". Traduzindo para o caso concreto: num gerador de foto, a sua conta pode nascer com uma imagem do seu rosto dentro dela, antes do primeiro upload. O que o serviço faz com essa imagem depois é outro assunto, vizinho de a foto de perfil que vira matéria-prima de treino da própria rede.

O campo tem nome, e o nome diz que é uma URL

No protocolo, esse campo se chama picture. A documentação do Google Identity para OpenID Connect define assim: "picture: The URL of the user's profile picture". Repare no primeiro substantivo. O serviço não recebe o arquivo da sua foto: recebe um endereço. Quem recebe endereço decide sozinho se abre, se baixa, se redimensiona, se guarda uma cópia e por quanto tempo. Essa diferença é a razão de a revogação resolver menos do que a palavra sugere.

Aqui mora uma divergência entre dois documentos oficiais da mesma empresa, e ela vale ser publicada inteira. A documentação de desenvolvedor diz que picture "Might be provided when: The request scope included the string 'profile'" e acrescenta "Note that this claim is never guaranteed to be present". A ajuda ao usuário, que é o texto que a pessoa comum encontra, afirma que o clique autoriza o compartilhamento da foto do perfil. Uma fala de possibilidade técnica, a outra de autorização. As duas são oficiais, as duas foram lidas em 23/08/2026, e a leitura prudente é a segunda: parta do princípio de que a foto vai.

Dá para conferir sozinho, sem conta e sem escrever código. Cada provedor publica um documento aberto com o que o login pode devolver. No documento de configuração do Google, lido em 23/08/2026, scopes_supported traz três itens (openid, email, profile) e claims_supported traz onze: aud, email, email_verified, exp, family_name, given_name, iat, iss, name, picture, sub. No documento equivalente do Linkedin, são doze, com locale a mais. Uma divergência menor que vale registrar: o exemplo publicado dentro da documentação de desenvolvedor do Google também lista doze, com locale, que não aparece no documento servido na data em que medi.

Do lado do Linkedin, a documentação oficial do login com OpenID Connect descreve o escopo profile como "Required to retrieve the member's lite profile including their id, name, and profile picture", com o e-mail em escopo separado. E o exemplo de resposta publicado ali entrega a foto no caminho profile-displayphoto-shrink_100_100, ou seja, uma miniatura de 100 por 100 pixels no exemplo do documento. Não é regra fixa de tamanho: é o que a documentação mostra.

A palavra foto não aparece em nenhuma das três descrições de permissão

Cada linha de permissão de um login tem um texto oficial, que o Google publica para descrever o escopo correspondente. Fui ler os três que valem para o login básico: nenhum deles escreve a palavra foto.

Os três escopos desse login são openid, userinfo.email e userinfo.profile, e o Google publica a descrição em português de cada um deles na referência de escopos do OAuth 2.0, lida em 23/08/2026:

• openid: "Associar suas informações pessoais a você no Google".
• userinfo.email: "Ver o endereço de e-mail principal da sua Conta do Google".
• userinfo.profile: "Ver suas informações pessoais, inclusive aquelas que você disponibilizou publicamente".

Contagem própria nas três descrições, na mesma data: a palavra foto aparece zero vez. Conferi também o original em inglês, porque as páginas de ajuda do Google avisam no rodapé que podem conter tradução automática. O texto de userinfo.profile em inglês é "See your personal info, including any personal info you've made publicly available", e ali também não há picture nem photo. A foto está embutida em "informações pessoais". Nomeada com todas as letras, ela só aparece nas duas páginas de ajuda da seção anterior, que ninguém abre no meio de um cadastro. E um limite desta medição, porque ele muda o que a frase acima autoriza dizer: o que eu li foi o texto que o Google publica para cada escopo, não uma captura da tela de consentimento de uma autorização real. Essa captura não foi feita, então não afirmo, palavra por palavra, o que a sua tela mostra.

Por que o aviso de app não verificado não alcança esse login

Existe uma segunda razão para o clique ser tão liso, e ela é de engenharia de plataforma. O Google classifica os escopos das próprias APIs em faixas, e nome, e-mail e foto do perfil ficam na primeira, a de escopo não sensível. A documentação de verificação de aplicativo é literal: "If your app utilizes only non-sensitive scopes, it is not mandatory for your app to complete the app verification process". Um serviço que só pede login, portanto, não é obrigado a completar a verificação, e o regime que produz a tela de alerta de aplicativo não verificado não alcança esse caso.

Duas réguas usam a mesma palavra e precisam ficar separadas: "não sensível" aqui é uma categoria de escopo de API, criada pelo Google para decidir quais aplicativos precisam ser verificados. Não é, e não deve ser lida como, a categoria de dado sensível de nenhuma legislação.

O contraste mostra o tamanho da diferença. Quando um aplicativo pede escopo sensível ou restrito e não completa a verificação, a página do Google Cloud sobre aplicativos não verificados diz que "your app will be limited to 100 new users until it is verified", exige "You must have a privacy policy URL" e manda "Verify your website ownership through Search Console". Nada disso alcança quem só pede nome, e-mail e foto. O login que entrega o seu rosto é justamente o que passa livre pela portaria.

Até o texto do botão é padronizado por documento. As diretrizes de marca do Fazer Login com o Google recomendam três chamadas: "Sign in with Google", "Sign up with Google" ou "Continue with Google", e autorizam traduzir esse texto para o idioma do aplicativo, que é de onde vem o "Continuar com o Google" que você lê em português. As mesmas diretrizes determinam que o botão "should be displayed at least as prominently as other third-party sign-in options". Não há conspiração nenhuma: a porta mais visível da tela de cadastro é a mais visível por regra escrita, e acontece de ser também a que entrega mais campos.

Vale creditar quem chegou perto na busca. Em um texto de março de 2025, o Olhar Digital registrou que o login "pode incluir nome, e-mail, foto de perfil e até mesmo dados mais sensíveis, dependendo das permissões concedidas". A frase está correta. Ela apenas não é desenvolvida em nenhum ponto do texto, e foi a única menção à foto que encontrei nas três páginas não oficiais que consegui abrir em 23/08/2026 sobre o assunto.

Testei as URLs da foto: o que respondeu e o que ficou sem teste

O que ninguém mede nessa conversa é o comportamento do endereço em si. Fiz isso em 23/08/2026, de uma máquina sem sessão em nenhum dos dois provedores, sem cookie, sem cabeçalho de autorização e sem referenciador. Os comandos são estes, e reproduzem em qualquer terminal:

# 1. endpoint de leitura do perfil, sem nenhuma credencial
curl -i https://openidconnect.googleapis.com/v1/userinfo

# 2. o mesmo endpoint, agora com um token inventado
curl -i -H "Authorization: Bearer token-invalido-de-teste" \
  https://openidconnect.googleapis.com/v1/userinfo

# 3. avatar padrão do Google, requisição anônima, dois tamanhos
curl -sI "https://lh3.googleusercontent.com/a/default-user=s96-c"
curl -sI "https://lh3.googleusercontent.com/a/default-user=s400-c"

# 4. mesma rota de imagem, com um identificador inventado
curl -sI "https://lh3.googleusercontent.com/a/xxxx=s96-c"

# 5. lista aberta do que cada provedor pode devolver no login
curl -s https://accounts.google.com/.well-known/openid-configuration
curl -s https://www.linkedin.com/oauth/.well-known/openid-configuration

Linha a linha, em português: o primeiro comando pergunta ao Google quem é o dono da sessão sem apresentar credencial nenhuma; o segundo repete a pergunta com um token inventado, para separar "sem token" de "token inválido"; o terceiro bloco pede a mesma imagem de avatar em dois tamanhos, mudando só o sufixo do endereço; o quarto repete a chamada com um identificador inventado, para separar resposta por credencial de resposta por caminho; os dois últimos baixam a lista pública do que cada provedor pode devolver no login, que é a base da tabela da seção anterior.

Os resultados, exatamente como voltaram:

• O canal de leitura é fechado por token. O endpoint de perfil devolveu 401 nas duas tentativas, com o corpo {"error":"invalid_request","error_description":"Invalid Credentials"}. Sem credencial válida, nada sai por ali.
• As URLs de imagem responderam sem credencial nenhuma. O avatar padrão do Google voltou 200 e image/png, com 567 bytes no sufixo s96-c e 2.186 bytes no sufixo s400-c. O tamanho entregue é parâmetro de quem pede, não do dono da foto.
• O host de imagem responde por caminho, não por credencial. Uma rota malformada no mesmo domínio devolveu 400, e não 401 nem 403.
• No Linkedin, o endereço carrega assinatura e validade. Colhi uma URL no padrão .../profile-displayphoto-shrink_100_100/...?e=...&v=beta&t=... a partir do HTML de uma página pública, e não publico o endereço porque ele identifica uma pessoa. Anônima, ela devolveu 200 e image/jpeg com 5.939 bytes. Sem os parâmetros de assinatura: 403. Trocando 100_100 por 800_800 e mantendo a assinatura: 403 também. E o parâmetro de validade daquela URL, e=2147483647, corresponde a 19/01/2038, que é o teto de um inteiro de 32 bits.

Agora a parte que o resto da internet resolve por dedução, e que aqui fica escrita com todas as letras: o ciclo completo de revogação com conta real não foi testado nesta apuração. Entrar com o Google num serviço de verdade, capturar a URL devolvida no campo picture daquela conta, revogar o acesso do aplicativo e pedir a mesma URL de novo exigiria uma conta pessoal e a autorização de um app de terceiro, e eu não fiz isso. Por isso você não vai ler aqui "revoguei e a foto continuou no ar".

O que dá para afirmar é a soma de duas coisas medidas. Revogar fecha a porta por onde o serviço lê o seu perfil de novo, e quem escreve isso é o próprio Google. E o endereço da imagem, nos dois hosts que testei, não se comportou como recurso protegido por token: os dois entregaram imagem para uma requisição que não apresentou nada. A medição vale para dois hosts, em uma data, com essas requisições, e não para "todo login social". Se a sua pergunta é sobre a cópia, ela não é para a tela de conexões do provedor: é para o serviço.

Revogar em cada provedor, com o rótulo real de cada tela

Tutoriais de terceiros ainda descrevem telas com nomes antigos e apontam para pelo menos um endereço de ajuda que já morreu, medido mais abaixo. Os caminhos a seguir saíram da documentação viva dos dois provedores, lida em 23/08/2026.

Na Conta do Google

1. Abra a página de vinculações da sua Conta do Google com terceiros, em myaccount.google.com/connections. Ela só funciona logada: uma requisição anônima ao endereço de conexões termina na tela de login do accounts.google.com, e isso não significa que a URL esteja errada.
2. Escolha a seção Fazer Login com o Google. A mesma tela separa três tipos de vinculação, que não são sinônimos: Fazer Login com o Google, Conta vinculada e Acesso à sua Conta do Google. Só o primeiro é o botão de cadastro.
3. Clique no aplicativo que você quer desconectar e depois em Ver detalhes.
4. Escolha Parar de usar o recurso Fazer Login com o Google e confirme.

Um detalhe de vocabulário que economiza busca: o corpo do artigo de ajuda sobre gerenciar vinculações usa a palavra vinculações, e os botões e links da página irmã usam conexões. É a mesma coisa; procure pelas duas. E o aviso que a própria página coloca em destaque, antes do passo final: "Importante: se você excluir essa vinculação, o Google vai interromper o login automático no app ou serviço. Essa ação não exclui seus dados no app ou serviço de terceiros".

No Linkedin

No computador, o caminho publicado na ajuda é: ícone Eu, depois Configurações e privacidade, depois Privacidade dos dados, seção Outros aplicativos, botão Alterar ao lado de Serviços permitidos, e então Remover. A página publica só esse caminho: em 23/08/2026, em nenhuma das versões de idioma que abri, ela trazia passo a passo para o aplicativo de celular. A página de ajuda sobre uso de dados por aplicativos de terceiros é explícita sobre o que fica para trás: "o proprietário do aplicativo pode reter os dados do Linkedin recebidos antes da alteração das configurações após você desvincular a sua conta do Linkedin do seu aplicativo e ele é responsável por utilizá-los adequadamente. Ele também é responsável por responder às solicitações para excluir os dados do Linkedin em seu poder".

Duas notas de campo sobre essa página. A primeira: o endereço de ajuda que aparece em tutoriais de terceiros, terminado em answer/a522031, devolveu 404 em todas as variantes de idioma que testei em 23/08/2026; a página viva é a de código a520877. A segunda: a própria página exibe "Última atualização: há 2 anos", um rótulo relativo que não vira data, o que é mais um motivo para registrar a data em que você leu.

E um recado do fornecedor que costuma escapar de quem integra esse login em produto: a documentação técnica do recurso avisa que ele "does not verify user identities and should not be marketed as such". Entrar com a rede profissional não prova que você é você; prova apenas que alguém tinha a sessão daquela conta aberta.

O que a revogação desfaz e o que ela não desfaz

A palavra revogar dá a impressão de que algo é desfeito. Ela desfaz um pedaço bem definido e deixa o resto exatamente onde estava. Os dois trechos que decidem isso estão publicados, e são do Google: "Se você remover a permissão, os apps e serviços de terceiros não poderão acessar nem compartilhar atualizações ou mudanças nas informações básicas do seu perfil, incluindo nome, e-mail e foto do perfil. Os dados que você já compartilhou não serão removidos". E, na mesma página: "Ao remover o acesso, o app ou serviço de terceiros pode manter as informações fornecidas quando você fez login na sua Conta do Google. Talvez seja necessário solicitar a exclusão dos dados que eles já têm".

Traduzindo para uma frase que cabe na cabeça: revogar corta a leitura futura, não a cópia. A tabela abaixo separa linha por linha o que muda e o que continua igual.

A página do Google termina mandando você para o lugar certo: quem exclui os dados é o terceiro, no canal dele. Esse é outro procedimento, com outra prova e outro prazo, e ele começa com a data que o item 5 do checklist mandou anotar. Se a curiosidade é sobre a camada de baixo, por onde o arquivo passa depois de entrar no serviço tem artigo próprio, e trata de infraestrutura, não de consentimento.

Permissão do celular e autorização de conta são duas coisas diferentes

As duas se chamam permissão, aparecem em telas parecidas e não têm nada em comum além do nome. Vale escrever a fronteira, porque é ela que faz gente revogar a coisa errada e achar que resolveu.

A permissão de galeria é do sistema operacional do aparelho: ela decide o que o aplicativo alcança nos arquivos que estão com você, e quem concede e retira é o telefone. É a régua de o que um aplicativo de foto enxerga dentro do seu aparelho. A autorização de login é do provedor da conta: ela decide o que o serviço recebe do Google ou do Linkedin, e esse conteúdo nunca passa pelo seu celular. Sai de um servidor e chega em outro.

A consequência prática é dura. Você pode cortar o acesso do aplicativo à galeria e o serviço continuar lendo o seu perfil no provedor; e pode desconectar o login e o aplicativo seguir com acesso total às fotos do telefone. São dois lugares de configuração, com dois donos diferentes, e nenhum dos dois mostra o outro. Se a sua preocupação é o outro extremo do fluxo, a imagem que sai do gerador e nasce visível para estranhos segue uma terceira régua, que também não está em nenhuma dessas telas.

Quando o cadastro com e-mail e senha ganha do botão

A regra de decisão cabe em três linhas, e nenhuma delas é "login social é perigoso".

• O botão ganha quando o seu problema é senha. Nenhuma senha sua vai para o serviço: o que trafega é um token do provedor, e a lista do que você autorizou fica reunida em uma tela só, do lado do Google ou do Linkedin. Para dezenas de cadastros banais, isso é uma melhora real de segurança.
• O cadastro com e-mail ganha quando o serviço processa o seu rosto. Aqui o custo do botão não é a senha: é entregar uma imagem sua antes de escolher qual imagem entregar, e deixar a conta nascer com essa imagem dentro.
• O caminho do meio é um endereço de e-mail dedicado a serviços de imagem, com senha única. Ele não esconde nada de ninguém e não é anonimato: serve para você saber, olhando a caixa de entrada, exatamente quais serviços têm alguma coisa sua.

Os limites honestos dessa regra. Trocar o botão por e-mail e senha só melhora alguma coisa se a senha for única: senha repetida é pior que login social, porque o vazamento de um serviço vira a chave de todos os outros. E, antes de revogar um login que já existe, confira se o serviço permite definir uma senha para a conta atual, senão a revogação te deixa do lado de fora da sua própria conta e das suas próprias imagens.

Vale lembrar que essa decisão vem colada em outra, e as duas costumam ser tomadas no mesmo minuto: qual ferramenta usar. As opções colocadas lado a lado antes de você criar conta em qualquer uma ajudam a não repetir esse cadastro em cinco serviços só para comparar resultado.

Sintoma, causa provável e correção

Quatro situações que chegam prontas, com o caminho e, principalmente, com o que cada caminho não resolve. A quarta linha é a única que não termina em uma tela de provedor, e é a mais importante.

Os limites desta leitura

O maior deles já apareceu e vale repetir com outras palavras: eu medi o comportamento de endereços de imagem sem credencial, não o efeito de uma revogação real sobre a URL de uma conta real. Ninguém deve sair daqui dizendo que "a foto continua acessível depois que você desconecta", porque essa frase exige um teste que não foi feito. Vale o mesmo para o outro lado da apuração: li o texto que o Google publica para cada escopo, não a tela de consentimento de uma autorização real, que não foi capturada aqui.

Outros provedores de login social podem servir imagem de outro jeito, com token, com expiração curta ou com bloqueio por origem: generalizar a partir de dois hosts medidos numa data seria repetir o vício que este artigo tenta corrigir.

Três ressalvas de leitura de documento. As páginas de ajuda do Google avisam no rodapé que podem conter conteúdo traduzido por inteligência artificial, então conferi os trechos centrais também na versão em inglês. Na ajuda do Linkedin, o parágrafo sobre acesso continuado por até um ano está sob o cabeçalho "Aviso aos usuários em países designados", que trata de portabilidade em outra jurisdição: não é regra geral e não foi usado aqui. E uma das cinco páginas da busca inicial, de uma fabricante de antivírus, devolveu 403 à leitura automatizada em 23/08/2026, então não afirmo nada sobre o conteúdo dela.

Por fim, o que este artigo não é: não é acusação a nenhum serviço nomeado. Tudo aqui é mecanismo publicado pelos próprios provedores, mais medição de HTTP que qualquer pessoa reproduz em um terminal. Um gerador de foto que recebe o campo picture está usando o login exatamente como ele foi desenhado para funcionar. O ponto é que quase ninguém sabe que é assim que ele funciona.

Resumo e próximos passos

O clique em Continuar com o Google entrega três informações da sua conta, e uma delas é o endereço de uma imagem do seu rosto. Nenhuma das três descrições de permissão publicadas pelo Google escreve a palavra foto; quem escreve são duas páginas de ajuda que ninguém abre no meio de um cadastro. Num serviço que trabalha com rosto, essa é a diferença entre um detalhe de protocolo e o começo do seu problema.

Revogar resolve um pedaço bem delimitado: corta a leitura futura do seu perfil e derruba o login automático. Não apaga a conta que nasceu, nem a cópia que o serviço tenha baixado, e os dois provedores escrevem isso com todas as letras. O que resolve cópia é pedido de exclusão feito ao serviço, com a data em que você autorizou na mão.

O próximo passo depende de onde você está. Se ainda não criou conta em lugar nenhum, use os seis itens do checklist e decida entre botão e cadastro com e-mail com a régua da seção de decisão. Se já entrou, comece pela lista de vinculações para descobrir o tamanho real da coisa. E, para o resto do caminho, o guia deste pilar continua do cadastro em diante, com a escolha de ferramenta, o envio das selfies e o que fazer com o arquivo que sai do outro lado.