QA Buddy — Política de privacidade

Última atualização: alinhada à versão da extensão no manifest.json. Publique esta página no seu site ou na loja de extensões e mantenha o link no README.

Controlador / contato

Substitua este bloco pelos dados legais da sua empresa ou do mantenedor do QA Buddy (e-mail de privacidade, jurisdição).

Dados que a extensão processa

Dado Onde fica Finalidade
Erros de console e avisos (texto truncado e redigido) Memória volátil do processo da extensão (service worker / painel) — não em storage.local Monitor de QA na aba atual
Falhas de rede vistas via fetch/XHR na página (URL sem query string, método, status, trechos de corpo/cabeçalhos redigidos e truncados) Idem Diagnóstico de APIs e CORS
Falhas só ao nível do navegador (webRequest, rede bloqueada) Idem URL, método, status, cabeçalhos de pedido (quando o browser expõe com extraHeaders) e de resposta redigidos — sem corpo de pedido nem corpo de resposta neste caminho (limitação da API webRequest)
Metadados da página (título, hostname, viewport, user-agent) Idem (associados ao buffer de logs em memória) Contexto do relatório
Capturas de tela e imagens editadas Memória da sessão / download explícito pelo usuário Evidência de bug
Chave de licença Pro (se informada) storage.local Validação contra o Worker HTTPS configurado em license-config.js
Preferências (tema, idioma, estado do gravador/inspetor) storage.local UX da extensão

A extensão não envia o corpo das requisições das páginas que você visita para servidores do QA Buddy. A redação de cabeçalhos sensíveis (Cookie, Authorization, etc.) e de campos comuns em JSON é heurística.

Chrome Web Store (pacote build:store): o artefato publicado não contém o script de preenchimento automático (Faker) nem o motor de gravação de passos; apenas pré-visualização estática do gravador. Isso reduz superfície de dados gerados automaticamente na página.

Integridade dos logs de rede: eventos vindos do hook fetch/XHR na página usam um token de canal definido na injeção pela extensão. Scripts arbitrários na página que não conhecem esse token não devem aparecer no monitor; scripts maliciosos na mesma página ainda podem tentar ler o token no contexto da página — use o monitor como apoio, não como prova forense isolada.

Corpos HTTP e webRequest: corpo de pedido e corpo de resposta no painel vêm do hook fetch/XHR no content script da página. A API webRequest do browser não fornece esses corpos; só pode complementar cabeçalhos de pedido (dependendo do browser e de permissões como extraHeaders). Eventos webRequest são associados ao mesmo buffer que a aba que originou o pedido (quando há tabId), para deduplicar com o log rico da página.

Agrupamento dos logs: o buffer em memória indexa entradas pelo hostname da página (aba ativa). Chamadas fetch/XHR feitas pela página para outro host (ex.: API) aparecem nesse mesmo buffer. Os eventos webRequest passam a preferir o mesmo hostname da aba quando disponível; se tabs.get falhar, mantém-se o hostname do URL do pedido. O fallback “todos os logs” no painel continua a devolver um único buffer recente quando a aba não tem URL HTTP(S).

Licença e rede

Retenção e exclusão

Content scripts e páginas sensíveis