Para equipes de segurança · 15 minutos

Tratamento de dados

Para cada coisa que a extensão de navegador PhishTriage faz: o que sai do dispositivo, para onde vai e por quanto tempo é mantido. Depois, os operadores, o que uma equipe pode ver, a exclusão e as chaves de política do administrador que alteram fluxos de dados.

Versões e escopo

• Extensão. As lojas dos navegadores distribuem a versão 1.0.0. O comportamento descrito abaixo é o dessa versão, a menos que uma linha diga o contrário.
• Política. Política de privacidade, versão 1.10, em vigor a partir de 4 de outubro de 2026. O cabeçalho dela diz que ela se aplica à extensão de navegador a partir da versão 1.1.0 e aos serviços de backend padrão em api.phishtriage.com e — somente com a proteção de arquivos ativada — filescan.phishtriage.com. Uma mudança relevante (uma nova coleta, um novo operador, um período de retenção diferente) altera o número da versão e a data de vigência. As versões anteriores podem ser obtidas pelo endereço privacy@phishtriage.com.
• Onde as duas divergem. Quando a versão 1.0.0 se comporta de modo diferente do que a política 1.10 descreve, esta página descreve a versão 1.0.0. As diferenças:
  • Os botões de feedback não enviam nada; o clique fica guardado no dispositivo. A política 1.10 descreve o envio de um clique por padrão.
  • O Outlook em outlook.cloud.microsoft é lido como uma página da web comum, não como e-mail. São quatro hosts de e-mail, não os cinco da política, e as permissões de instalação citam apenas esses quatro.
  • Nada é capturado nos hosts de e-mail, qualquer que seja o veredito. A política 1.10 descreve a 1.1.0, que, nesses hosts, guarda uma captura de tela recortada para a mensagem analisada e o HTML dessa mensagem depois de um veredito de phishing ou suspeito, nunca a caixa de entrada.
  • As builds da versão 1.0.0 nas lojas diferem entre si no limite de texto da página (5.000 ou 10.000 caracteres), em ler ou não os frames, em remover ou não o texto do aviso de página inteira de uma verificação de página e em oferecer ou não o interruptor File protection. A política 1.10 descreve o limite de 10.000 caracteres, a leitura dos frames, a remoção de todos os painéis do próprio PhishTriage e a opção File protection no Chrome, no Edge, no Brave e no Firefox.
• Controlador. A equipe do PhishTriage, no caso do serviço hospedado. Quando uma organização opera o próprio backend (a hospedagem própria é oferecida no plano corporativo, mediante solicitação), essa organização é a controladora dos registros do backend, e a política descreve apenas o comportamento da extensão.
• Retenção no serviço hospedado. Todo período abaixo é o do serviço hospedado. Um backend de hospedagem própria define os seus.

O que roda antes de alguém clicar em qualquer coisa

• Permissões de instalação: activeTab, storage, scripting e acesso de host a quatro hosts de e-mail — mail.google.com, outlook.office.com, outlook.office365.com e outlook.live.com — declarados como padrões de correspondência estáticos do script de conteúdo. Não há permissão identity: a extensão não consegue ler a conta com a qual o navegador fez login.
• Permissões opcionais, solicitadas somente quando o recurso que as exige é ativado: webNavigation para o monitoramento, downloads para a proteção de arquivos e <all_urls> para qualquer um dos dois. Se nenhum dos dois estiver ativado, nenhum acesso de host além dos quatro hosts de e-mail é solicitado.
• Nos quatro hosts de e-mail, o script de conteúdo é carregado em todas as páginas em document_idle e observa continuamente a estrutura da página, para manter o botão Analyze no lugar. Ele não lê o conteúdo de nenhuma mensagem e não envia nada até que alguém clique no botão Analyze.
• Com a proteção de arquivos ativada, scripts são registrados para <all_urls> em document_start, em todos os frames — dois registros (quatro arquivos) no Chrome, no Edge e no Brave, menos no Firefox — para que um arquivo criado por uma página possa ser examinado antes de chegar à pessoa. Com a proteção de arquivos desativada, nada disso é registrado.
• O registro do dispositivo é executado automaticamente na instalação (veja o inventário). Não é um cadastro.

Fonte: a lista de permissões da política, na seção “TL;DR”, e a seção “When you click ‘Analyze’ (on-demand triage)”. Os quatro hosts de e-mail são os da versão 1.0.0; a política 1.10 acrescenta um quinto, outlook.cloud.microsoft, a partir da 1.1.0.

Inventário, por ação

