phishtriage

PhishTriage — Política de Privacidade

Esta é uma tradução de cortesia da Política de Privacidade do PhishTriage para o português do Brasil. A versão juridicamente vinculante é a versão em inglês, disponível em phishtriage.com/privacy. Em caso de divergência entre a tradução e o texto em inglês, prevalece o texto em inglês.

Em vigor a partir de: 4 de outubro de 2026 Versão: 1.10 Aplica-se a: extensão de navegador PhishTriage (Chrome, Edge, Firefox, Brave, Safari) versão 1.1.0 e posteriores, e serviços de backend padrão em https://api.phishtriage.com e — somente com a proteção de arquivos ativada — https://filescan.phishtriage.com.

Esta linha antes terminava no Brave, embora a seção sobre proteção de arquivos, mais abaixo, tratasse o Safari como uma plataforma que o recurso não alcança. Uma versão que distribuímos estava ausente da lista de versões que esta política abrange; por isso ela passa a constar aqui, com as duas diferenças: a versão para Safari não tem proteção de arquivos nem política de administrador. O Safari não implementa as APIs de download de que a primeira precisa nem o armazenamento gerenciado por meio do qual a segunda é entregue; assim, toda frase deste documento sobre proteção de arquivos, e toda frase sobre o que um administrador pode definir para uma frota gerenciada, descreve as outras quatro versões e não esta.

Um segundo cliente acessa o mesmo backend, e até a versão 1.5 nenhuma versão deste documento dizia isso. O api.phishtriage.com também atende o filtro de mensagens do PhishTriage no iOS, que envia mensagens de texto para obter um veredito. Ele não é a extensão de navegador, e nada na extensão consegue ler suas mensagens em nenhuma plataforma. Mas é o mesmo proxy, o mesmo caminho de análise e a mesma equipe responsável pela operação, e uma superfície inteira que transporta conteúdo não estava descrita em lugar nenhum. Agora ela está descrita aqui, em Mensagens de texto. Essa seção trata do filtro de mensagens e não pretende ser uma política completa do aplicativo para iOS.

Resumo

Este parágrafo costumava oferecer “um número para lembrar: activeTab como a única permissão obrigatória”. O manifesto dentro do pacote que um revisor baixa diz o contrário, então aqui está a lista real.

Obrigatórias na instalação: activeTab, storage, scripting e, a partir da versão 1.1.0 da extensão, alarms, que permite que a extensão acorde sozinha para perguntar de novo sobre um pedido de registro que o backend ainda não respondeu (veja ID pseudônimo) — mais acesso aos cinco hosts de e-mail (mail.google.com, outlook.office.com, outlook.office365.com, outlook.live.com, outlook.cloud.microsoft), que a extensão declara como padrões de correspondência estáticos de script de conteúdo e que, por isso, seu navegador concede quando você a instala, listando-os no aviso de instalação. O quinto, o endereço web mais novo do Outlook, é novo na versão 1.1.0 da extensão; por isso a atualização para a 1.1.0 pede esse acesso: o Chrome e o Edge mantêm a extensão desativada até você aceitar. Até a versão 1.8, este parágrafo listava quatro hosts.

Opcionais, solicitadas somente quando você ativa o recurso que precisa delas, e revogáveis nas configurações de extensões do navegador — chrome://extensions → PhishTriage → Detalhes → Permissões no Chrome, no Edge e no Brave, about:addons → PhishTriage → Permissões no Firefox: webNavigation para a opção Background protection, downloads para a proteção de arquivos e <all_urls> para qualquer um dos dois — os dois recursos pedem essa permissão, e ativar apenas um deles basta para que você receba o pedido de acesso a todos os sites. Com nenhum dos dois ativado, nunca é solicitado nenhum acesso a hosts além dos cinco hosts de e-mail acima. Até a versão 1.9, este parágrafo chamava a opção Background protection de “threat monitoring”.

Quem somos

O PhishTriage é operado pela equipe do PhishTriage. Para dúvidas sobre privacidade, pedidos de exclusão de dados ou qualquer outro assunto tratado neste documento, escreva para privacy@phishtriage.com.

O controlador (para os fins do GDPR / UK GDPR) é a equipe do PhishTriage. Se sua organização implantou a extensão com um proxy de hospedagem própria (veja “Hospedagem própria” abaixo), o controlador é a sua organização — e não nós — e este documento descreve apenas o comportamento do lado do cliente; pergunte à sua equipe de TI ou ao encarregado (DPO) qual é a política correspondente deles.

O que a extensão coleta e quando

Quando você clica em “Analyze” (triagem sob demanda)

Clicar no botão Analyze no pop-up, no painel lateral ou na barra de ferramentas do Gmail ou do Outlook Web é o que faz a página ou a mensagem à sua frente ser lida e enviada para obter um veredito. Quando você clica, a extensão lê a aba — por meio da permissão activeTab em uma página comum, e por meio do script de conteúdo já carregado nos cinco hosts de e-mail, que não precisa de activeTab — e envia uma requisição ao proxy configurado (por padrão, api.phishtriage.com) contendo:

Os dados enviados também incluem seu ID pseudônimo (veja abaixo) e, se você registrou ou vinculou uma conta, o ID da sua extensão. O proxy repassa esse conteúdo a um modelo e devolve um veredito estruturado (pontuação de risco, IOCs, ações recomendadas). Qual modelo, e no hardware de quem, é explicado em Onde a análise acontece.

Este parágrafo dizia “o proxy encaminha uma versão sanitizada deste conteúdo à API Claude da Anthropic para análise”, e as duas metades precisam de correção. A primeira metade é o roteamento: a Anthropic já não é a primeira consultada e muitas vezes nem é consultada. A segunda metade é a palavra sanitizada, que carregava uma implicação que não consegue sustentar. Ela dá a entender que removemos algo em seu benefício. O que ela de fato nomeia é uma etapa que remove marcadores de injeção de prompt — [INST], <|…|>, delimitadores de turno do Claude, tags <system> semelhantes a XML e linhas que começam como uma instrução (“IGNORE ALL PREVIOUS…”) — antes que um modelo leia o conteúdo, além dos limites de tamanho indicados acima. Ela existe para impedir que um e-mail hostil dê ordens ao analista. Ela remove esses padrões e, quando uma linha começa como um deles, leva consigo o resto dessa linha. Três mudanças menores também são feitas. No corpo de um e-mail, as longas sequências de caracteres invisíveis que newsletters colocam depois da linha de pré-visualização, para que a prévia da caixa de entrada não mostre o corpo, são condensadas; ninguém que lê o e-mail as vê. Nos campos exibidos em uma única linha, como o remetente, o assunto, os links e os nomes dos anexos, uma quebra de linha vira um espaço. Essas duas estão no que o modelo lê e na requisição que armazenamos. A terceira é feita apenas na cópia que o modelo lê, e não no que armazenamos: quando a mensagem contém qualquer um dos dois títulos que colocamos acima das nossas próprias constatações para o modelo, “Facts about the message” e “Precomputed technical signals”, essa cópia o marca com “(quoted)”, para que o texto da mensagem não possa se passar pelo nosso. Nada é removido por dizer respeito a você: nenhum endereço, nenhuma URL e nenhum nome é eliminado por motivo de privacidade. O que chega ao modelo é o que está listado acima, menos os marcadores de injeção e esse enchimento, com essas quebras de linha como espaços e esses títulos marcados.

Se você não clicar em Analyze, nenhum texto de página é lido nem enviado para um veredito do botão Analyze. A opção Background protection e a opção Send full URLs (enviar endereços completos), na seção Advanced (avançado), ainda podem enviar o nome do host ou a URL atual para um veredito de ameaça, e a proteção de arquivos pode processar downloads, como descrito abaixo.

O botão Analyze não é a única coisa que envia, e esta seção costumava dizer que era. Além das verificações de visita mencionadas há pouco, três coisas enviam, e cada uma tem sua própria seção abaixo. Com a proteção de arquivos ativada, cada arquivo que você baixa é lido no seu dispositivo e uma impressão digital dele — com seu nome, seu tamanho e os motivos por trás do nosso veredito — é enviada, e, com a opção “Deep scan every file” (verificação profunda de todos os arquivos) ativada, o próprio arquivo é enviado; nada disso espera por um clique. A partir da versão 1.1.0 da extensão, um arquivo que uma página constrói dentro do navegador é a exceção: para ele, a impressão digital e o arquivo só são enviados quando uma pessoa iniciou esse download (veja a seção sobre proteção de arquivos). A captura de evidências, que fica ativada a menos que você a desative, envia uma captura de tela e o HTML quando uma análise resulta em phishing ou suspeito — da página, em uma página da web, e somente da mensagem analisada nos hosts de e-mail. E, desde a versão 1.7, os dois botões abaixo de um veredito, Looks safe to me e Looks dangerous, enviam sua resposta quando você clica em um deles; veja Suas correções a um veredito. Até a versão 1.7, este parágrafo citava duas coisas, porque esses botões não enviavam nada. A frase acima dizia “nada na página sai do seu dispositivo”, frase escrita antes de a proteção de arquivos ser lançada e que deixou de ser verdade quando ela foi — um arquivo blob: que uma página constrói é, por qualquer leitura, algo que está na página.

Essa frase costumava ser seguida por outra, “a extensão não roda em páginas em que você não pediu que ela rodasse”, que nunca foi verdade para os hosts de e-mail e tampouco é para a proteção de arquivos. Código que roda não é o mesmo que dados que saem, e a versão honesta da parte sobre o que roda é:

Quando você opta pelo rastreamento de visitas a URLs ou domínios

Para você, esses recursos vêm desativados por padrão. No pop-up, eles são a opção Background protection (proteção em segundo plano), que faz o rastreamento por domínio, e, na seção Advanced (avançado), a opção Send full URLs (enviar endereços completos), que faz o rastreamento por URL. Se você ativar qualquer uma delas ali ou na página de boas-vindas da primeira instalação, o Chrome (ou o seu navegador) pede permissão para “ler seu histórico de navegação” (webNavigation) e para “ler e alterar todos os seus dados nos sites que você visita” (<all_urls>). Você pode recusar o pedido, e nesse caso o interruptor volta para desativado.

