Como avaliar um navegador para equipas: uma lista de verificação prática

Defina a decisão antes de abrir uma página de preços

Uma avaliação útil começa pelo trabalho, não pela lista de fornecedores. Registe:

• os fluxos autorizados e os sistemas que os permitem;
• o número de pessoas, perfis guardados, perfis sincronizados e sessões simultâneas do navegador;
• os sistemas operativos e as arquiteturas de processador suportados;
• os motores de navegador, extensões, proxies, fornecedores de identidade e clientes de automação necessários;
• as obrigações de localização, retenção, exportação, eliminação e auditoria de dados;
• as expectativas de tempo de recuperação e perda de dados aceitável;
• as necessidades de acessibilidade dos operadores e administradores;
• o orçamento, período de faturação, cobertura de apoio e condições de saída; e
• os fluxos proibidos que o produto não pode permitir à sua equipa.

Mantenha separados os tipos de recursos. Um plano com 500 perfis guardados, 100 perfis sincronizados na nuvem, cinco lugares e dez sessões simultâneas não fornece 500 sessões simultâneas à equipa. Traduza cada limite para a unidade consumida pelo seu fluxo.

Em seguida, identifique os requisitos incontornáveis. Um conjunto comum inclui:

1. compilações do navegador suportadas e atuais;
2. ausência de corrupção silenciosa dos perfis ou de processos de escrita simultâneos;
3. identidades individuais com acesso revogável e de privilégio mínimo;
4. ausência de segredos em bruto nos registos correntes ou nos resultados de automação;
5. provas de auditoria utilizáveis;
6. um percurso de restauro e saída testado; e
7. utilização legal e autorizada, coerente com os termos dos serviços aplicáveis.

Não dilua um requisito falhado numa pontuação numérica média. Uma interface cuidada não compensa um atualizador não verificado nem um processo de restauro que perde estado.

Utilize uma escala de provas simples

Para cada elemento da lista, registe o resultado e as provas mais fortes obtidas.

Resultado

• Aprovado: o requisito declarado foi demonstrado no ambiente de teste definido.
• Preocupação: o comportamento entra em conflito com o requisito ou cria um compromisso significativo.
• Não verificado: as provas estão em falta, inacessíveis, obsoletas ou são demasiado ambíguas para decidir.
• Não aplicável: o requisito não se aplica realmente ao fluxo, e o motivo fica registado.

Provas

1. Afirmação publicada: texto comercial ou de vendas.
2. Documentação técnica: documentação do produto, segurança, API ou apoio com versão definida.
3. Demonstração observada: demonstração ao vivo do fornecedor com o seu cenário.
4. Teste controlado: a sua equipa reproduz o comportamento com dados descartáveis e regista versões e resultados.
5. Provas independentes ou contratuais: uma avaliação limitada, um compromisso assinado ou uma condição de apoio que abrange o requisito.

Uma categoria mais elevada de provas não é automaticamente melhor em todos os casos. Um relatório independente pode excluir o navegador para computador, enquanto um teste controlado pode exercitá-lo diretamente. Registe o âmbito, a data, a versão e as limitações de cada artefacto.

1. Estado do produto e limites das afirmações

• □ Existe uma compilação real e instalável para todas as plataformas e arquiteturas de que precisa?
• □ O fornecedor consegue identificar a versão atual da aplicação, a versão do navegador e a data de lançamento?
• □ As funções beta, de pré-visualização, experimentais e de disponibilidade geral estão identificadas separadamente?
• □ A documentação e o teste efetivo coincidem quanto aos limites e ao comportamento?
• □ As afirmações de segurança, disponibilidade, encriptação e desempenho estão limitadas a componentes e provas específicos?
• □ Estão publicadas as limitações conhecidas, os fluxos não suportados e as regras de fim de suporte?
• □ O fornecedor evita garantias de invisibilidade, sobrevivência das contas ou acesso a serviços de terceiros?

Capture o instalador, o ecrã de versões, as notas de versão e a documentação relevante na data da avaliação. Uma resposta comercial sem referência estável permanece uma afirmação publicada, não comportamento verificado.

2. Isolamento e integridade dos perfis

Comece por definir o que o produto chama perfil. Pode referir-se a um diretório persistente de dados do navegador, um contexto temporário do navegador, um arquivo sincronizado, uma sessão remota ou uma coleção de definições. Não são equivalentes.