Toda requisição ao backend também leva o endereço IP do dispositivo, como toda requisição HTTP. O que acontece com ele está em Endereços IP e o log da aplicação.

Os detalhes de cada linha vêm a seguir. As requisições de análise e de visita também levam o pseudoId do dispositivo e, depois do registro, o extensionId. Os envios de evidências, o início de um login no portal, a verificação de conta do pop-up e, com a proteção de arquivos ativada, a atualização da lista de bloqueio e cada verificação de arquivo e verificação completa enviada a filescan.phishtriage.com levam, em vez disso, a credencial do dispositivo.

Registro do dispositivo

É executado a partir do evento de instalação do navegador e novamente antes da primeira verificação de uma sessão, se essa tentativa não tiver tido êxito. Não há controle de registro no pop-up. Antes do registro, o pseudoId é uma sequência hexadecimal aleatória de 12 caracteres, gerada no dispositivo com crypto.getRandomValues; o registro o substitui por um valor aleatório de 32 caracteres (128 bits) gerado pelo servidor. Nenhum dos dois é derivado de um endereço de e-mail, endereço IP, ID de hardware, impressão digital ou qualquer outro identificador. O registro falha em silêncio e tenta de novo; um dispositivo não registrado ainda faz verificações. O registro armazenado da extensão guarda o extensionId, o pseudoId, o identificador do navegador, um rótulo opcional, quando o dispositivo se registrou e quando esteve ativo pela última vez — um carimbo de data e hora reescrito a cada verificação e a cada ping de visita registrados. Política: “Pseudonymous ID” e “What the backend stores, and for how long”.

Verificação de e-mail e de página

• Gatilho. O botão Analyze no pop-up (Analyze Current Email ou Analyze Current Page), no painel lateral ou na barra de ferramentas do Gmail ou do Outlook na web. Em uma página comum, a aba é lida por meio de activeTab; nos quatro hosts de e-mail, pelo script de conteúdo já carregado ali.
• Hosts de e-mail. O modo e-mail existe apenas nos quatro hosts acima. O webmail em qualquer outro host, inclusive o Outlook em outlook.cloud.microsoft, recebe a verificação de página comum.
• Texto da página. Scripts, estilos e o painel lateral do PhishTriage são removidos. Nas builds mais recentes da versão 1.0.0, o aviso de página inteira também é removido; nas builds anteriores, clicar no botão Analyze enquanto o aviso está aparecendo envia o texto do aviso junto com a página. O texto oculto com display:none, visibility:hidden ou o atributo hidden é incluído. Nas builds mais recentes da versão 1.0.0, o limite de 10.000 caracteres soma a página e todos os frames que puderem ser lidos; as builds anteriores leem só a página, com limite de 5.000.
• Frames. Somente nas builds mais recentes da versão 1.0.0: o texto e os links dentro de frames são incluídos quando o navegador permite que a página os leia. Para um frame de outro site, é enviada apenas a contagem dos frames grandes o bastante para exibir conteúdo, mais um valor verdadeiro/falso que indica se a página é só um invólucro em torno de um frame. Quando a página não tiver título, o título de um frame de mesma origem é enviado como título — para um visualizador de documentos, costuma ser um nome de arquivo.
• A URL. Enviada por inteiro. Se ela contiver um token de sessão ou uma consulta de busca, eles são enviados como parte dela.
• Não lido. O conteúdo dos anexos. Campos de entrada: o que é digitado em um formulário não está no payload (mas veja a captura de evidências).
• Antes que um modelo leia o conteúdo. Os marcadores de prompt injection são removidos (e, quando uma linha começa como uma instrução, o resto dessa linha); o preenchimento invisível que as newsletters colocam depois da linha de pré-visualização é reduzido; quebras de linha em campos de linha única viram espaços. Na cópia que o modelo lê (não na armazenada), as cópias que a própria mensagem tem dos títulos de seção do PhishTriage são marcadas com “(quoted)”. Nada é removido por motivos de privacidade: nenhum endereço, URL ou nome é apagado.
• Armazenado. Registro de triagem: o corpo da requisição como acima, o veredito, o pseudoId, o extensionId, um hash do IP, uma chave de cache, um carimbo de data e hora, qual nível de modelo respondeu (com o motivo da falha de um nível anterior, se houve) e a data em que será excluído (veja Retenção). O log do servidor também registra cada verificação que chega a um modelo, com o IP bruto, e não é excluído automaticamente; veja Endereços IP e o log da aplicação.

Política: “When you click ‘Analyze’ (on-demand triage)” e “What the backend stores, and for how long”.