Em uma frota gerenciada, essas duas opções não cabem a você, e esta seção costumava ficar em silêncio sobre isso. Um administrador pode forçar qualquer uma delas a ficar ativada — ou desativada — com as chaves de política trackVisits e trackDomains, e um valor forçado prevalece sobre o pop-up: a configuração que você salva é lida de volta com o valor da política por cima dela, de modo que desativá-la não muda nada do que é enviado. O rastreamento forçado de URLs significa que a URL completa de cada navegação do frame principal, string de consulta incluída, vai para o proxy a cada página que você carrega — e, a partir da versão 1.1.0 da extensão, também cada endereço para o qual uma página passa sem carregar um novo documento, como descrito abaixo. O pop-up de fato mostra a você quando é esse o caso — um controle definido por um administrador é desenhado com um selo Managed (gerenciado) e não pode ser alterado, e um aviso no topo da seção ⚙ Settings informa isso. A partir da versão 1.1.0 da extensão, forçar a ativação de qualquer uma delas não a inicia por si só: nada é verificado ou enviado até você conceder a permissão webNavigation do navegador, que o pop-up, e a página de boas-vindas na instalação, pedem que você conceda. O documento informava essa imposição pela política no caso da proteção de arquivos, da verificação profunda e da captura de evidências, e antes da versão 1.4 não a citava em lugar nenhum para o rastreamento de visitas, que é justamente o lugar em que uma pessoa tem mais probabilidade de supor que a opção é dela.

Com o rastreamento de visitas a domínios ativado, toda vez que você navega para uma nova página, o nome do host (por exemplo, example.com) é enviado ao endpoint /visit do proxy com o tipo domain. A URL completa não é enviada. A partir da versão 1.1.0 da extensão, uma página é verificada assim que o navegador começa a exibi-la, e não quando termina de carregar, de modo que uma página que nunca termina de carregar também é verificada.

Por padrão, o nome do host é enviado a cada navegação. Um cache local opcional — desativado por padrão, ativado na seção Advanced do pop-up — lembra as respostas. A partir da versão 1.1.0 da extensão, um site considerado seguro não é consultado de novo por uma hora. Um sinalizado como perigoso é consultado de novo após 15 minutos, e uma nova visita antes disso mostra o aviso de novo sem consultar. Uma verificação que não obteve resposta não fica em cache, e por isso a próxima visita consulta de novo. Até a versão 1.0.0 da extensão, o cache limita isso a no máximo uma vez por hora por domínio, não importa quantas páginas você carregue nele, qualquer que tenha sido a resposta.