O Chromium documenta o diretório de dados do utilizador como o local dos dados e explica como escolher um diretório personalizado. A documentação também indica casos em que duas instâncias em execução não podem partilhar um diretório. Utilize a documentação a montante sobre o diretório de dados do utilizador como ponto de partida e exija, depois, provas específicas do produto.

• □ Cada perfil persistente tem um limite de armazenamento e processos claramente definido?
• □ O produto impede dois processos de escrita de abrirem o mesmo estado mutável do perfil?
• □ Os cookies, o armazenamento, a cache, o histórico, as extensões, as transferências, as permissões e as preferências estão isolados tal como documentado?
• □ As sessões temporárias e os perfis persistentes estão identificados de forma diferente?
• □ Um arranque limpo utiliza apenas os dados do perfil pretendido?
• □ Um reinício preserva exatamente o estado que o produto promete preservar?
• □ As permissões e as origens de instalação das extensões são controladas?
• □ As importações de perfis são tratadas como dados não fidedignos e validadas antes da utilização?
• □ Um perfil danificado ou incompatível pode ser colocado em quarentena sem substituir uma cópia em bom estado conhecida?

As provas do teste devem incluir verificações entre perfis. Defina um marcador inofensivo no perfil A, confirme que está ausente no perfil B, reinicie ambos e repita depois de uma atualização da aplicação. Utilize contas descartáveis e dados sintéticos.

3. Atualidade do navegador, sandbox e atualizações

Um navegador é uma dependência de segurança mantida continuamente. A documentação atual dos canais do Chromium indica que o canal Stable recebe atualizações secundárias semanais e atualizações principais a cada quatro semanas. Essa cadência de versões não determina o nível de serviço exato de um fornecedor, mas demonstra por que razão «baseado no Chromium» é uma descrição incompleta sem provas da versão e das atualizações.

• □ Consegue associar a compilação do navegador do produto a uma versão exata a montante?
• □ Existe um objetivo ou histórico publicado para a adoção de atualizações de segurança a montante?
• □ Quem monitoriza as versões a montante e as correções urgentes?
• □ As atualizações da aplicação e do navegador são assinadas e autenticadas independentemente da ligação de transferência?
• □ Consegue verificar os resumos criptográficos dos artefactos, a proveniência da versão ou uma cadeia de custódia equivalente?
• □ As distribuições são faseadas, monitorizadas e podem ser interrompidas?
• □ A reversão evita restaurar uma versão que seja insegura segundo a política de segurança atual?
• □ As migrações do esquema dos perfis são testadas nos percursos de atualização e reversão suportados?
• □ O produto mantém a sandbox do navegador ativa durante a utilização normal?
• □ O fornecedor consegue explicar todos os processos sem sandbox ou privilegiados e a respetiva necessidade?

O Chromium descreve a sandbox como um limite que restringe código não fidedigno e aplica o privilégio mínimo tanto ao código dentro da sandbox como ao seu controlador. Analise o desenho da sandbox do Chromium e peça, depois, ao fornecedor para mostrar a configuração efetiva de produção. A afirmação de que um produto «utiliza Chromium» não demonstra que todas as medidas de mitigação a montante permanecem ativas.

Para a integridade das atualizações, The Update Framework é uma referência útil porque trata expressamente o comprometimento dos repositórios e das chaves de assinatura. A proveniência SLSA define informações verificáveis sobre onde, quando e como um artefacto foi produzido. Um fornecedor não precisa de utilizar exatamente estes projetos, mas deve explicar como o desenho trata a identidade dos artefactos, chaves comprometidas, reversão, congelamento e proveniência das compilações.

4. Identidade, dispositivos e privilégio mínimo

O NIST SP 800-53 Rev. 5 organiza controlos de acesso, auditoria, autenticação, planeamento de contingência, resposta a incidentes e risco da cadeia de fornecimento. Utilize estas famílias como questões orientadoras, não como prova de implementação por associação.

• □ Cada pessoa recebe uma identidade individual em vez de um início de sessão partilhado pela equipa?
• □ A autenticação multifator está disponível e pode ser imposta a administradores e outras funções sensíveis?
• □ São suportadas opções de autenticação mais fortes e resistentes a phishing quando o risco o exige?
• □ A identidade pode ser federada com o seu fornecedor, quando necessário, sem contornar a autorização do produto?
• □ As funções permitem separar de forma suficientemente precisa a consulta, o arranque, a edição, a partilha, a exportação, a eliminação, a faturação e a administração?
• □ O acesso pode ser limitado a uma organização, espaço de trabalho, pasta ou conjunto explícito de perfis?
• □ Um dispositivo, uma sessão, um utilizador, uma credencial de serviço ou um convite podem ser revogados rapidamente?
• □ As contas de serviço têm identidade, validade, âmbitos e limites de ritmo próprios?
• □ As alterações de permissões e as tentativas de autorização falhadas são visíveis no registo de auditoria?
• □ A saída de um membro remove o acesso sem exigir a alteração de uma palavra-passe partilhada?