Captura de evidências

• Padrão. Ativada, a menos que seja desativada: pop-up, Settings, Keep evidence of phishing. A opção é mostrada durante a configuração inicial. Os administradores podem definir qualquer um dos dois valores com evidenceCapture.
• Quando. A captura de tela e o HTML são feitos no momento em que alguém clica no botão Analyze em uma página da web, antes de o veredito existir, e ficam apenas na memória da extensão. Só são enviados se o veredito for phishing ou suspeito; com qualquer outro veredito, os dois são descartados. Nada é capturado em páginas chrome://, na Chrome Web Store nem em páginas de outras extensões.
• O quê. Um JPEG da parte visível da aba e o HTML completo da página, sem filtro — não o extrato de texto descrito acima. Uma captura com mais de 1 MiB depois de compactada é descartada por inteiro.
• A exceção para e-mail são quatro nomes de host, não uma regra sobre e-mail. Em mail.google.com, outlook.office.com, outlook.office365.com e outlook.live.com, nada é capturado. Em qualquer outro host de webmail — Yahoo Mail, Proton Mail, Fastmail, Zoho Mail, Roundcube, o Outlook Web Access próprio de uma empresa —, um veredito de phishing ou suspeito envia uma captura de tela da caixa de entrada e o HTML da página, inclusive o da mensagem aberta. Isso inclui o Outlook em outlook.cloud.microsoft.
• Valores digitados. A captura de tela mostra qualquer coisa digitada que ainda esteja visível. O HTML normalmente não contém os valores digitados, mas uma página pode gravá-los de volta em sua marcação.
• Armazenado. A captura de tela e o HTML, um SHA-256 de cada um, o veredito e a chave de cache da verificação, os IDs da conta e do dispositivo, o horário de recebimento e o horário de captura informado pelo navegador.
• Retenção. Phishing: 12 meses. Suspeito: 30 dias. Uma captura suspeita que um revisor confirma passa para 12 meses. Rejeitada por um revisor: excluída imediatamente. Excluída junto com a conta. O período do histórico de verificações não se aplica às evidências, e a rotina de limpeza do histórico de verificações não as toca.
• Manuseio. O HTML armazenado nunca é renderizado no portal; ele é baixado como um arquivo inerte e servido como texto simples. Uma captura de tela que não é de fato uma imagem é recusada.

Política: “Keeping evidence of phishing pages”. Nos hosts de e-mail, as linhas acima descrevem o comportamento da versão 1.0.0, a das lojas. A política 1.10 descreve a próxima versão, a 1.1.0, que, nesses hosts, guarda uma captura de tela recortada para a mensagem analisada e o HTML dessa mensagem, nunca a caixa de entrada.

Background protection e Send full URLs

• Interruptores. O interruptor Background protection é o rastreamento de domínios. O interruptor Send full URLs, na seção Advanced, é o rastreamento de URLs. Os dois vêm desativados por padrão. Ativar qualquer um deles pede webNavigation e <all_urls>; recusar mantém o interruptor desativado.
• O rastreamento de domínios envia o nome do host para /visit com o tipo domain a cada navegação. A URL completa não é enviada. O cache opcional (desativado por padrão) limita isso a uma vez por hora por domínio.
• O rastreamento de URLs envia a URL completa, com caminho e string de consulta, a cada navegação do frame principal, com o tipo url.
• Resposta. Um veredito de ameaça. Se o backend considera a página perigosa, a extensão injeta o script de conteúdo dela nessa página para mostrar um aviso de página inteira.
• Histórico. webNavigation dispara apenas em navegações futuras. A extensão não enumera nem lê o histórico do navegador.
• Armazenado. Registro de visita: a URL ou o nome do host, o tipo, o pseudoId, o extensionId, o hash do IP, o carimbo de data e hora e a data em que será excluído (veja Retenção). Acima de um número definido de verificações de um mesmo dispositivo em uma hora, a verificação ainda recebe resposta, mas nenhum registro é gravado. O log do servidor também registra a URL ou o nome do host de cada verificação registrada e não é excluído automaticamente; veja Endereços IP e o log da aplicação.
• Frotas gerenciadas. trackDomains e trackVisits forçam o respectivo interruptor a ficar ativado ou desativado, e um valor forçado prevalece sobre o pop-up. Forçar um deles a ficar ativado não concede webNavigation nem acesso a todos os sites; sem webNavigation, nada é enviado.

Política: “When you opt into URL or Domain Visit Tracking”.

File protection (proteção de arquivos)