Com o rastreamento de visitas a URLs ativado, a URL completa (incluindo o caminho, a string de consulta e qualquer coisa depois de um #, como o seu navegador informa) é enviada a cada navegação do frame principal, com o tipo url. A partir da versão 1.1.0 da extensão, ela também é enviada quando uma página muda seu endereço sem carregar um novo documento (history.pushState, history.replaceState ou uma mudança depois do #), uma requisição por vez para cada página, para o endereço mais recente para o qual ela passou. Até a versão 1.9, este parágrafo não citava nem a parte depois do # nem essas mudanças. Esta é a opção mais invasiva; nós a distribuímos desativada por padrão por um motivo. Ative-a somente se você quiser inteligência de ameaças no nível da URL completa.

Os dois endpoints respondem com um veredito de ameaça. A partir da versão 1.1.0 da extensão, se o proxy sinaliza uma URL ou um domínio como perigoso, a extensão substitui a página por uma página de aviso própria, na mesma aba. O botão Go back to safety (voltar à segurança) volta pelo histórico da aba quando se sabe que isso leva para além da página sinalizada e, caso contrário, abre a página de nova aba do seu navegador. Escolher continuar para o site carrega a página sinalizada uma vez, somente nessa aba: a extensão lembra esse único endereço para essa única aba, na memória de sessão do navegador e nunca em disco, até a próxima vez que o navegador começar a exibir uma página nessa aba, a aba ser fechada ou passarem dois minutos, o que ocorrer primeiro. O endereço da própria página de aviso leva o endereço sinalizado, e por isso o endereço sinalizado fica no histórico do seu navegador, como a própria página sinalizada já ficava. Até a versão 1.0.0 da extensão, um aviso intersticial em tela cheia é desenhado sobre a própria página sinalizada; você pode escolher voltar ou prosseguir mesmo assim.

Quando você opta pela proteção de arquivos (acesso antecipado)

A proteção de arquivos vem desativada por padrão. Ela está disponível no Chrome, no Edge, no Brave (que executa a versão para Chrome) e no Firefox, e não no Safari, que não implementa as APIs de download de que ela precisa. Ativá-la pede duas permissões juntas: downloads e acesso a todos os sites. As duas são necessárias — a parte que detecta um arquivo que uma página constrói dentro do navegador lê o conteúdo da página, de modo que conceder apenas downloads cobriria menos do que esta seção descreve. Quando um administrador forçou a ativação da proteção de arquivos, a partir da versão 1.1.0 da extensão ela não roda até você ter concedido as duas, e o pop-up, e a página de boas-vindas na instalação, pedem que você faça isso.

Por padrão, o arquivo em si fica no seu dispositivo. Esta linha dizia “nenhum arquivo e nenhuma parte de nenhum arquivo sai do seu dispositivo”, e a segunda metade disso não era verdade: um dos motivos curtos que enviamos com a impressão digital nomeia um arquivo encontrado dentro de um arquivo compactado que você baixou, de modo que um pouco do que há no arquivo pode viajar com ela. O que é enviado está descrito dois parágrafos abaixo. Quando você baixa um arquivo que a página criou (um download blob: ou data: — o formato usado para fazer arquivos passarem escondidos pelos filtros de e-mail), a extensão lê os bytes dele na memória do seu navegador, verifica-os ali (é um executável disfarçado de documento? um arquivo do Office com macro? um executável dentro de um arquivo compactado?) e avisa você — ou, no modo de bloqueio, retém o download e pergunta antes. Esses bytes são descartados logo depois da verificação e nunca são gravados em lugar nenhum pela extensão.

O que é enviado por padrão: uma impressão digital SHA-256 do arquivo (um hash de 64 caracteres), o nome e o tamanho do arquivo, o veredito da própria extensão e os motivos curtos por trás desse veredito. A impressão digital é comparada com impressões digitais de malware conhecido. Um hash tem 32 bytes e não pode ser revertido para o seu arquivo — ele nos permite reconhecer um arquivo que já sabemos ser malicioso sem nunca ver o seu. Os motivos são, em sua maioria, frases fixas que a extensão escreveu (“runnable script (.js)”, “Office document with an embedded macro”), e alguns citam o nome ou a extensão do próprio arquivo, que são enviados de qualquer forma. Um deles cita algo que não é: o nome de um executável encontrado dentro de um arquivo compactado que você baixou. Baixe invoice.zip com payload-for-acme.exe dentro dele e esse nome interno é enviado com a impressão digital, sem o arquivo e sem que outra opção precise ser ativada. Os motivos estavam ausentes desta lista até a versão 1.4, o que fazia a frase “nenhuma parte de nenhum arquivo” acima parecer verdadeira.

A partir da versão 1.1.0 da extensão, só enviamos algo sobre um arquivo que uma página constrói quando uma pessoa iniciou o download. Isso significa o seu próprio clique no link, ou um clique que a página faz enquanto o seu clique ainda está ativo; um navegador mantém um clique ativo por cerca de cinco segundos, de modo que uma página cuja exportação demora mais que isso para ser preparada conta como tendo iniciado o download por conta própria. Um arquivo que uma página salva por conta própria ainda é verificado no seu dispositivo, retido no modo de bloqueio e acompanhado de aviso, mas nem a impressão digital nem o arquivo são enviados. Downloads comuns não são afetados. Até a versão 1.0.0 da extensão, essa distinção não é feita.

Toda verificação que chega ao verificador de arquivos deixa um registro conosco, inclusive a verificação padrão, que não envia arquivo algum: a impressão digital, o nome do arquivo (até 300 caracteres) e o tamanho, o veredito, qual verificação o deu, o mecanismo da verificação profunda ou o nome da assinatura de malware com a qual houve correspondência, quando houve, seu pseudoId e o extensionId do dispositivo, quando ela foi feita e a data em que o registro será excluído. O registro recebe sua data de exclusão quando é gravado, do mesmo modo que seus registros de verificação e de visita; a única exceção são as verificações de arquivos feitas antes de começarmos a dar uma data a cada registro, que receberam 365 dias (veja Retenção). O botão “Delete my scan history” o remove. Um arquivo que uma página salva por conta própria, que é verificado somente no seu dispositivo, não deixa registro aqui. Seu próprio painel no portal não o mostra. Em uma equipe, o proprietário o vê na lista Scans (verificações) da página Team (equipe) do portal, exceto em uma organização no modo de relatório agregado, em que essa lista é omitida. Até a versão 1.9, este documento não descrevia esse registro e dizia que guardávamos “apenas a impressão digital e o veredito”.

Enviar um arquivo de fato é uma escolha separada, arquivo por arquivo. Quando uma verificação é inconclusiva, o aviso pode oferecer o botão “Check it properly” (verificar com mais atenção). Um arquivo é enviado somente se você clicar nesse botão, e só para esse arquivo. Ele é verificado na memória pelo nosso próprio verificador, no nosso próprio hardware, o veredito é devolvido e o arquivo não é armazenado — guardamos apenas o registro da verificação descrito acima.

A menos que você ative a opção “Deep scan every file”. Essa configuração vem desativada por padrão e muda a regra acima: com ela ativada, cada arquivo que você baixa é enviado a nós para uma verificação completa de malware assim que chega, e não apenas aqueles sobre os quais você pergunta. Cada arquivo continua sendo verificado na memória e continua não sendo armazenado — guardamos o mesmo registro da verificação, como antes —, mas o arquivo em si sai do seu dispositivo todas as vezes, exceto, a partir da versão 1.1.0 da extensão, um arquivo que uma página construiu e salvou por conta própria, como descrito acima. Ela existe para pessoas e organizações que querem tudo verificado; se não é o seu caso, deixe-a desativada e nada é enviado a menos que você peça. Um administrador pode exigi-la para uma frota gerenciada por meio de política.

Downloads comuns (um link normal, um arquivo que um servidor envia) também estão cobertos, mas de outra forma: o navegador não entrega a uma extensão os bytes de um download desse tipo, e por isso a extensão busca o endereço do arquivo uma segunda vez para lê-lo, verifica-o na memória da mesma forma e o descarta. Consequências práticas, ditas com clareza: o arquivo é transferido duas vezes, e um link de download de uso único pode falhar nessa segunda busca — caso em que a verificação recorre ao nome e ao tipo do arquivo. A reputação da URL é verificada no seu dispositivo, em uma lista de ameaças que a extensão baixa; o endereço do que você baixa não é enviado a lugar nenhum para ser consultado.

O que este recurso não faz: ele não lê arquivos que já estão no seu disco, não monitora sua pasta de Downloads e não consegue impedir um download comum antes de ele ser salvo — nenhuma extensão de navegador consegue. Para esses casos, ele avisa depois que o arquivo chega e oferece excluí-lo.

O que a extensão guarda no seu próprio dispositivo

Esta subseção surgiu na versão 1.4. O documento descrevia o que recebemos e nunca descrevia o que fica com você, e nomeava exatamente uma chave de armazenamento — pseudoId — de um modo que parecia ser a lista inteira. Manter essas cópias localmente não aciona, por si só, nenhuma transmissão; quando um valor listado também é enviado, a seção correspondente abaixo diz isso. Esta lista é apresentada porque são dados sobre você que existem por você ter instalado nossa extensão, e porque as vias de exclusão mais adiante agem em nossos servidores e não alcançam o perfil do seu navegador.

A partir da versão 1.1.0 da extensão, ela também guarda três coisas na memória de sessão do navegador, que nunca é gravada em disco e some quando o navegador é fechado:

Suas configurações em si ficam em chrome.storage.sync, e não no armazenamento local, o que significa que o seu navegador as copia para a sua Conta do Google ou conta Mozilla junto com o resto do seu perfil, se você tiver a sincronização do navegador ativada. São estados de opções, não conteúdo.

Guarda de evidências de páginas de phishing

Esta configuração vem ativada, a menos que você a desative. Ela é mostrada a você durante a configuração e fica no pop-up, na seção ⚙ Settings, onde você pode desativá-la a qualquer momento. Com ela desativada, nada do que é descrito nesta seção jamais acontece. Um administrador pode defini-la de um jeito ou de outro para uma frota gerenciada com a chave de política evidenceCapture.

Ela é uma de duas coisas no PhishTriage que vêm ativadas antes de você mexer em qualquer coisa, e é por isso que é descrita aqui por inteiro, e não resumida. A outra, desde a versão 1.7, é que sua resposta a um veredito é enviada quando você clica em um dos dois botões abaixo dele; isso não envia nada até você clicar, e tem sua própria seção abaixo. Até a versão 1.7, este parágrafo dizia que a captura de evidências era a única, o que era verdade enquanto esses botões não enviavam nada. Ela costumava ser descrita como a única coisa que envia sem ter sido ativada antes, e essa é uma afirmação diferente e falsa: a política de um administrador pode ativar a opção Background protection, a proteção de arquivos e a opção “Deep scan every file” para uma frota gerenciada, sejam quais forem as suas opções (a partir da versão 1.1.0 da extensão, as duas primeiras então esperam até você conceder a permissão do navegador de que cada uma precisa), e o registro — descrito em ID pseudônimo — acontece sozinho na instalação, antes de existir uma configuração sobre a qual ter opinião.

Um veredito diz que uma página ou uma mensagem era phishing. Ele não prova isso ao registrador de domínios, ao provedor de hospedagem ou ao provedor de e-mail que de fato pode agir. Esta configuração existe para produzir algo sobre o qual eles possam agir.

O que é capturado em uma página da web. Duas coisas, e somente estas duas: uma captura de tela da parte visível da aba (um JPEG — o que você viu, e o que uma vítima teria visto) e o HTML da página como estava no seu navegador (o que a página realmente é: o formulário que coleta a senha, o endereço para o qual ele envia os dados, o código que ela carrega). O que é capturado nos hosts de e-mail é mais restrito e está descrito abaixo.

Quando. No momento em que você clica em Analyze — antes de o veredito existir — porque uma captura de tela feita mais tarde seria do que quer que a aba tivesse passado a mostrar, e anexar a página errada a um pedido de retirada do ar é pior do que não anexar nada. Os dois itens são então mantidos somente na memória da extensão, durante os poucos segundos que a verificação leva. Nenhum dos dois é gravado em disco, no armazenamento do navegador ou em qualquer outro lugar da sua máquina.

Se é enviado. Somente se essa verificação resultar em phishing ou suspeito. Com qualquer outro veredito, os dois são descartados e nenhum deixa o seu dispositivo. Nada é capturado em páginas chrome://, na Chrome Web Store ou em páginas de outras extensões, porque o navegador recusa.

Nos hosts de e-mail, a mensagem que você analisou e nada ao redor dela. O caminho de e-mail são cinco nomes de host, e não uma regra sobre e-mail; essa foi a correção mais importante da versão 1.4, e por isso é dita por extenso. O caminho de e-mail são exatamente estes cinco hosts:

Nesses cinco, nunca é feita uma imagem da aba inteira. Ela seria da sua caixa de entrada — a lista de mensagens, os e-mails de outras pessoas, suas pastas e sua conta —, que é a coisa mais sensível que este recurso poderia capturar e não ajuda em nada a denunciar phishing. Se o veredito resultar em phishing ou suspeito, o que recebemos em vez disso é a mensagem que você analisou, sozinha:

O endereço da mensagem na sua caixa de correio não é enviado com ela. Se a extensão não consegue encontrar a mensagem na página, ou não consegue recortar a imagem para ela, não envia nada, em vez de uma imagem mais ampla. Seu navegador só deixa a extensão fazer a captura quando você abriu o PhishTriage pela barra de ferramentas do navegador para essa aba, ou quando você deu a ela acesso a todos os sites, o que a ativação da opção Background protection ou da proteção de arquivos pede; um clique no botão do PhishTriage dentro do Gmail ou do Outlook, por si só, não captura nada.

Até a versão 1.8, esta seção dizia que absolutamente nada era capturado no caminho de e-mail. A versão 1.1.0 da extensão é a primeira a capturar a mensagem, e a primeira a conferir o endereço da aba com a lista antes de fazer qualquer imagem, de modo que uma página em um desses cinco hosts nunca é capturada inteira, mesmo que a extensão não a tenha reconhecido como e-mail. Até a versão 1.8, a lista também tinha quatro hosts e deixava de fora outlook.cloud.microsoft, o endereço web mais novo do Outlook, de modo que o Outlook lido nesse endereço se enquadrava no parágrafo seguinte, como uma página da web comum.

Webmail em qualquer outro lugar é tratado como uma página da web comum. A verificação é uma comparação de nomes de host, e não um julgamento sobre se você está lendo e-mail. Portanto, se você usa o Yahoo Mail, o Proton Mail, o Fastmail, o Zoho Mail, o Roundcube ou o Outlook Web Access próprio da empresa onde você trabalha, em um domínio da empresa — qualquer coisa que não seja um dos cinco hosts acima —, então clicar em Analyze em uma mensagem ali é clicar em Analyze em uma página da web. Se o veredito resultar em phishing ou suspeito, recebemos:

Esta é a configuração distribuída. A captura de evidências fica ativada, a menos que você a desative, e “suspeito” — a classe de veredito que este documento chama, em outro ponto, de onde ficam os falsos positivos — basta para acioná-la. Nada disso exige que você tenha optado por ela.

Para desativá-la: abra o pop-up do PhishTriage, clique no botão ⚙ Settings (configurações) e desative a opção Keep evidence of phishing. Com ela desativada, nada desta seção acontece em lugar nenhum, em nenhum host. Se você lê e-mail em um provedor que não é um dos cinco acima, essa opção é a que você deve conferir.

Este parágrafo dizia “nada nunca é capturado no caminho de e-mail”, e só isso, e a frase foi escrita quando o Gmail e o Outlook eram os únicos serviços de e-mail para os quais o produto já tinha sido direcionado. Ela soava como uma promessa sobre e-mail. Nunca foi mais do que uma promessa sobre uma lista de nomes de host, e a distância entre essas duas coisas é a caixa de entrada de alguém. O esquema de política corporativa da própria extensão descrevia o comportamento corretamente — “webmail em qualquer outro host conta como página da web” — enquanto este documento o negava; estamos corrigindo o documento, e não o esquema.

Duas ressalvas honestas. Suspeito é onde ficam os falsos positivos, então, com esta opção ativada, você pode enviar uma página que acaba se revelando perfeitamente legítima — é por isso que páginas suspeitas são mantidas por um tempo muito menor, e por isso que um revisor que diz que não era phishing a exclui na hora —, embora dentro de uma organização essa revisão seja recusada enquanto a janela de atividade estiver ocultando as informações, que é o estado padrão dela; veja a seção de retenção. E o HTML geralmente não contém o que você digitou, porque os valores digitados ficam em uma propriedade e não na marcação da página, mas uma página pode gravá-los de volta na marcação, então geralmente é a palavra honesta.

Por quanto tempo é mantida. Não pelo período do histórico de verificações abaixo, que diz respeito ao seu próprio histórico de verificações. A evidência diz respeito a um terceiro e é mantida em um prazo próprio, qualquer que seja o período que vale para as suas verificações:

Quem pode vê-la, e como. Se você faz verificações individualmente, somente você. Se sua conta pertence a uma equipe, então todos da equipe — as mesmas pessoas que já podem ver que a verificação ocorreu.

Ela aparece no portal em uma lista própria, Phishing Evidence (evidências de phishing), no painel, ao lado da verificação de que veio, enquanto essa verificação ainda existe. A lista é a parte que importa, porque a evidência pode durar mais que a verificação de que veio: depois que a rotina de limpeza remove o registro da verificação, a captura continua lá, e a lista é como você chega a ela para vê-la, baixá-la ou excluí-la. Este parágrafo dizia que a evidência era visível “na verificação a que pertence”, e durante a metade mais longa da vida de uma captura de 12 meses isso não era verdade para nada em que você pudesse clicar.

Exceto em uma organização no modo de relatório agregado, em que a lista é omitida para todos. O modo agregado é aquele em que toda organização começa. Nele, uma lista de capturas é atividade por pessoa como qualquer outra, e por isso o portal recusa toda a superfície — não apenas a visualização. Ninguém, nem o proprietário, nem a pessoa cujo próprio dispositivo fez a captura, pode abrir a lista Phishing Evidence, baixar uma captura de tela ou o código-fonte da página, confirmar uma captura, rejeitá-la ou excluir uma única. Este documento admitia apenas a metade da visualização e deixava intacto, ao lado dela, o trecho “vê-la, baixá-la ou excluí-la”.

Quem pode excluí-la. Dentro de uma equipe, confirmar ou rejeitar uma captura é uma ação do proprietário — e somente onde a organização usa o modo de relatório por pessoa; no modo agregado, conforme o parágrafo acima, ninguém pode. O que funciona em todos os modos é excluir as suas próprias: o botão “Delete my scan history” descrito em Retenção remove toda captura armazenada na sua conta, inclusive aquelas cujo registro de verificação já expirou, e nenhuma função na organização pode fazer isso com você nem desfazê-lo.

Esse botão é limitado à sua conta, e não ao seu hardware. Este documento dizia que ele removia “toda captura feita nos seus próprios dispositivos”, que é um conjunto diferente: uma captura que o seu dispositivo fez antes de você vinculá-lo à sua conta foi gravada sob a identidade anterior própria desse dispositivo, e o botão não a alcança. Essa é a mesma ressalva que a seção Retenção já faz para os registros de verificação e de visita, e ela vale também para as capturas.

O código da própria página nunca é executado. O HTML armazenado de uma página hostil é tratado como hostil: nunca é renderizado no nosso portal, apenas baixado como um arquivo inerte, e é servido como texto simples para que abrir o link não possa executá-lo. A captura de tela é uma imagem e é conferida como tal antes de ser armazenada — um arquivo que não é de fato uma imagem é recusado.

Suas correções a um veredito

Esta seção foi acrescentada na versão 1.7. Abaixo de cada veredito, o painel lateral mostra dois botões, ✓ Looks safe to me e ⚠ Looks dangerous. Até a versão 1.6, eles guardavam sua resposta no seu dispositivo e não enviavam nada. Agora eles também enviam sua resposta a nós, e esse é o padrão. Nada é enviado até você clicar em um deles: o clique é o único gatilho, e um veredito ao qual você não responde não gera relato.

Não há opção para isso no pop-up. Uma organização pode desativar o envio para sua frota gerenciada com a chave de política feedbackUpload definida como false, e a resposta passa então a ficar somente no dispositivo, como antes. A versão para Safari não tem política de administrador (veja o início deste documento), então nela o envio não pode ser desativado dessa forma. Se você não quer que uma correção seja enviada, não clique nos botões.

O que a extensão envia. Uma pequena requisição ao api.phishtriage.com por clique, contendo:

Nada da própria página ou da própria mensagem vai junto: nenhum texto, nenhum título, nenhum remetente, nenhum destinatário, nenhum assunto. Como toda outra requisição da extensão, ela também leva a credencial de dispositivo com a qual a extensão se registrou, que é como sabemos de qual dispositivo e de qual conta um relato veio. Um dispositivo que não se registrou não consegue enviar um; recusamos o relato em vez de guardar um relato que não pode ser atribuído a ninguém.

Um relato feito sobre um e-mail nunca leva a localização da mensagem. No Gmail e nos quatro hosts do Outlook citados em Guarda de evidências de páginas de phishing, o endereço no seu navegador identifica a sua caixa de correio e a mensagem que você tem aberta, e por isso a extensão o omite do relato. Até a versão 1.8, este parágrafo dizia que a extensão lia outlook.cloud.microsoft como uma página da web comum e omitia o endereço ali do mesmo jeito; agora ele é um dos hosts de e-mail. Se mesmo assim chegasse um relato com um endereço em um desses cinco hosts, ou com qualquer endereço vindo do complemento do Google Workspace, que não nos envia nenhum, descartaríamos o endereço antes de armazenar ou encaminhar qualquer coisa. Webmail em qualquer outro host é uma página da web para a extensão, exatamente como na captura de evidências, e por isso um relato que você faz ali leva o endereço dessa página. A cópia mantida no seu dispositivo não é o relato: ela guarda o endereço completo de onde quer que você tenha clicado no botão (veja O que a extensão guarda no seu próprio dispositivo).

O que guardamos. Uma linha por relato, no banco de dados que guarda o seu histórico de verificações:

O endereço em si nunca é armazenado. Seu endereço IP também não: o endereço da requisição é usado apenas na memória, para limitar quantos relatos podem chegar de um mesmo endereço em uma hora, e o dispositivo tem um limite próprio. O log da aplicação não registra relatos. Ele recebe uma linha apenas quando algo dá errado com um deles — um endereço descartado, uma linha que não pôde ser gravada — e, na primeira vez após uma reinicialização em que um relato traz um endereço, uma observação de que nenhuma chave para o hash está configurada. Nenhuma dessas linhas traz o endereço, o seu pseudoId ou o seu endereço IP (veja O log da aplicação). Um relato não é enviado a nenhum modelo nem a nenhum terceiro.

Por quanto tempo. Em um prazo próprio de 90 dias, qualquer que seja o período que vale para o seu histórico de verificações: a rotina de limpeza de retenção exclui os relatos mais antigos que isso, várias vezes por dia, e o botão “Delete my scan history” do portal exclui de uma só vez todos os relatos armazenados na sua conta. A ressalva descrita em Retenção, para registros que um dispositivo fez antes de você vinculá-lo à sua conta, vale também para os relatos. Os prazos mais longos da evidência não se aplicam a eles. Até a versão 1.9, este parágrafo punha os relatos no mesmo prazo de 90 dias do seu histórico de verificações, o que era um único prazo enquanto o histórico de verificações tinha apenas um período.

Quem pode vê-lo. Nenhuma página do portal mostra um relato — nem a você, nem aos proprietários da sua organização, nem a ninguém. Os relatos são lidos apenas por nós, no banco de dados. Um pedido de acesso (veja Seus direitos) devolve os seus junto com o restante dos seus registros.

O que chega ao hub de inteligência. Por padrão, nada. Encaminhar relatos ao hub é uma opção separada do nosso lado, desativada na configuração distribuída e, na data de vigência indicada no início deste documento, desativada no serviço hospedado. Inteligência de ameaças compartilhada descreve o hub e exatamente o que um relato encaminhado leva, e cada linha registra se o seu relato foi encaminhado.

O que a extensão nunca coleta

Dois destes itens trazem ressalvas agora, e o título deve ser lido junto com elas, e não por cima delas. Cada um nomeia uma coisa específica que a extensão não tem mecanismo para obter; nenhum deles é uma promessa de que nada desse tipo jamais chega a nós por outro caminho, e onde existe um caminho o item o diz.

Mensagens de texto (PhishTriage para iOS)

Esta seção surgiu na versão 1.5. Ela cobre uma superfície que nenhuma versão anterior mencionava — pesquisar a versão 1.4 por “SMS” ou “text message” não retorna nada, embora o backend tivesse um endpoint para elas o tempo todo. Nada nela foi uma mudança de comportamento. Ela fechou uma lacuna no documento, e a maior que essa versão fechou.

Esta não é a extensão de navegador. O que se segue acontece somente se você instalou o aplicativo PhishTriage no iOS e ativou o filtro de mensagens dele. Se você não fez isso, nada disto se aplica a você. A extensão não consegue ler mensagens em nenhuma plataforma.

O iOS decide quais mensagens chegam a ser oferecidas ao filtro. Uma extensão de filtro de mensagens não recebe seu histórico de mensagens e não pode sair procurando; o sistema entrega a ela mensagens individuais de remetentes em que ele ainda não confia, e essa regra é do sistema operacional, não nossa. Não podemos ampliá-la.

Somente uma mensagem com um link chega a ser enviada a nós. Antes de qualquer requisição de rede, o aplicativo verifica se a mensagem tem um link. Uma mensagem sem link — e uma mensagem sem corpo — é liberada no dispositivo, e nada sobre ela é enviado. A detecção de links é do sistema e tende a errar para o lado de encontrar um.

O que é enviado, quando uma mensagem é enviada:

Os três chegam completos e são reduzidos do nosso lado, no recebimento — o remetente a 100 caracteres, o corpo a 2.000, a string de versão a 40 — antes que qualquer outra coisa mexa neles. Dizemos isso de propósito nessa ordem: o celular envia a mensagem inteira, de modo que esses limites restringem o que guardamos e analisamos, e não o que sai do seu dispositivo. Um dos dois formatos de requisição que nosso próprio aplicativo pode enviar também leva um pequeno número inteiro de versão do próprio formato. Ele descreve a mensagem, não você.

Esse é o corpo inteiro da requisição. Ele não leva nenhum dos identificadores usados em todo o resto deste documento: nem pseudoId, nem ID de extensão, nem ID de dispositivo, nem conta. O filtro de mensagens não consegue anexar nenhum — o encaminhamento da Apple (deferral) não o carrega — e não inventamos um substituto. O endpoint não é autenticado por esse motivo e tem, em vez disso, limite de requisições por endereço IP. Essa é a ressalva honesta: seu endereço IP não está no corpo, mas chega com a requisição, como em toda requisição HTTP, é o que o limite de requisições conta e é gravado no log descrito abaixo.

Mas a mensagem ainda pode identificar você. É a mesma ressalva que o caminho do botão Analyze traz, e é igualmente verdadeira aqui. Uma mensagem de texto muitas vezes começa com o seu nome; um aviso de entrega ou um alerta do banco pode trazer uma referência de conta, um número de reserva ou um endereço. Não saímos à procura de nada disso e nada disso é armazenado — mas está no corpo, e o corpo é enviado.

Nem toda mensagem que recebemos chega a um modelo. Do nosso lado, uma etapa de palavras-chave e lista de bloqueio responde primeiro, e as URLs da mensagem são conferidas na nossa lista de bloqueio. Só uma mensagem que essa etapa não consegue decidir é entregue a um modelo — e então pelo mesmo caminho de todo o resto, descrito em Onde a análise acontece, com a mesma ordem e as mesmas condições.

O que é armazenado: nenhum registro da mensagem. Este é o único lugar deste documento em que essa é a resposta. Ao contrário dos registros de triagem e de visita descritos abaixo, uma verificação de SMS não grava nenhum — nem o remetente, nem o corpo, nem o veredito, nem a ação devolvida. Não há histórico de mensagens no portal, e o botão “Delete my scan history” não tem nada a excluir aqui, porque nada foi gravado.

O que é registrado em log, que é a exceção ao parágrafo acima. Uma requisição que chega ao manipulador do endpoint produz uma linha no mesmo log operacional descrito em O log da aplicação, com o mesmo tempo de vida — ou seja, nada na aplicação o exclui. Essa linha traz seu endereço IP original, a versão do aplicativo, um hash truncado do remetente (os primeiros 12 caracteres hexadecimais de um SHA-256 sem salt — a cautela dita para os registros de triagem vale aqui da mesma forma), se a mensagem continha um link, em qual dos dois formatos de requisição ela chegou, qual etapa a decidiu, o veredito e a ação, e quanto tempo levou. O corpo da mensagem não é registrado em log, e o remetente não aparece em texto claro.

O que não podemos oferecer a você aqui, dito com clareza. Toda via de acesso e de exclusão deste documento funciona a partir de um pseudoId ou de um extensionId, e uma requisição de SMS não leva nenhum dos dois. Portanto, não há registro para devolver a você nem para excluir — porque nenhum foi gravado — e a linha de log descrita acima não está ligada a nada além do endereço IP de onde veio. Dizemos “a linha de log” em vez de “o único rastro” de propósito: o que um provedor de modelo faz com uma mensagem que enviamos a ele para análise é regido pelos termos dele, não por esta frase. Se você quiser que a linha de log seja apagada, escreva para privacy@phishtriage.com; nós a apagamos manualmente, como o restante do log. Preferimos dizer isso a sugerir um remédio que não existe.

Onde a análise acontece

Esta seção é nova na versão 1.5. Ela existe porque a afirmação que ela substitui estava errada em uma direção que não favorece ninguém: a política dizia que seu conteúdo vai para a Anthropic como rotina, e não é mais assim que o roteamento funciona.

A ordem. Tudo o que precisa de um modelo — uma verificação em que você clicou em Analyze, ou uma mensagem de texto que passou pelas duas etapas acima — é oferecido aos backends em uma ordem fixa, e o primeiro a devolver uma resposta utilizável é o que responde:

  1. Um modelo que hospedamos nós mesmos. Uma máquina que operamos, na nossa própria rede, em vez de um serviço de modelo que compramos. Este é consultado primeiro.
  2. Um serviço de modelo de terceiros. Não está no caminho em nenhuma implantação que operamos na data de vigência desta versão. Ele é nomeado em Operadores terceiros, que diz exatamente o que o colocaria ali.
  3. A API Claude da Anthropic. O último recurso, e o único dos três sem nada atrás dele para tentar, de modo que a falha dele não é repassada: a requisição termina sem veredito. Ainda assim, a resposta dele é conferida. Um campo opcional malformado é descartado, e uma resposta que não corresponde ao formato exigido pelo resto do sistema é tratada como falha, em vez de ser usada.

As condições. Um nível só é consultado se estiver configurado, não tiver sido desativado e a requisição ainda tiver tempo restante em seu orçamento; um nível que não está configurado simplesmente não está na ordem. Um nível que é consultado e falha passa para o seguinte, e o termo “falha” é deliberadamente amplo: inalcançável, lento demais, um erro, um limite de taxa, uma saída que não conseguimos interpretar ou um veredito que não corresponde ao formato exigido pelo resto do sistema. Em qualquer um desses casos, o nível seguinte recebe o mesmo conteúdo.

Uma coisa pode vir antes da ordem, e somente onde o nosso hub de inteligência está em uso: uma verificação cujos links, domínio do remetente ou hashes de anexos o hub já guarda como maliciosos, e marcados como seguros para ação automática, é respondida a partir disso e não é oferecida a nenhum modelo (Inteligência de ameaças compartilhada, a partir da versão 1.7). No serviço hospedado, na data de vigência indicada no início deste documento, o hub não está em uso.

Um nível pode ser consultado duas vezes sobre um e-mail. Quando um nível anterior à Anthropic — nosso próprio modelo ou o serviço de terceiros — classifica um e-mail como phishing ou suspeito, nomeia o próprio nome de domínio do remetente como a marca que está sendo imitada (a “Acme” de acme.com) e nenhuma das nossas verificações determinísticas encontrou algo errado na mensagem, está prevista uma segunda requisição a esse mesmo nível. Ela não está prevista em alguns casos mais restritos: quando o remetente está em um domínio de e-mail gratuito ou de hospedagem compartilhada; quando não conseguimos afirmar com certeza o domínio do remetente, como quando o campo do remetente é longo o bastante para ter sido cortado; ou quando esse domínio traz o nome de uma de algumas organizações cujos próprios domínios mantemos em uma lista revisada, e não é um domínio que contamos como delas (anthropic.co em vez de anthropic.com). A segunda requisição leva o mesmo conteúdo mais uma curta instrução adicional que informa o domínio do remetente e pede um sinal concreto de engano ou uma resposta reconsiderada. Quando resta pouco tempo para fazê-la, ela é pulada e a primeira resposta é usada; caso contrário, a segunda resposta é usada se for utilizável, e a primeira se não for. Ela vai somente para o nível que acabou de responder, nunca adiante e nunca para a Anthropic, e por isso não acrescenta nenhum destinatário: é uma segunda cópia do mesmo conteúdo para o mesmo destinatário. Se esse nível é o serviço de terceiros, esse serviço recebe seu conteúdo duas vezes.

Por que não há aqui uma frase dizendo que seu conteúdo fica no nosso hardware. Porque ela seria falsa justamente nos dias em que importa. A alternativa de reserva existe porque o primeiro nível falha e, quando ele falha, seu conteúdo segue adiante — esse é todo o sentido de ter uma. Na semana de 17 de agosto de 2026, um parâmetro de amostragem que o modelo que hospedamos rejeita enviou toda verificação à Anthropic até ser encontrado e corrigido. Não vamos pôr aqui uma proporção nem uma duração: qualquer número que imprimíssemos seria a medição de um momento, e o roteamento é uma regra, não uma proporção. O que você pode ter como certo é a ordem e as condições acima.

A Anthropic continua sendo operadora. Menos vezes não é nunca. Uma versão desta política que tirasse a Anthropic estaria errada na primeira hora em que a máquina local se comportasse mal, e ela se comportou mal naquela semana. A entrada dela em Operadores terceiros permanece.

Não estamos dizendo em que país fica essa máquina, e isso é deliberado. A declaração sobre a Estônia em Operadores terceiros diz respeito ao host do PostgreSQL e sempre disse respeito apenas a essa máquina. Ela não é uma declaração sobre o servidor de modelo, e um rascunho desta seção a reutilizou por engano antes de a revisão detectar o erro. Vamos indicar uma localização aqui quando pudermos declará-la com a mesma precisão com que declaramos a do banco de dados, e não antes.

Esta página tem data, e o roteamento não. Quais níveis estão configurados é uma propriedade do serviço em execução e pode mudar sem que este documento mude. Por isso tudo o que está acima é escrito como uma regra mais uma declaração do arranjo na data de vigência indicada no início — e não como uma afirmação sobre este instante. Onde as duas coisas puderem divergir, a regra é a parte com a qual você pode contar.

O que não muda com o roteamento. Qualquer que seja o nível que responda, o conteúdo enviado é o conteúdo listado acima e o mesmo veredito volta. As verificações feitas com o botão Analyze têm o mesmo registro armazenado; as verificações de SMS não armazenam registro, como dito em Mensagens de texto.

O que o registro agora diz sobre o roteamento. Desde a versão 1.6, um registro de triagem armazenado, e a linha de log gravada junto com ele, anota qual nível respondeu e, quando um nível anterior a ele falhou primeiro, por quê: um motivo de uma lista fixa, como um tempo esgotado, um erro ou uma saída que não conseguimos interpretar. Se tivemos de recolocar vírgulas que faltavam na resposta que guardamos antes de conseguirmos lê-la, o que só acontece em um nível anterior à Anthropic, o registro e a linha anotam quantas. Quando uma segunda requisição ao nível que respondeu estava prevista, como descrito acima, eles também anotam como ela foi (respondida, pulada por falta de tempo ou um motivo da mesma lista fixa), o veredito da primeira resposta e se o veredito mantido é outro. Tudo isso são palavras de listas fixas ou uma contagem, e nada carrega qualquer conteúdo seu. Este parágrafo dizia que um registro de triagem armazenado não anota qual backend produziu o veredito, de modo que não poderíamos dizer a você depois qual deles analisou uma verificação sua — e você também não poderia. A primeira metade já não é verdade: um pedido de acesso conforme Seus direitos devolve essa informação junto com o restante do registro. A segunda metade ainda é, porque nada que você possa abrir na extensão ou no portal a mostra.

O que o backend armazena e por quanto tempo

O proxy em api.phishtriage.com (Node/Express; o código-fonte dele não é público hoje) registra cada requisição de triagem e cada ping de visita em um banco de dados PostgreSQL em hardware que possuímos e operamos — veja Operadores terceiros, abaixo, para o quadro completo de armazenamento. Campos armazenados por registro:

Registros de conta e de identidade

Esta subseção surgiu na versão 1.2. Os tipos de registro acima vinham sendo apresentados como o quadro completo de armazenamento, e não são: são os registros de atividade. O plano de controle que fica por baixo deles foi acrescentado quando o produto passou a ter contas, equipes e planos, e é onde um endereço de e-mail de fato mora. Na ordem do esquema (migrations/ no repositório do proxy):

Uma organização pode incluir você nela sem perguntar, e até a versão 1.4 este documento nunca disse isso. Ele descrevia dois caminhos para uma equipe — um convite que você aceita e um token de registro que um administrador envia a um dispositivo — e há um terceiro. Se uma organização comprovou que é dona de um domínio de e-mail, então, na próxima vez que alguém fizer login no portal com um endereço do Google verificado nesse domínio, essa conta passa a ser membro dessa organização. Não há convite, nem pergunta, nem aviso no login; isso acontece durante um login que se parece com qualquer outro. A partir desse momento, os proprietários da organização podem ver as verificações dessa conta e suas evidências de phishing nos mesmos termos de qualquer outro membro — sujeito ao modo de relatório descrito em Guarda de evidências de páginas de phishing.

Três limites são reais e vale dizê-los. Uma conta que já está em uma organização nunca é movida para outra. Somente a atividade a partir do instante em que a organização passou para o relatório por pessoa chega a ser atribuída, de modo que entrar não expõe retroativamente o que você fez antes disso. E o portal informa em qual organização você está, quando entrou e qual domínio o colocou ali, justamente porque esta é a única associação sobre a qual ninguém é consultado. Se você preferir que isso não aconteça, não faça login no portal com um endereço desse domínio — a extensão verifica perfeitamente bem sem uma conta.

Um domínio pode ser comprovado de duas formas, e somente uma delas é visível para você. A primeira é um registro TXT de DNS que a organização publica. A segunda identifica a organização pelo tenant do seu provedor de identidade — hoje, a claim hd do Google Workspace — e não exige que a organização publique absolutamente nada. Portanto, conferir os registros DNS do seu domínio não é um modo de descartar isso.

De volta ao inventário de registros:

O log da aplicação

Separadamente do banco de dados, o proxy grava uma linha de log operacional ao tratar uma requisição. Seis tipos de linha importam aqui. A terceira não constava desta lista até a versão 1.5, porque a superfície a que pertence não constava deste documento, a quarta chegou com os botões de relato na versão 1.7, e as duas últimas foram acrescentadas ao serviço em 3 de outubro de 2026 e a esta lista na versão 1.10:

Outras linhas dizem respeito a um dispositivo ou a uma conta, e não a uma verificação. Elas trazem o extensionId, o pseudoId ou o ID de conta dele e nada das suas verificações: um dispositivo que apresenta uma credencial que não aceitamos mais, uma conta cujas credenciais de dispositivo revogamos, uma conta que entra em uma organização por um domínio comprovado, uma ação do portal recusada por falta de uma função e um dispositivo que leva a organização dele além do número de licenças que o plano inclui, registrado com o número de licenças e o plano quando o dispositivo se registra ou envia um token de registro tardio.

O verificador de arquivos em filescan.phishtriage.com, um serviço nosso separado, mantém um log próprio se você usa a proteção de arquivos: uma linha para cada requisição que trata, com a requisição, o status dela, quanto tempo levou e os primeiros oito caracteres do extensionId do dispositivo e, para uma verificação de arquivo, o veredito, qual verificação o deu, se uma verificação profunda foi oferecida, a assinatura de malware com a qual uma verificação profunda teve correspondência e os primeiros 60 caracteres do nome do arquivo. Não o seu endereço IP e não o arquivo. Até a versão 1.9, este documento não o mencionava.

É nesse sentido que “não sabemos seu endereço IP”, a frase que ficou no início deste documento até a versão 1.2, era falsa. O hash é real, e é o que o banco de dados guarda; não é o que o log guarda.

A rotina de limpeza de retenção descrita a seguir exclui linhas do banco de dados. Ela não toca nesses logs — nada em nenhuma das duas aplicações os exclui, e por isso o tempo de vida deles é o que o gerenciamento de logs de quem opera o serviço determinar. Um pedido de exclusão que indique seu extensionId os cobre, inclusive as linhas que trazem apenas o pseudoId ou o ID de conta a que esse extensionId pertence; nós as apagamos manualmente. Uma linha de SMS não tem extensionId que se possa indicar — Mensagens de texto diz o que isso significa para um pedido. Uma linha de capacidade também não tem, pois nomeia um endereço com hash e nada mais sobre ninguém.

Retenção

Os registros de evidência são a exceção a tudo nesta seção: são mantidos no prazo separado, por veredito, descrito acima, e a rotina de limpeza do histórico de verificações não toca neles. Como podem durar mais que a verificação de que vieram, têm sua própria lista no portal — veja Quem pode vê-la, e como acima — de modo que uma captura continua acessível, e excluível individualmente, durante todo o tempo em que for mantida. A menos que sua organização use o modo de relatório agregado, que é o modo em que toda organização começa: ali a lista é omitida para todos e o botão de histórico completo abaixo é o único caminho.

Os registros de triagem, de visita e de verificação de arquivos são excluídos automaticamente. Cada um recebe sua data de exclusão quando é gravado, a partir do período em vigor naquele momento para a conta sob a qual é gravado:

Alterar um período muda a data de exclusão apenas dos registros gravados depois da alteração: um período mais curto não exclui registros mais antigos antes da hora, e um mais longo não os mantém por mais tempo. Assim, um registro de verificação ou de visita gravado antes da mudança para 365 dias mantém os 90 dias que recebeu. Os registros de verificação de arquivos não tinham data de exclusão até começarmos a dar uma a cada registro, pouco antes de a versão 1.10 entrar em vigor: os feitos antes disso receberam 365 dias a partir do momento em que cada um foi feito, e os feitos entre então e a mudança para 365 dias receberam 90. Uma rotina de limpeza remove, várias vezes por dia, todo registro que passou da data de exclusão, de modo que um registro pode durar algumas horas além da data.

Os relatos que você envia com os botões abaixo de um veredito não seguem esses períodos: a mesma rotina de limpeza exclui cada um 90 dias depois de o recebermos, qualquer que seja o período que vale para as suas verificações.

Quando você ou o proprietário de uma equipe alteram um período, guardamos um registro de quem o alterou, de quê para quê e quando e, para uma alteração do seu próprio período, o período da equipe naquele momento. Ele não contém conteúdo de verificações, e nem a rotina de limpeza nem o botão “Delete my scan history” o removem.

O padrão é configurado no lado do servidor (RETENTION_DAYS); proxies de hospedagem própria escolhem o seu ou não definem nenhum — caso em que os registros sem período escolhido são mantidos até serem excluídos manualmente, e esta política não se aplica a essa implantação. Até a versão 1.9, esta seção descrevia uma única janela de retenção de 90 dias para todo registro de triagem, todo registro de visita e todo relato, e não mencionava os registros de verificação de arquivos, que nada excluía.

Independentemente da rotina de limpeza:

ID pseudônimo

Sua instalação é identificada por uma sequência aleatória de caracteres que chamamos de “pseudoId”. Ela é armazenada em chrome.storage.local, sob a chave pseudoId, e é enviada com toda requisição de triagem e de visita. Dependendo de você ter se registrado ou não, ela é uma de duas coisas:

Nenhuma das duas formas deriva do seu e-mail, endereço IP, ID de hardware, impressão digital ou qualquer outro identificador. As duas são números aleatórios novos. Tratamos o ID como uma chave de correlação, e não como prova de quem você é: ele existe para que o uso repetido a partir da mesma instalação possa ser ligado no servidor (para cache, ou para mostrar a você um histórico por dispositivo no portal), e não para identificar você como pessoa.

Quando o registro acontece: correção. Esta seção dizia “o registro é uma ação explícita; ele não acontece na instalação”. O contrário é o que acontece, e é assim desde que o registro deixou de ser um botão: ele roda automaticamente a partir do evento de instalação do navegador e, de novo, antes da primeira verificação de uma sessão, se essa tentativa não teve êxito. Não há um controle de registro no pop-up. Assim, em uma rede que funciona, o ID gerado pelo dispositivo acima existe somente até a primeira chamada a /register retornar, e toda instalação passa a ter uma identidade gerada pelo servidor antes de você ter feito qualquer coisa com a extensão.

O registro não é um cadastro e não envolve nenhuma conta sua. O que ele envia é o pseudoId atual, em qual navegador você está, um rótulo vazio e — somente em uma frota em que um administrador enviou um por política — um token de registro que vincula o dispositivo a essa organização. Nenhum endereço de e-mail e nada que você digite. Ele falha em silêncio e tenta de novo mais tarde: um dispositivo não registrado continua fazendo verificações.

A partir da versão 1.1.0 da extensão, a extensão também envia um token de registro, e nada mais, para /devices/enrol, com a credencial do próprio dispositivo, sempre que tem um sobre o qual o backend ainda não deu uma resposta definitiva. Isso inclui um token que um administrador envia a um dispositivo já instalado, ou altera; um token que o registro levou, mas que não vinculou o dispositivo a uma organização; e, uma vez, um token já definido por política quando um dispositivo é atualizado para a versão 1.1.0. Ela envia o mesmo token de novo somente até o backend dar uma resposta definitiva: depois de uma requisição que ficou sem resposta — o backend ocupado, fora do ar ou inalcançável —, ela espera, por mais tempo após cada falha, e tenta de novo. O que ela guarda sobre isso no seu dispositivo está listado em O que a extensão guarda no seu próprio dispositivo.

Antes, derivávamos o identificador de uma pessoa registrada de um hash do endereço de e-mail dela. Não fazemos mais isso, e a derivação foi removida: um valor calculado a partir de um endereço de e-mail não é de fato pseudônimo, porque qualquer pessoa que tenha o endereço pode recalculá-lo.

A linha da conta no pop-up pode descartar essa identidade. Este documento chamava o controle de Unregister, que não é uma palavra da interface: o botão diz Leave team quando seu dispositivo pertence a uma organização e Sign out quando você fez login individualmente, e ele aparece somente nesses dois casos. Qualquer um dos dois apaga extensionId, pseudoId, a organização e os tokens armazenados e, a partir da versão 1.1.0 da extensão, também os dados sobre o registro com o token — e depois se registra de novo imediatamente, de modo que o que você acaba tendo é uma identidade nova gerada pelo servidor, e não nenhuma. Do ponto de vista do backend, você é uma instalação diferente; seus registros antigos ficam onde estão e não podem mais ser alcançados a partir deste dispositivo.

Quando um ID cobre vários dispositivos: correção. Este parágrafo dizia que vincular-se a uma equipe “por meio de um código de convite” sobrescrevia seu pseudoId com o do proprietário da equipe, e que essa era a única forma de um ID alcançar mais de um dispositivo. Cada parte disso agora está errada. Não existe mais um campo de código de convite na extensão — digitar um código ali registrava uma máquina como dispositivo da equipe sem nenhuma pessoa vinculada, então ele foi removido, e um dispositivo agora entra em uma equipe pelo portal, onde um administrador pode ver o que está sendo associado a quem.

O que realmente acontece: quando você faz login, ou quando um administrador vincula seu dispositivo pelo portal, seu pseudoId local é substituído pelo ID dessa conta. Nunca é um ID de organização — esses ficam em um espaço de nomes separado — e, quando um administrador vincula um dispositivo pelo portal, o ID que ele assume é o ID da conta à qual o administrador o vinculou, que pode não ser a sua. O pop-up o lê de novo no servidor cada vez que você o abre. Assim, todo dispositivo em que você faz login carrega o mesmo ID, e as requisições de todos eles são ligadas no servidor; é isso que faz um único histórico a partir de vários dispositivos, e isso vale tanto para um login pessoal quanto para um de equipe. Uma instalação em que nunca foi feito login mantém um ID só dela.

Inteligência de ameaças compartilhada

Esta seção foi acrescentada na versão 1.7, e descreve um destino para os seus dados que nenhuma versão anterior à 1.7 mencionava. Ela é escrita antes de o recurso ser ativado, e não depois, que é a única ordem que dá valor à divulgação.

Operamos um hub de inteligência interno: um serviço nosso que reúne indicadores — URLs de links, domínios, hosts, hashes de arquivos — a partir das nossas próprias verificações e de parceiros, para que uma página que um cliente denuncia possa ser reconhecida instantaneamente por todos os outros. Ele não é de terceiros. Também não é este proxy, e esse é o ponto desta seção: ele é um terceiro destino, ao lado dos dois hosts citados em Operadores terceiros, e dados derivados das suas verificações podem chegar a ele.

Todo fluxo descrito abaixo está desativado na configuração distribuída e, na data de vigência indicada no início deste documento, todos estão desativados no serviço hospedado. Onde um está ativado, é exatamente isto que acontece. Até a versão 1.9, este parágrafo dizia que cada um permaneceria desativado no serviço hospedado até que uma revisão datada deste documento dissesse o contrário. A partir da versão 1.10, qualquer um deles pode ser ativado sem uma nova revisão, de modo que esta seção é escrita para ser verdadeira esteja ele ativado ou não. Toda afirmação deste documento de que o hub, um fluxo para ele ou a configuração dele não está em uso no serviço hospedado é uma afirmação na data de vigência, e não uma promessa de que ainda seja assim.

O que sai e o que nunca sai

Somente valores derivados de uma verificação, nunca o conteúdo dela:

Perguntar antes de um modelo ser consultado. O proxy também pode perguntar ao hub sobre essas mesmas URLs de links, domínios, hosts, domínio do remetente e hashes antes de um modelo ler a mensagem, e espera uma fração de segundo pela resposta. Se o hub já guarda um deles como malicioso e marcado como seguro para ação automática, essa resposta passa a ser o veredito e nenhum modelo é consultado; o registro de triagem e a linha de log dele então não nomeiam nenhum nível como autor da resposta. Qualquer outra resposta, ou nenhuma a tempo, não muda nada, e a verificação vai a um modelo como iria de qualquer forma.

Uma captura que um proprietário confirma. Quando o proprietário de uma organização confirma uma captura de phishing (Guarda de evidências de páginas de phishing), o endereço da página, reduzido da mesma forma, e um hash do HTML dela são enviados como uma constatação confirmada sobre essa página, e uma rejeição posterior da captura a retira. Onde o caminho do endereço seria removido, nada é enviado. Uma captura de uma mensagem de e-mail não tem endereço de página, então confirmar uma não envia nada. A captura de tela e o HTML em si nunca são enviados. A constatação não leva pseudônimo e é enviada em nome do próprio proxy, e não do proprietário. Como tudo o que o proxy envia ao hub, ela é registrada sob a organização, com o horário (veja Por quanto tempo o hub guarda os dados).

O que nunca sai do proxy para o hub: o corpo da mensagem, a linha de assunto, o HTML, os cabeçalhos brutos, o destinatário, o endereço do remetente, os nomes dos arquivos anexados, as capturas de tela, o código-fonte da página e qualquer coisa que você tenha digitado. A mesma lista é imposta no código e verificada por um teste que serializa uma contribuição montada a partir de uma mensagem recheada com cada um desses itens e procura cada um deles nos bytes resultantes.

O pseudônimo e o seu escopo

Uma contribuição leva uma referência de titular: um hash com chave que representa a sua conta, calculado como HMAC(HMAC(secret, organisation), account). Três consequências decorrem disso, e elas são o motivo de não ser um hash simples:

Suas correções, quando o encaminhamento está ativado

O que guardamos de um clique em “Looks safe to me” ou “Looks dangerous” está descrito em Suas correções a um veredito, e essa parte não depende do hub. Com o encaminhamento de relatos ativado, cada relato também é enviado ao hub como um relato sobre a página: sua resposta, o endereço da página reduzido ao esquema, ao host e ao caminho (nenhum para um relato feito sobre e-mail, ou quando o caminho parece carregar um token específico de cada destinatário), o horário informado pelo seu dispositivo (o nosso, se ele não informou nenhum), que tipo de cliente o enviou, um identificador aleatório do próprio relato e o pseudônimo acima, registrado sob a sua organização — nada mais sobre você, e nada em absoluto para uma conta sem organização. Ele vai como um relato de baixo peso, marcado como não sendo, por si só, motivo para bloquear a página, e o pseudônimo nele segue o prazo de 90 dias do próprio relato (abaixo).

Por quanto tempo o hub guarda os dados e o que a exclusão alcança

O hub guarda o que recebe sem limite de tempo e abre mão do pseudônimo que o liga a você quando o nosso registro o faz. O que ele guarda é o que um indicador é: a própria URL do link, o domínio, o host ou o hash, a frequência com que foi visto, as alegações feitas sobre ele e o veredito a que se chegou e, para cada ocorrência, relato encaminhado e constatação confirmada que o proxy envia, de qual organização veio e quando. O que ele não guarda além do nosso próprio registro é o pseudônimo que liga uma observação a você. Cada contribuição informa ao hub quantos dias faltam para que o registro de que veio seja excluído aqui — a verificação, no caso de uma contribuição de uma verificação, conforme o período descrito em Retenção; o relato, no caso de um relato encaminhado, conforme o prazo de 90 dias dos relatos — e, quando esse tempo se esgota, o hub remove o pseudônimo e guarda o resto. Isso acontece em até um dia depois da data em que o nosso registro é excluído, e mais tarde somente se o processo de segundo plano (worker) do próprio hub não estiver em execução. Uma contribuição feita a partir de um registro que já passou da data não leva nenhum pseudônimo.

O que o hub guarda ainda pode apontar para você. A organização e o horário ficam sem limite de tempo. Em uma organização com um único membro, a organização identifica esse membro. Em qualquer organização, poderíamos cruzar o horário de uma ocorrência com o nosso log da aplicação, cuja linha de triagem traz seu pseudoId e o horário de cada verificação, enquanto esse log for mantido (veja O log da aplicação). E, depois que o hub abre mão do pseudônimo em uma ocorrência, o botão “Delete my scan history” não a alcança mais, porque nada nela nomeia mais você.

Vale dizer isso com clareza porque é o único lugar que a nossa própria rotina de limpeza de retenção não alcança: a rotina exclui linhas no nosso banco de dados e não consegue excluir uma linha no do hub. Até a versão 1.9, esta seção dizia que as contribuições levavam um prazo de expiração definido por nós, igual ao período do seu histórico de verificações. O hub, em vez disso, guarda o indicador, e o que termina com o período é o pseudônimo.

O botão “Delete my scan history” também alcança o hub. Quando você exclui seu histórico, o proxy pede ao hub que apague tudo o que foi registrado sob os seus pseudônimos — uma requisição por organização em que você já contribuiu, inclusive aquelas que você deixou desde então — e o hub devolve um recibo; guardamos o identificador dele e um hash dele junto com o nosso registro da exclusão. O portal mostra a você qual de três coisas aconteceu, abaixo do resultado da exclusão: o apagamento foi confirmado (com o identificador do recibo), não havia nada ali a apagar, ou não foi possível confirmá-lo agora. A terceira não é uma falha da sua exclusão: seus registros aqui somem de qualquer forma, e essa frase significa que a cópia compartilhada ainda não foi confirmada. Nada é registrado no hub sob os seus pseudônimos — nenhuma contribuição e nenhum relato encaminhado — a menos que esse apagamento também esteja ativado.

Dois limites honestos. Um indicador que já foi agregado ao julgamento do próprio hub sobre uma URL — “várias pessoas denunciaram esta página” — não desaparece quando a associação com você desaparece; o que é apagado é o vínculo entre você e a observação, e o recibo do hub diz isso com as próprias palavras. E uma alegação que o hub já distribuiu a um consumidor a jusante não pode ser despublicada excluindo-se a linha que a produziu.

O que o verificador de arquivos pode enviar

O verificador de arquivos em filescan.phishtriage.com também pode estar conectado ao hub. Na data de vigência indicada no início deste documento, não está. Onde está, ele envia, para cada arquivo que a verificação profunda dele identificou como malware, inclusive arquivos verificados antes de ele ser conectado e antes de a versão 1.10 entrar em vigor, enquanto o registro da verificação for mantido: a impressão digital SHA-256 do arquivo, o tamanho, o nome da assinatura de malware com a qual houve correspondência, quando o arquivo foi verificado e uma referência ao registro próprio do verificador dessa verificação. Nunca o arquivo, o nome dele, sua conta, seu dispositivo ou um pseudônimo. O hub descarta a referência ao nosso registro quando chega a data de exclusão desse registro, conforme o período descrito em Retenção, e guarda a impressão digital e o veredito. Um arquivo cujo registro já passou da data não é enviado. Cada um é enviado como uma alegação ponderada de modo que uma única detecção basta para o hub julgar a impressão digital maliciosa, e uma impressão digital que o hub julga maliciosa pode ser repassada a outros que usam as listas do hub, que é para o que serve a contribuição.

A lista de bloqueio, que segue o caminho inverso

O proxy também pode buscar uma lista de bloqueio no hub, o que são dados que chegam até nós, e não dados que saem. Nada sobre você é enviado para buscá-la: é uma lista assinada de nomes de host e URLs, solicitada sem nenhum parâmetro derivado da atividade de qualquer usuário. Ela é listada aqui por completude, e não porque revele alguma coisa.

Outras duas buscas são parecidas com ela. Onde o verificador de arquivos está conectado ao hub, ele busca a lista assinada do hub com impressões digitais de malware conhecido, e um arquivo cuja impressão digital está nela é considerado malicioso sem que o arquivo seja enviado. E, a partir da versão 1.1.0 da extensão, quando a política de um administrador indica um hub e as chaves que assinam suas listas (intelHubUrl e intelRootJwks), a extensão, com a proteção de arquivos ativada, pede a esse hub a lista de bloqueio de downloads quando um download precisa dela, e pede ao nosso proxy somente quando o hub não fornece nada. Depois de uma busca que devolve uma lista, ela não pergunta ao hub de novo por uma hora. Caso contrário, quando a lista do hub está vazia ou a última busca falhou ou foi recusada, ela pergunta de novo no próximo download, e assim a cada download até que uma busca devolva uma lista. A requisição não leva nada sobre você, mas vai do seu navegador direto ao hub, de modo que o hub vê o seu endereço de rede e, como cada requisição segue um download, quando você baixa algo, embora não o quê.

Operadores terceiros

Anthropic — a API Claude, e o último nível da ordem descrita em Onde a análise acontece. O conteúdo chega a ela quando os níveis anteriores não respondem, o que é uma condição, e não uma frequência. Deliberadamente não imprimimos aqui uma proporção: seria a medição de um momento apresentada como uma propriedade do serviço, e a configuração incorreta descrita em Onde a análise acontece é como isso fica quando vai na direção contrária. Este parágrafo começava com “quando você clica em Analyze, o conteúdo extraído é encaminhado pelo proxy à API Claude da Anthropic para análise” — incondicional, correto quanto ao fato de a Anthropic receber conteúdo e errado quanto ao roteamento. A Anthropic atua como operadora em nosso nome, conforme os termos da API dela; segundo esses termos, a Anthropic não usa entradas de requisições à API para treinar modelos. Veja anthropic.com/legal/privacy para os compromissos dela quanto ao tratamento de dados.

Ollama — um serviço de modelo de terceiros hospedado (Ollama Cloud), nomeado aqui antes de ser usado, e não depois. É o nível intermediário dessa mesma ordem, e um nível só está no caminho quando está configurado, que é a regra enunciada em Onde a análise acontece. Na data de vigência desta versão, ele não está configurado em nenhuma implantação que operamos. Isso é uma declaração na data de vigência acima, e não uma declaração permanente — a regra que permanece é a da frase anterior: um nível só está no caminho quando está configurado.

Estamos nomeando um operador não utilizado por dois motivos, e achamos que a alternativa é pior. Ativá-lo não exige código novo nem lançamento — três valores de configuração e uma reinicialização —, de modo que a distância entre “fora do caminho” e “no caminho” é de minutos, enquanto a distância entre editar este documento e ele chegar a você passa por uma revisão da loja. E esta divulgação é aquilo que a ativação deve aguardar: a configuração de implantação diz, com todas as letras, que esta política deve nomear o Ollama antes que esse nível carregue tráfego real. Uma política que precisa ser reescrita no dia em que alguém define três variáveis de ambiente é uma armadilha, e por isso preferimos nomear um operador a mais a nomear um a menos. Se ele de fato receber tráfego, o que ele recebe é o que o nível anterior a ele teria recebido — o conteúdo descrito em O que a extensão coleta e quando e em Mensagens de texto — e nada adicional.

Os registros são armazenados em um banco de dados PostgreSQL em hardware que possuímos e operamos, localizado na Estônia. Essa frase diz respeito ao host do banco de dados e somente a ele; veja Onde a análise acontece para saber por que este documento não diz onde fica o servidor de modelo. Desde que a produção passou para o PostgreSQL em agosto de 2026, nenhum provedor de armazenamento de terceiros manteve os registros descritos em O que o backend armazena — não há nenhum provedor de banco de dados gerenciado no caminho. A Cloudflare, Inc. transporta o tráfego entre o seu navegador e o nosso servidor (terminação TLS, tunelamento, proteção contra DDoS) e é operadora apenas de dados em trânsito; ela não armazena os seus registros.

Até a versão 1.7, esta seção descrevia uma exceção legada: os registros criados antes da migração de agosto de 2026 para o nosso próprio hardware, os registros pré-lançamento do período beta, ficavam no nosso repositório de dados anterior na Elastic Cloud (Elasticsearch como serviço gerenciado, região GCP europe-west3, sob o DPA da Elastic), fora da exclusão automática de 90 dias. Excluímos esse projeto da Elastic Cloud em 2 de outubro de 2026 e não guardamos nenhuma exportação, snapshot ou cópia dele. O que a própria Elastic retém de um projeto excluído, como seus próprios backups, e por quanto tempo, é regido pelos termos dela e pelo acordo de tratamento de dados dela conosco; não enviamos mais nada a ela. Os registros criados desde que a produção passou para o PostgreSQL em agosto de 2026 nunca foram armazenados ali.

Esta seção costumava terminar com “não usamos nenhum outro operador terceiro”. A Anthropic, a Cloudflare e a Elastic eram a lista inteira quando ela terminava assim. Mais dois chegaram com as contas e a cobrança, e ambos são alcançáveis pelo botão Log in do pop-up:

Fora isso: sem análise de uso (analytics), sem publicidade, sem SDKs de telemetria, sem serviços de relatório de erros, sem bibliotecas de fingerprinting. Isso é uma declaração sobre o que construímos no produto, e não uma afirmação de que nenhum terceiro é jamais contatado — as dependências do Google no portal, citadas acima, são contatadas em todas as páginas.

Três destinos recebem os seus dados, os três nossos:

Os três são operados por nós no hardware descrito acima; nenhum é de terceiros. A política de administrador de uma organização pode apontar os dois primeiros para um serviço de hospedagem própria, e nesse caso esse serviço cabe à sua organização descrever, e não a nós.

Mais uma requisição, que a redação antiga negava. Esta lista era introduzida como “a extensão fala com dois hosts, ambos nossos, e com nada mais”. Isso deixou de ser verdade quando a proteção de arquivos foi lançada. Com a proteção de arquivos ativada, um download comum precisa ser buscado uma segunda vez para chegar a ser inspecionado — o navegador não entrega a uma extensão os bytes de um — e essa segunda busca vai para o endereço de onde o próprio download veio, que pode ser qualquer host da internet, levando os seus cookies desse site, para que um arquivo atrás de um login ainda possa ser lido. O que o site vê é uma segunda requisição pelo arquivo que acabou de entregar a você: a requisição não leva nenhum cabeçalho, identificador ou parâmetro nosso e não diz nada sobre o resto da sua navegação. Os bytes não vão além da memória do seu navegador, a menos que a seção sobre proteção de arquivos acima diga o contrário. Com a proteção de arquivos desativada, isso não acontece.

Hospedagem própria

Organizações podem executar o próprio proxy e apontar a frota delas para ele enviando uma política de administrador por meio do armazenamento gerenciado corporativo (veja o esquema managed-storage.json no código-fonte). Esta é deliberadamente a única forma de mudar o backend: não há nenhuma configuração voltada ao usuário, de modo que ninguém pode ser convencido a colar a URL de um atacante e a encaminhar a ela o e-mail que a extensão verifica. Quando sua organização usa hospedagem própria, o restante deste documento continua descrevendo o comportamento da extensão, mas o comportamento do backend é regido pela política de quem o opera na sua organização, e não pela nossa. Sua equipe de TI é o controlador desses registros. Não temos acesso aos dados de um proxy de hospedagem própria.

Seus direitos

Você tem, dependendo da jurisdição, o direito de:

Responderemos aos pedidos em até 30 dias. Se você usou a extensão em vários navegadores sem vinculá-los, cada instalação tem um pseudoId separado e talvez seja necessário pedir a exclusão para cada uma.

Alterações nesta política

Quando fizermos uma mudança relevante — uma nova coleta, um novo operador, um período de retenção mais curto ou mais longo — vamos atualizar a Versão e o campo Em vigor a partir de no início deste documento e, quando razoável, exibir um aviso na próxima página de boas-vindas aberta. O histórico completo de revisões deste documento é mantido no git; o repositório não é público hoje, então escreva para privacy@phishtriage.com para obter uma versão anterior e nós a enviaremos. Este parágrafo costumava trazer um link direto para o arquivo, o que retornava 404 para todo mundo.

Versão 1.10, e como ela foi comunicada a você. A versão 1.10 é uma mudança relevante. Ela amplia um período de retenção: no serviço hospedado, os registros de verificação, de visita e de verificação de arquivos gravados depois da mudança para o novo padrão são mantidos por 365 dias, enquanto os gravados antes dela mantêm o período que receberam, e você ou o proprietário da sua equipe agora podem escolher um período mais curto, com mínimo de 7 dias. Ela descreve, pela primeira vez, registros que já guardávamos: os registros de verificação de arquivos que o verificador de arquivos grava desde que a proteção de arquivos foi lançada, que nada excluía, e o log próprio do verificador de arquivos. Ela acrescenta o registro que guardamos de cada alteração de um período de retenção e as duas linhas de capacidade que o nosso log da aplicação traz desde 3 de outubro de 2026. Ela muda o que o hub de inteligência guarda: indicadores, com a organização de que cada um veio e quando, sem limite de tempo, e o pseudônimo que os liga a você somente enquanto durar o nosso registro dele. Ela diz o que o verificador de arquivos enviaria ao hub se estivesse conectado, inclusive as verificações feitas antes disso. Ela permite que um fluxo para o hub seja ativado sem uma nova revisão deste documento, o que, segundo este documento, até a versão 1.9 não aconteceria. E descreve o que a versão 1.1.0 da extensão muda em relação à versão 1.0.0, e corrige várias frases no próprio texto, cada uma nomeando a versão que corrige.

Não exibimos um aviso na página de boas-vindas da extensão para a versão 1.10: nenhuma versão da extensão traz um. O painel do portal exibe, em vez disso, um aviso único, quando a opção de retenção é ativada: “You can now choose how long we keep your scans, from 7 days to 1 year.” (agora você pode escolher por quanto tempo guardamos suas verificações, de 7 dias a 1 ano). Ele é mostrado às pessoas que fazem login no portal e podem escolher um período de até um ano, ou que definem o período da equipe. Um membro de uma equipe que guarda verificações por menos de um ano não o vê, e o aviso não menciona o novo padrão nem qualquer outra mudança. Se você não faz login no portal, nada além deste documento informa você sobre a versão 1.10.

Contato

privacy@phishtriage.com

Para divulgação de vulnerabilidades de segurança (na extensão ou no proxy), escreva para security@phishtriage.com.