Modelo de ameaça do Chrome assume renderer comprometido. Sua pilha defense-in-depth — de sandbox a atualizações automáticas — torna cadeias de exploit caras e frágeis para atacantes.
Cada origem (scheme + eTLD+1) ganha processo renderer dedicado com política seccomp-BPF restritiva (Linux), AppContainer (Windows) ou Seatbelt (macOS). Sem syscalls diretos, sem filesystem, sem GPU — apenas IPC Mojo para processo browser privilegiado.
Omnibox padrão para https://; lista HSTS preload embutida. Mixed-content autoupgrade e bloqueio. Certificate Transparency enforcement via logs CT.
Modelo ML on-device pontua features DOM (logos de marca, campos senha em domínios lookalike, typosquatting). Interstitial de aviso antes do commit.
Chrome pede security key (FIDO2/WebAuthn) ou Google Prompt ao logar em contas Google; suporta login apenas passkey.
NPAPI removido desde Chrome 45. Flash EOL 2020. Applets Java não suportados. Sem superfície de plugin = redução massiva de superfície de ataque.
chrome://flags/#dns-over-https padrão "Automático" (DoH oportunístico para Cloudflare, Google, NextDNS, etc.). Políticas enterprise podem forçar DoT para resolver on-prem.
Ciclo Stable de 4 semanas; patches de segurança backportados em 24–48 hrs após fix upstream. Atualizador em background (Omaha) instala silenciosamente; badge de reinício aparece.
Admins gerenciam via Chrome Browser Cloud Management ou Group Policy: URLBlocklist, ExtensionInstallForcelist, SafeBrowsingProtectionLevel, DNSInterceptionChecksEnabled, etc.
Nenhuma feature única torna Chrome seguro; a composição de sandbox, isolamento de site, transporte criptografado e patching rápido eleva custo de exploit além do ROI da maioria dos threat actors.
Tecnologia Eletrônica © [www.351231.com]