• Onde. Ativada na seção Settings, onde a build mostra o interruptor File protection; ou por política (fileProtection). Ativá-la pede downloads e acesso a todos os sites em conjunto.
• No dispositivo. Um arquivo que uma página cria (blob: ou data:) é lido na memória do navegador e verificado ali; os bytes são descartados logo em seguida. Um download comum é buscado uma segunda vez no próprio endereço, para ser lido, com os cookies da pessoa para aquele site, de modo que um arquivo protegido por login pode ser lido. Essa requisição não leva nenhum cabeçalho, identificador ou parâmetro nosso. Um link de uso único pode falhar na segunda busca; a verificação passa então a usar o nome e o tipo do arquivo.
• Enviado para todo download: a impressão digital SHA-256, o nome do arquivo, o tamanho, o veredito da extensão e os motivos resumidos dele. A maioria dos motivos é composta de frases fixas; alguns citam o nome ou a extensão do próprio arquivo; um cita o nome de um executável encontrado dentro de um arquivo compactado baixado. A impressão digital é comparada com impressões digitais de malware conhecido.
• Não enviado para consulta: o endereço do download. Ele é verificado no dispositivo, em uma lista de ameaças que a extensão atualiza a partir do nosso backend no máximo uma vez por hora, quando um download a leva a consultá-la.
• O arquivo em si só é enviado com o botão Check it properly (oferecido quando uma verificação é inconclusiva; apenas aquele arquivo) ou com a opção Deep scan every file ativada (todo download; desativada por padrão; pode ser exigido por política com deepScanAlways). Ele é verificado na memória, em hardware nosso, e não é armazenado; só o registro de verificação de arquivo abaixo é mantido.
• Armazenado. Toda verificação que chega a filescan.phishtriage.com, inclusive a verificação padrão por impressão digital, deixa um registro de verificação de arquivo: a impressão digital, o nome do arquivo (até 300 caracteres), o tamanho, o veredito, qual verificação o produziu, o mecanismo da verificação profunda ou a assinatura de malware com a qual houve correspondência, quando houve, o pseudoId, o extensionId, o horário e a data em que será excluído (veja Retenção). O painel da própria pessoa não o mostra; em uma equipe, os proprietários o veem na lista Scans da página Team, exceto no modo agregado.
• Log do verificador de arquivos. Uma linha por requisição: a requisição, o status, a duração e os oito primeiros caracteres do extensionId; para uma verificação de arquivo, também o veredito, qual verificação o produziu, se uma verificação profunda foi oferecida, uma assinatura de malware correspondente e os primeiros 60 caracteres do nome do arquivo. Nem o endereço IP, nem o arquivo. Nada o exclui automaticamente; veja Endereços IP e o log da aplicação.
• O que não é feito. Os arquivos que já estão no disco não são lidos, a pasta Downloads não é monitorada e um download comum não pode ser interrompido antes de ser salvo; nesses casos, a extensão avisa depois que o arquivo chega e se oferece para excluí-lo.

Política: “When you opt into File protection (early access)” e “Third-party processors”.

Botões de feedback

Na versão 1.0.0, clicar no botão Looks safe to me ou no botão Looks dangerous não envia nada. O painel lateral mostra “Thanks — saved on this device.” A resposta fica no armazenamento local da extensão: até 100 entradas, cada uma com o veredito, o botão clicado, o horário, se era um e-mail ou uma página da web e o endereço completo da página ou da mensagem de e-mail em que o botão foi clicado. Os botões Sign out e Leave team não limpam essas entradas; já remover a extensão, ou limpar o armazenamento dela, apaga as entradas. A política 1.10, escrita para a 1.1.0 e posteriores, descreve o envio de um clique por padrão; veja a seção “Your corrections to a verdict” da política.

Login no portal

• Fluxo. O botão Log in do pop-up abre o portal; a pessoa faz login com o Google nas páginas do Google. Nunca vemos uma senha.
• Armazenado. Conta: um ID de conta opaco, nome de exibição, funções, status, organização e momento de entrada. Identidade: emissor, o subject id do emissor, o endereço de e-mail, se o emissor diz que ele foi verificado, o domínio do Google Workspace, se houver, e os horários do primeiro e do último login. Os tokens de sessão, de dispositivo e de atualização são armazenados como hash. Sem expiração automática.
• A extensão recebe o ID da conta e o nome de exibição, e mostra “Signed in as” e esse nome. Ela não recebe o endereço de e-mail. Todo dispositivo conectado a uma mesma conta leva o ID dessa conta, e por isso as requisições deles são vinculadas no servidor.
• Sem login, não existe registro de identidade — com uma exceção: o proprietário de uma organização que convida alguém digita o endereço da pessoa no convite, e esse endereço fica armazenado a partir daí, com o convite aceito ou não.
• Google em todas as páginas do portal. Cada página carrega a biblioteca de login do Google de accounts.google.com e as fontes de fonts.googleapis.com e fonts.gstatic.com, antes do login, e independentemente de alguém fazer login ou não. Isso informa ao Google o endereço IP do visitante, o navegador e que ele esteve no portal. Nenhum dado de verificação vai para o Google.