Para a terminologia e as orientações atuais sobre garantia da autenticação, consulte o NIST SP 800-63B-4, finalizado em 31 de julho de 2025. Confirme que partes do produto são abrangidas pelas afirmações de autenticação do fornecedor: o início de sessão no site, o desbloqueio da aplicação, a API local, a API na nuvem, a recuperação e o acesso do apoio podem utilizar mecanismos diferentes.

5. Dados sensíveis e limites de confiança

Desenhe o produto como um fluxo de dados. Assinale o gestor para computador, os processos do navegador, o serviço local, o plano de controlo na nuvem, o armazenamento de sincronização, o atualizador, o sistema de relatórios de falhas, as ferramentas de apoio e as integrações de terceiros. Em cada limite, pergunte o que o atravessa e porquê.

• □ Que conteúdo dos perfis permanece local por predefinição?
• □ Que metadados e conteúdo sensível são carregados quando a sincronização está ativa?
• □ Onde ocorre a encriptação e que partes podem obter as chaves de desencriptação?
• □ Como são protegidas, copiadas, rodadas e recuperadas as chaves locais?
• □ O que podem ler os administradores da organização, o apoio do fornecedor, os operadores da infraestrutura e os clientes de automação?
• □ Os cookies, as palavras-passe, as credenciais de proxy, os segredos de dois fatores e as chaves de encriptação estão excluídos da interface, dos registos, da telemetria, das APIs e dos resultados dos agentes correntes?
• □ Os relatórios de falhas e diagnósticos podem ser pré-visualizados, são ocultados, consideram o consentimento e têm retenção limitada?
• □ O apoio consegue atuar sem pedir arquivos de perfis ou credenciais em bruto?
• □ As extensões importadas, os arquivos, as transferências do navegador e os metadados de atualização são tratados como dados não fidedignos?
• □ A eliminação está definida para cópias locais, objetos na nuvem, cópias de segurança, registos e artefactos de apoio?

Não aceite «encriptado» como resposta completa. Registe a categoria de dados, localização, limite de encriptação, detentor da chave, percurso de recuperação e situações em que existem dados em claro.

6. Colaboração e auditabilidade

• □ A propriedade dos perfis permanece clara durante a atribuição e a transferência?
• □ O produto consegue impedir ou resolver visivelmente edições simultâneas?
• □ Os convites, alterações de funções, arranques, paragens, partilhas, exportações, eliminações, chamadas de automação e ações de recuperação ficam registados?
• □ Cada evento identifica o interveniente humano, a carga de trabalho delegada, o recurso, a hora, a decisão e o resultado?
• □ Os valores anteriores e posteriores são registados em alterações relevantes de configuração, com os segredos ocultados?
• □ Os relógios, fusos horários, a ordem dos eventos e os identificadores dos pedidos são inequívocos?
• □ O acesso, o formato de exportação, a retenção e os controlos de eliminação da auditoria estão documentados?
• □ Um administrador pode alterar ou eliminar os mesmos registos utilizados para analisar as suas ações?
• □ A sua equipa pode exportar registos para o sistema de monitorização ou investigação?
• □ Quando o destino da auditoria está indisponível, os registos continuam, utilizam uma memória intermédia segura ou as ações falham de forma fechada?

As orientações da OWASP sobre registos recomendam registar falhas de autorização e ações de maior risco, capturar quando, onde, quem e o quê, controlar o acesso aos registos e evitar segredos técnicos. Aplique este teste aos eventos efetivamente exportados pelo produto, não apenas às capturas de ecrã de uma página de segurança.

7. Recuperação, interrupção e saída

Uma afirmação sobre cópias de segurança é incompleta até o restauro ser testado. O NIST Cybersecurity Framework 2.0 inclui resultados para criar, proteger, manter e testar cópias de segurança e para verificar os recursos de restauro e os sistemas restaurados.