Política: “Account and identity records”, “Pseudonymous ID” e “Third-party processors”.

Onde a análise acontece

Tudo o que precisa de um modelo é oferecido a backends em uma ordem fixa. O primeiro a devolver uma resposta utilizável é o que responde:

1. um modelo que o PhishTriage hospeda por conta própria, em uma máquina que opera na própria rede;
2. um serviço de modelos de terceiros (Ollama Cloud) — não configurado em nenhuma implantação na data de vigência;
3. a API Claude da Anthropic, o último recurso.

Um nível só é consultado se estiver configurado, não estiver desativado e a requisição ainda tiver tempo restante. Um nível que falha — inacessível, lento demais, com erro, com limite de taxa, com saída que não pode ser interpretada ou com formato errado — passa o mesmo conteúdo ao seguinte. A política deliberadamente não promete que o conteúdo permaneça em hardware do PhishTriage e não informa nenhuma proporção: o fallback é uma regra, não uma proporção. Na semana de 17 de agosto de 2026, uma configuração incorreta enviou todas as verificações à Anthropic.

Para alguns e-mails, é feita uma segunda requisição ao nível que acabou de responder, com o mesmo conteúdo e uma instrução adicional. Ela nunca segue adiante e nunca vai para a Anthropic. O registro de triagem armazenado anota qual nível respondeu. A política não diz onde fica o servidor do modelo.

Política: “Where analysis happens”.

Operadores e destinos

Os dados da extensão vão para destinos que o PhishTriage opera:

• api.phishtriage.com — análise, verificações de visita, evidências e contas;
• filescan.phishtriage.com — somente com a proteção de arquivos ativada;
• um hub de inteligência interno, acessado pelo backend e nunca pelo navegador. Todo fluxo para ele está desativado na configuração distribuída e no serviço hospedado; veja a seção “Shared threat intelligence” da política.

Os registros ficam em um banco de dados PostgreSQL, em hardware que o PhishTriage possui e opera, na Estônia. Nenhum provedor de armazenamento de terceiros guarda esses registros desde que a produção migrou para o PostgreSQL, em agosto de 2026. Os operadores que a política cita:

• Anthropic — a API Claude, o último nível da ordem acima. Operadora segundo os termos da API dela, pelos quais as entradas não são usadas para treinar modelos.
• Ollama — o Ollama Cloud, o nível intermediário. Citado antes do uso; não configurado em nenhuma implantação na data de vigência.
• Cloudflare, Inc. — transporta o tráfego entre o navegador e nosso servidor (terminação TLS, tunelamento, proteção contra DDoS). Apenas dados em trânsito; não armazena registros.
• Stripe — pagamentos, e apenas se alguém iniciar um checkout de um plano. No checkout, recebe o endereço de e-mail com que a pessoa fez login e guarda o cartão; nós armazenamos uma referência opaca e nunca vemos um número de cartão.
• Google — login no portal e todo carregamento de página do portal, como acima. A política observa que o login em si não é uma relação de operador. Ela também diz que recebemos os avisos de Proteção entre contas (Cross-Account Protection) do Google, e é assim que uma Conta do Google invadida ou desativada perde a sessão no portal.
• Elastic Cloud — o armazenamento de dados anterior, que guardava registros de antes da migração de agosto de 2026. O projeto foi excluído em 2 de outubro de 2026 e nenhuma cópia foi mantida. O que a Elastic retém de um projeto excluído é regido pelos termos dela.

O produto não inclui análise de uso (analytics), publicidade, SDKs de telemetria, serviços de relatório de erros nem bibliotecas de fingerprinting. Com a proteção de arquivos ativada, a segunda busca de um download comum vai para o próprio host do download, como descrito acima. Política: “Third-party processors”.

Endereços IP e o log da aplicação

• Banco de dados. Os registros de triagem guardam um hash do IP: os 12 primeiros caracteres hexadecimais (48 bits) de um SHA-256 sem salt. O espaço IPv4 é pequeno o bastante para reverter esse hash, então ele deve ser considerado pseudonimizado, não anonimizado. Os registros de visita também guardam um hash do IP.
• Linha de log de triagem, para toda verificação que chega a um modelo: o endereço IP bruto, o horário, o e-mail ou a página, o pseudoId, um hash do endereço do remetente, o tamanho do assunto, o veredito, a confiança e a pontuação de risco, o indicador de escalonamento, qual nível respondeu e por que um anterior falhou, e a duração. Em uma verificação de página, o “remetente” é o nome do host e o “assunto” é o título; assim, ao lado do IP bruto, a linha praticamente identifica o site. Ela não traz corpo, texto da página, assunto, título nem URL completa. Um acerto de cache registra apenas a chave de cache e o horário.
• Linha de log de visita: o horário, o hash do IP, o tipo, a URL ou o nome do host, se um registro foi gravado e a duração. Para uma verificação que não é registrada (veja Background protection acima), apenas o horário, o tipo, a informação de que não foi registrada e a duração: sem hash de IP e sem URL ou nome do host.
• Linhas de log de capacidade, na primeira vez em uma hora em que verificações de um endereço de rede são recusadas porque ele esgotou a cota por hora, ou em que o serviço atinge o teto por hora: o horário, quando a hora termina, a cota ou o teto, e um hash de um endereço (o mesmo hash sem salt de 12 caracteres; para IPv6, do bloco do endereço). Para o teto, o endereço com hash que enviou mais verificações naquela hora, com a quantidade.
• Log do verificador de arquivos (com a proteção de arquivos ativada): sem endereço IP; veja File protection acima.
• Tempo de vida. Nada em nenhuma das duas aplicações exclui esses logs, e a rotina de limpeza de retenção não os toca. Um pedido de exclusão a privacy@phishtriage.com que cite um extensionId abrange esses logs, inclusive as linhas que levam apenas o pseudoId ou o ID de conta a que esse extensionId pertence, e nós apagamos essas linhas manualmente. Uma linha de capacidade não tem extensionId: ela cita um endereço com hash e nada mais sobre ninguém.

Política: “What the backend stores, and for how long” e “The application log”.

O que fica no dispositivo

• A identidade: pseudoId, extensionId, tokens da organização e do dispositivo. Os botões Sign out e Leave team os limpam e, na mesma hora, registram uma identidade nova.
• As entradas de feedback descritas acima.
• Com a proteção de arquivos ativada: a lista de bloqueio de URLs e quando ela foi obtida.
• Os nomes de downloads arriscados para os quais não foi possível mostrar um aviso na hora.
• Com a opção Background protection e o cache dela ativados: os nomes de host visitados na última hora.
• As configurações, em chrome.storage.sync: se a sincronização estiver ativada, a sincronização do navegador pode copiá-las para a conta com que o navegador sincroniza (uma Conta do Google, uma conta da Microsoft ou da Mozilla, ou a cadeia de sincronização do Brave). São posições de interruptores, não conteúdo.

Os pedidos de exclusão atuam em nossos servidores e não alcançam o perfil do navegador. Política: “What the extension keeps on your own device”.

Resumo da retenção

• Os registros de triagem, de visita e de verificação de arquivo recebem, cada um, uma data de exclusão quando são gravados, com base no período em vigor naquele momento para a conta sob a qual são gravados:
  • Padrão: 365 dias, para os registros gravados desde 4 de outubro de 2026, a data de vigência da política 1.10. Antes disso, 90 dias.
  • O período de uma equipe: um proprietário pode escolher de 7 a 365 dias, na página Team, na seção Scan history (veja Configure o PhishTriage para uma equipe). Ele se aplica a todos os membros da equipe e a todos os dispositivos que a equipe configurou.
  • O período de cada pessoa: qualquer pessoa que fez login no portal pode escolher de 7 a 365 dias para os próprios registros: Dashboard, Your data, How long we keep your scans, Keep my scans for. Em uma equipe, o período da equipe ou um mais curto, nunca um mais longo; se o proprietário definir depois um período mais curto que o do membro, o da equipe vale para os novos registros do membro. Isso abrange as verificações de dispositivos vinculados à conta da pessoa; os dispositivos que a organização configurou seguem o período da equipe. Os proprietários não veem o período que um membro escolhe.
  • Não retroativo: uma mudança define a data de exclusão apenas dos registros gravados depois dela. 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. Os registros de verificação e de visita gravados antes de 4 de outubro de 2026 mantêm 90 dias. Os registros de verificação de arquivo não tinham data de exclusão até que todos os registros recebessem uma, pouco antes de a política 1.10 entrar em vigor: os feitos antes disso receberam 365 dias a contar de quando cada um foi feito, e os feitos entre aquele momento e 4 de outubro de 2026 receberam 90.
  • A rotina de limpeza remove várias vezes ao dia os registros cuja data já passou, então um registro pode durar algumas horas além da data.
  O log da aplicação, que também registra verificações e visitas, não passa pela limpeza (abaixo).