• □ Consegue criar uma cópia de segurança coerente respeitando os bloqueios dos perfis?
• □ As versões locais e sincronizadas são identificáveis e estão ordenadas?
• □ Um operador consegue restaurar uma versão escolhida sem destruir a cópia atual?
• □ Os dados restaurados e a compatibilidade do navegador são verificados antes de retomar a utilização normal?
• □ O que acontece após terminar à força um processo do navegador, perder a rede, encher o disco, interromper um carregamento ou sofrer uma falha da aplicação?
• □ Uma última versão em bom estado conhecida fica protegida contra uma reparação falhada?
• □ Um dispositivo revogado ou perdido pode ser removido sem perder o único percurso de recuperação?
• □ As chaves ou os códigos de recuperação estão protegidos contra perda acidental e acesso ilimitado do administrador?
• □ A equipa consegue exportar os dados num formato documentado e verificar a exportação antes de cancelar o serviço?
• □ Existe um processo suportado de eliminação e encerramento da conta, com uma declaração clara da retenção residual?

Realize testes de recuperação apenas com dados de teste descartáveis, salvo se o fornecedor e o seu processo de alterações suportarem expressamente exercícios em produção. Registe o tempo de recuperação, o estado perdido, os passos manuais, os avisos e a versão do produto. Uma demonstração bem-sucedida num pequeno perfil não estabelece o desempenho nem a integridade à escala de produção.

8. Controlos de automação e desenvolvimento

• □ O produto expõe operações de domínio com versões definidas, em vez de acesso sem restrições a ficheiros ou processos?
• □ As capacidades de API, CLI, SDK, Playwright, CDP, WebDriver, webhook e agentes estão documentadas separadamente?
• □ Existe uma matriz exata de compatibilidade entre navegador e cliente?
• □ As credenciais podem ser limitadas por inquilino, perfil, operação, destinatário, validade, ritmo e custos?
• □ As ações destrutivas, em massa, externamente visíveis, com segredos ou que geram custos exigem políticas ou aprovações mais rigorosas?
• □ As pré-visualizações estão vinculadas ao pedido exato que será executado?
• □ Os comandos que alteram estado são idempotentes ou tornam explícitos os resultados desconhecidos?
• □ As operações demoradas podem ser canceladas e retomadas em segurança?
• □ A revogação entra em vigor durante uma tarefa ativa?
• □ As decisões de automação são atribuíveis no mesmo registo de auditoria das ações humanas?
• □ Os resultados correntes da automação conseguem ser úteis sem devolver estado de sessão em bruto?
• □ As mensagens de erro são suficientemente específicas para permitir a recuperação sem revelar segredos?

Teste os percursos de recusa. Um token apenas de leitura deve falhar ao iniciar um perfil. Um token limitado a um perfil deve falhar noutra pasta. Uma credencial expirada não deve ser renovada silenciosamente para obter acesso mais amplo. Um agente não deve conseguir transformar uma chamada recusada numa aprovação do administrador ao reformular o pedido.

9. Experiência do operador e acessibilidade

• □ Os utilizadores de teclado conseguem alcançar, utilizar e abandonar todos os controlos, diálogos, tabelas, menus e ações de perfis?
• □ O foco é visível e segue uma ordem lógica após navegação, erros e alterações de diálogos modais?
• □ Os rótulos, erros, alterações de estado e confirmações destrutivas funcionam com leitores de ecrã?
• □ A interface permanece utilizável com ampliação e texto aumentado?
• □ A cor, o movimento e os limites de tempo podem ser ajustados ou não são essenciais?
• □ Os operadores conseguem distinguir a organização, o perfil, o proxy, o ambiente e o estado de risco selecionados sem depender apenas da cor?
• □ É possível rever ações em massa sem obrigar os utilizadores a percorrer tabelas densas e inacessíveis?
• □ O comportamento nativo da plataforma, as notificações, os seletores de ficheiros, os pedidos de credenciais e os diálogos de atualização funcionam de forma coerente?

As WCAG 2.2 fornecem critérios testáveis para conteúdo web, incluindo utilização do teclado, ordem e visibilidade do foco, tamanho dos alvos, identificação de erros e autenticação acessível. Um produto para computador pode incluir interfaces nativas e web; combine as verificações de normas relevantes com testes de tecnologias de apoio em cada sistema operativo suportado.

10. Adequação comercial e operacional