• Envios dos botões de feedback: 90 dias após o recebimento, qualquer que seja o período aplicável às verificações. A versão 1.0.0 não envia nenhum.
• Alterações de um período: cada alteração é registrada com quem a fez, de qual período para qual e quando, e, no caso do período de uma pessoa, o período da equipe naquele momento. Nenhum conteúdo de verificação. Nem a rotina de limpeza nem o botão Delete my scan history removem esse registro.
• Evidências: 12 meses para phishing (e para capturas suspeitas que um revisor confirma); 30 dias para suspeitas; excluídas imediatamente se um revisor as rejeitar; excluídas junto com a conta. Não seguem o período do histórico de verificações.
• Registros de dispositivo: sem expiração.
• Registros de conta e de identidade: sem expiração automática. O registro da conta guarda o período da própria pessoa, se ela escolheu um, e quando; o registro da organização guarda o da equipe.
• Log da aplicação: registra cada verificação que chega a um modelo e cada verificação da opção Background protection ou da opção Send full URLs; não é excluído automaticamente; as linhas de uma pessoa são apagadas manualmente mediante solicitação a privacy@phishtriage.com. O mesmo vale para o log do verificador de arquivos.
• Os arquivos enviados por inteiro são verificados na memória e não são armazenados; só o registro de verificação de arquivo é mantido.
• Os registros que um dispositivo fez antes de ser vinculado a uma conta permanecem sob a identidade anterior do dispositivo. Eles não aparecem no painel, não podem ser alcançados pela ação de exclusão e são excluídos pela rotina de limpeza na data que cada um recebeu quando foi gravado.
• Depois de sair da conta: quando um clique no botão Sign out ou no botão Leave team descarta a identidade de um dispositivo, os registros feitos sob ela não podem mais ser alcançados a partir de nenhum dispositivo ou conta. A rotina de limpeza os exclui na data que cada um recebeu.
• O cache de triagem de uma hora considera apenas registros com menos de uma hora.

Política: “Retention” e “Keeping evidence of phishing pages”.

O que a equipe pode ver

As equipes são criadas no portal (botão Create a team). Somente proprietários podem abrir a página Team; todo membro, proprietário ou não, vê o painel e suas listas. O que ambos mostram depende do modo de relatório da equipe (Reporting mode). Toda equipe começa no modo Aggregate. Isto descreve o portal em produção.

• Não retroativo. Um proprietário muda o modo com o botão Turn on attributed reporting. A atividade registrada antes da mudança nunca é mostrada por pessoa. O botão Switch to aggregate volta a ocultar na hora o detalhamento por pessoa; reativar o modo por pessoa inicia uma nova janela, e o período intermediário nunca é mostrado por pessoa.
• Desde a entrada, nos dois modos. As listas e os totais da equipe incluem as verificações de um membro somente a partir do momento em que ele entrou — para o proprietário que criou a equipe, o momento em que ela foi criada. As verificações registradas antes disso não são mostradas à equipe nem contadas para ela e, enquanto a pessoa está na equipe, também deixam de aparecer no painel da própria pessoa. No modo agregado, todas as listas do painel, inclusive as verificações da própria pessoa, mostram “Not shown”.
• Como as pessoas entram em uma equipe. Aceitando um convite; por meio de um token de registro enviado ao dispositivo por política; ou automaticamente, quando uma organização provou ser dona de um domínio de e-mail e alguém faz login no portal com um endereço do Google verificado nesse domínio. A entrada automática não tem convite, pergunta nem aviso no login; o portal mostra depois qual organização, quando e qual domínio. Uma conta que já está em uma organização nunca é movida. Um domínio pode ser comprovado por um registro TXT de DNS ou pelo tenant do Google Workspace, então verificar o DNS não descarta essa possibilidade.
• Exclusão. Nenhuma função de organização pode excluir o histórico de um membro nem desfazer a exclusão feita pelo próprio membro.

Fontes: a página Team do portal; as seções “Keeping evidence of phishing pages” e “Account and identity records” da política.

Pedidos de exclusão e de acesso

• Autoatendimento. Pessoas que fizeram login: portal, Dashboard, Your data, Delete my scan history. O botão remove todo registro de triagem, de visita e de verificação de arquivo, todo envio dos botões de feedback e toda captura de evidências armazenada na conta — inclusive as capturas cujo registro de verificação já expirou — imediatamente e de forma irreversível, sem esperar as datas de exclusão. Ele alcança apenas os registros dessa conta. Não remove o registro do dispositivo nem o registro das alterações de um período de retenção, e não alcança os registros que um dispositivo fez antes de ser vinculado.
• Uma captura. Na lista Phishing Evidence, é possível excluir uma única captura de tela e o código-fonte da página correspondente. Dentro de uma equipe, essa é uma ação de proprietário, e só no modo por pessoa.
• Por e-mail. privacy@phishtriage.com com o pseudoId ou o extensionId, para acesso, exclusão ou oposição — inclusive o registro do dispositivo e as linhas do log da aplicação. O pop-up mostra os oito primeiros caracteres do extensionId em Settings, Advanced, Device ID; envie esses caracteres com o navegador e a data aproximada da instalação. Cada instalação de navegador que nunca foi vinculada tem o próprio pseudoId. Respostas em até 30 dias.
• O que não existe no portal: não há botão de exclusão de conta nem botão de remoção de dispositivo. As duas coisas passam por privacy@phishtriage.com.
• Revogação do consentimento para o monitoramento. Desative a opção Background protection (e a opção Send full URLs) ou remova a permissão webNavigation em chrome://extensions → PhishTriage → Details → Permissions (Chrome, Edge, Brave) ou about:addons → PhishTriage → Permissions (Firefox). Remover webNavigation interrompe as verificações de visita na hora, mas não redefine os interruptores. Remover apenas o acesso a todos os sites não as interrompe: nomes de host ou endereços continuam sendo enviados. Em uma frota gerenciada, a configuração é do administrador.
• Outros direitos: o de se opor (por e-mail) e o de apresentar reclamação a uma autoridade de proteção de dados na União Europeia ou no Reino Unido.

Política: “Retention” e “Your rights”.

Chaves de política do administrador que alteram fluxos de dados

Essas chaves existem no esquema de armazenamento gerenciado (managed storage) da versão 1.0.0. Uma chave definida prevalece sobre o interruptor da pessoa. O pop-up marca cada interruptor controlado com um selo Managed e o desativa. Quando proxyUrl, trackDomains, trackVisits ou cacheDomainVisits está definido, a seção Settings também mostra o aviso “Some settings are managed by your organization and can’t be changed here.” Não há chave para os botões de feedback, porque nesta versão eles não enviam nada.

• proxyUrl — o backend para o qual vai tudo o que se destinaria a api.phishtriage.com. Deve ser https://; sem definição, vale o padrão. Não há configuração de usuário para ela.
• filescanUrl — o endpoint do serviço de verificação de arquivos (https://). Usado apenas pela proteção de arquivos.
• trackDomains — força a opção Background protection (nome do host a cada navegação) a ficar ativada ou desativada.
• trackVisits — força a opção Send full URLs a ficar ativada ou desativada. Se ela for forçada a ficar ativada, a URL completa de toda navegação do frame principal vai para o backend.
• cacheDomainVisits — define se o cache de domínios de uma hora é usado.
• evidenceCapture — força a opção Keep evidence of phishing a ficar ativada ou desativada. Para o usuário, o padrão é a opção ativada.
• fileProtection — força a proteção de arquivos a ficar ativada ou desativada. Forçá-la a ficar ativada não concede a permissão downloads nem o acesso a todos os sites; sem eles, nada é verificado.
• fileBlocking — força o modo de bloqueio da proteção de arquivos, que retém um arquivo criado por uma página e pergunta antes de salvar, ou o modo de aviso. A impressão digital é enviada nos dois modos; o cartão de um arquivo retido também pode oferecer o botão Check it properly.
• deepScanAlways — envia todo arquivo baixado para uma verificação completa. Exige a proteção de arquivos.
• enrolmentToken — enviado com o registro para vincular o dispositivo a uma organização. Nenhum e-mail de usuário é coletado. Um token inválido ou expirado deixa o dispositivo sem vínculo com a organização.

Onde cada navegador recebe essas chaves, como um token de registro vincula navegadores a uma equipe e as permissões de que um interruptor forçado ainda precisa: Implante o PhishTriage por política do navegador. A implantação gerenciada é oferecida no plano corporativo; podemos configurá-la com você (entre em contato).