• □ Os lugares, os perfis guardados, os perfis sincronizados, o armazenamento, o tráfego, as sessões simultâneas, o ritmo da API, os executores de automação e os níveis de apoio têm preços separados e claros?
• □ Que limites são bloqueios absolutos, custos adicionais ou condições de utilização razoável?
• □ As alterações de faturação ou capacidade podem ocorrer sem aprovação de um administrador?
• □ Os protocolos de proxy, métodos de autenticação, extensões e ambientes de rede suportados estão documentados?
• □ A política de apoio abrange incidentes de atualização do navegador, corrupção de perfis, falhas de restauro, comunicações de segurança e recuperação de contas?
• □ O estado do serviço, a comunicação de incidentes e os percursos de escalamento são reais e monitorizados?
• □ O contrato define a devolução e eliminação de dados, as alterações de preços, a suspensão e o termo?
• □ Consegue sair sem perder as provas necessárias para demonstrar uma migração segura?

Calcule o custo com base no pico de trabalho simultâneo, no estado sincronizado esperado, no volume de automação e nos requisitos de apoio. Registe impostos, compromissos anuais, custos adicionais e trabalho de migração. Evite comparar apenas o maior número de perfis em cada página de preços.

Um plano de teste controlado

Utilize contas de teste, credenciais sintéticas e perfis criados para a avaliação. Não importe cookies de produção apenas para tornar o teste realista.

1. Registe o ambiente. Anote as versões da aplicação e do navegador, o sistema operativo, o hardware, a rede, o tipo de proxy, o conjunto de extensões, o plano da conta e a data do teste.
2. Crie duas funções e vários perfis. Inclua um administrador, um operador limitado, pastas separadas e pelo menos um perfil a que o operador não pode aceder.
3. Execute o fluxo normal. Inicie, utilize, pare, transfira e volte a iniciar perfis. Registe o estado esperado e efetivo.
4. Exercite a recusa. Tente utilizar um perfil fora do âmbito, uma exportação, uma alteração de função e um comando de automação com a identidade limitada.
5. Exercite a interrupção. Com dados descartáveis, interrompa a paragem de um navegador ou um passo de sincronização através de um método suportado pelo fornecedor ou que seja seguro. Verifique o percurso de recuperação.
6. Restaure e compare. Restaure uma captura conhecida numa nova cópia, verifique a respetiva integridade e preserve a cópia atual até à aceitação.
7. Revogue o acesso. Remova um utilizador, um dispositivo, uma sessão e uma credencial de serviço; confirme a recusa na interface e na API e inspecione os eventos de auditoria.
8. Verifique a portabilidade. Exporte os dados permitidos, inspecione o formato documentado, volte a importá-los para um destino descartável quando suportado e identifique o que foi omitido.
9. Reveja a acessibilidade. Conclua as tarefas essenciais com o teclado e as tecnologias de apoio relevantes em cada plataforma necessária.
10. Concilie custos e afirmações. Compare a utilização de recursos e as respostas de apoio observadas com a proposta e o contrato.

Modelo de registo de decisão

Requisito	Prioridade	Resultado	Provas e data	Limitação ou risco	Responsável e próxima ação
Exemplo: o operador não consegue exportar o estado da sessão	Requisito	Aprovado	Teste controlado, versão X, AAAA-MM-DD	Apenas a superfície da API; CLI não testada	Responsável de segurança testa a CLI

Conclua a avaliação com quatro listas explícitas:

• requisitos aprovados com provas suficientes;
• preocupações aceites por um responsável identificado e com data de revisão;
• elementos que permanecem por verificar;
• condições que desencadearão uma nova avaliação, como um novo motor de navegador, fornecedor de identidade, atualizador, modelo de preços ou formato de perfis.

Sinais de alerta comuns

Suspenda a decisão quando:

• não for possível identificar a versão do navegador;
• a sandbox tiver de ser desativada na utilização normal;
• os administradores e a automação partilharem uma credencial permanente;
• o produto depender da partilha de cookies ou palavras-passe em bruto para transferências na equipa;
• uma API puder exportar segredos que a interface afirma proteger;
• os eventos de auditoria omitirem o interveniente ou não puderem ser exportados;
• «cópia de segurança» significar apenas que existe uma cópia na nuvem, sem restauro demonstrado;
• o fornecedor não conseguir explicar escritas interrompidas ou acesso simultâneo aos perfis;
• um fluxo crítico inacessível não tiver alternativa;
• uma comunicação de segurança exigir o envio de segredos por e-mail comum; ou
• as afirmações do produto prometerem indetetabilidade, acesso garantido a contas ou contorno da aplicação de regras da plataforma.

Um resultado «não verificado» não é uma acusação. É uma afirmação precisa sobre provas em falta. Mantenha-o visível até o fornecedor apresentar provas, a sua equipa testar o comportamento ou o responsável pela decisão aceitar o risco.