Uma janela do Chrome com vários espaços de trabalho isolados: como isso funciona por dentro
O isolamento em uma única janela são três camadas sobrepostas: sessão e armazenamento, roteamento de rede, ciclo de vida. Não é virtualização do kernel e não muda a impressão digital.
Por que abrir mais janelas não equivale a várias contas conectadas ao mesmo tempo
Comecemos desmontando uma intuição: janela não é unidade de isolamento. Dez janelas no mesmo perfil compartilham um armazenamento de cookies, um localStorage e um cache HTTP, e o site enxerga uma única sessão. O modo anônimo até tem um armazenamento separado, mas existe só um e ele morre com a janela, então não serve para dez contas. A unidade real é o contêiner de sessão: um conjunto próprio de cookies, um espaço de nomes de armazenamento próprio e um mapa de pertencimento estável. O Chrome não tem API de contêiner — a exceção é o contextualIdentities do Firefox —, então a extensão constrói isso na camada de sessão: anota qual aba pertence a qual contêiner e distribui requisições e armazenamento conforme esse mapa. O CrispLogin funciona assim: o contêiner é um registro que a extensão mantém, não uma primitiva do Chrome. A unidade de isolamento é a sessão, não o processo.
Camada um: por que os cookies não se misturam
As contas ficam separadas por um pote de cookies virtual mais a reescrita do cabeçalho de requisição por aba. Cada contêiner guarda dentro da extensão seus próprios registros de cookie. Antes de a requisição sair, uma session rule do declarativeNetRequest casa a aba por condition.tabIds e define o cabeçalho cookie inteiro com o valor daquele contêiner; quando a resposta chega, o webRequest observa o Set-Cookie e grava no pote correspondente. O pote precisa serializar os cookies ordenando por comprimento de caminho e depois por data de criação, senão o cabeçalho não bate com o que o navegador teria enviado.
O que costuma passar batido é a duração: tabIds só funciona em session rules, e as session rules são apagadas ao fechar o navegador e ao atualizar a extensão. Por isso as regras precisam ser reinstaladas a cada início; pular essa etapa produz o sintoma “depois de reiniciar, todos os espaços de trabalho são a mesma conta”. O armazenamento de página é outra face: document.cookie lê o armazenamento real e o localStorage tem um único espaço de nomes, então um script no MAIN world precisa intermediar leituras e gravações por contêiner. Isso é isolamento na camada de aplicação: separa duas contas do mesmo site, mas não toca na impressão digital do kernel.
Camada dois: como o proxy acompanha o espaço de trabalho
O Chrome não tem API de proxy por aba. chrome.proxy.settings vale para o perfil inteiro, e FindProxyForURL(url, host) de um PAC nunca recebe um tabId; o declarativeNetRequest reescreve cabeçalhos e redireciona, mas não tem a ação “escolher um proxy de saída”. O que a extensão consegue fazer é manter um mapa espaço de trabalho → saída e reescrever essa configuração global quando a aba em primeiro plano muda.
O PAC separa por domínio, mas o insumo é a URL, não a aba: o mesmo site aberto em dois espaços de trabalho recebe uma única resposta do PAC. Por isso “dez espaços de trabalho, cada um com seu túnel” não existe em extensão; o que se garante é “o espaço de trabalho que está na frente é o que tem a sua saída”. É também o motivo de aparecer uma reconexão ao trocar de espaço: mudando a configuração de proxy, as conexões já abertas são refeitas. Limite: esta camada troca o IP de saída e o caminho da requisição, não a impressão digital TCP/TLS (JA3/JA4); o WebRTC pode ser restringido com chrome.privacy.network.webRTCIPHandlingPolicy para descartar UDP não proxiado, mas é uma política do navegador inteiro, não por espaço de trabalho.
Camada três: o vínculo sobrevive a fechar a aba ou reiniciar?
O background do MV3 é um service worker: 30 segundos sem evento e ele é encerrado, levando junto variáveis de módulo e qualquer Map dentro de um closure. Então “qual aba pertence a qual espaço de trabalho” não pode morar na memória: vai para chrome.storage.session, que fica na memória enquanto a extensão está carregada e sobrevive à reciclagem do worker, mas é limpo quando o navegador reinicia. Atenção: ele não é exposto a content scripts por padrão; se o lado da página precisa ler o vínculo, é preciso chamar setAccessLevel explicitamente.
Isso divide os dados em dois: vínculos de execução em session, e tudo que precisa sobreviver a um reinício — lista de espaços, configuração de proxy, índice de instantâneos — em storage.local. A cadeia causal é direta: como o vínculo está em session e não em uma variável, depois de acordar a extensão ainda sabe a quem pertence cada aba e não despeja os cookies de um espaço na página de outro. Se ficasse só na memória, assim que o worker dormisse a próxima requisição não teria dono a consultar, e isso aparece como grupos duplicados e instantâneos restaurados no contêiner errado.
Camada quatro: o que um instantâneo de site guarda e o que ele restaura
O instantâneo responde a outra pergunta: portabilidade do estado de login, não isolamento em execução. Está em quarto lugar na lista, mas não faz parte do isolamento em si. Ele serializa os cookies de um site dentro de um contêiner e o armazenamento desse site, e ao restaurar despeja tudo no espaço de nomes daquele contêiner. Os dois são ortogonais: o isolamento impede que dois espaços se atrapalhem enquanto existem; o instantâneo evita ter de entrar de novo. A granularidade é o site, não o navegador: dois sites em um contêiner são dois registros independentes.
Por isso um instantâneo precisa pertencer a um contêiner: despejar o estado de A em B funde duas contas em uma. Igualmente importante é dizer o que ele não faz: restaura estado de sessão da camada de aplicação, não uma impressão digital do kernel, e não promete burlar os controles de risco ou a validação de dispositivo de uma plataforma. Uso: Link interno: uso prático dos instantâneos de site.
Qual é a diferença em relação a abrir vários perfis?
Os perfis múltiplos do Chrome são um corte físico no nível do diretório raiz de armazenamento: cada perfil tem seu próprio armazenamento de cookies, seu armazenamento, suas extensões e seu cache, então o isolamento é completo. O custo aparece em quatro eixos: memória, porque cada perfil tem seu contexto de rede e seus processos de renderização, então três perfis são mais ou menos três vezes o custo residente; processos, porque as árvores são separadas; janelas, porque um perfil é uma janela e trocar significa trocar de janela; impressão digital, porque os perfis compartilham kernel e máquina, e UA, Canvas e fontes são idênticos por padrão. Há um custo mais silencioso: favoritos, extensões e histórico não são compartilhados, e a partir do terceiro perfil cada um começa a divergir.
O caminho da extensão inverte isso: um perfil, uma janela, processos e kernel compartilhados, em troca de paralelismo em janela única com custo incremental quase nulo — e o preço é não alcançar a camada de impressão digital do kernel. Não são dois graus da mesma coisa, são duas formas de cortar a granularidade do isolamento. Comparação: Link interno: perfis do Chrome versus isolamento por extensão.
Limites: quais camadas a extensão cobre e quais não
Os limites vistos até aqui, comprimidos em uma tabela. A leitura é perguntando o que a plataforma verifica: para sessão e saída, a coluna do meio; para consistência de impressão digital, a da direita. Vale repetir: a extensão faz isolamento na camada de sessão, que não é o mesmo grau de um navegador antidetect; tratá-la como um antidetect mais leve é ler o risco errado.
| Camada | O que a extensão cobre | Fora de alcance, ou o preço |
|---|---|---|
| Cookies e estado de login | Separados por contêiner, serializáveis em um instantâneo | O kernel não conhece contêineres; os cabeçalhos são reescritos e, se as regras se perdem, há vazamento |
| Armazenamento de página | localStorage e IndexedDB podem receber prefixo ou proxy por contêiner | Service worker, SharedWorker e outros contextos separados exigem cobertura própria |
| IP de saída | Ligado ao espaço de trabalho; mudar o primeiro plano muda a saída | Uma saída em primeiro plano por vez; sem túneis concorrentes |
| WebRTC | Dá para descartar UDP não proxiado (política do navegador inteiro) | Não é por espaço de trabalho; rotas de mídia ainda podem contornar o proxy |
| Impressão digital TLS | Nada | JA3/JA4 vêm do kernel e da pilha de rede |
| Canvas / WebGL / Audio | Nada | A renderização acontece no kernel; não há API para reescrever |
| Enumeração de fontes | Nada | Só patches de JS na página, e são detectáveis |
| Cache HTTP | Nada | O cache é do perfil e compartilhado entre contêineres |
A tabela também mostra onde está o teto: o que a extensão substitui é o motivo de comprar um cliente só para entrar separadamente, não o cliente. Qual caminho escolher é outra pergunta, comparada ponto a ponto em Link interno: extensão versus navegador antidetect.
Perguntas frequentes
O isolamento de cookies de uma extensão é a mesma coisa que os Partitioned Cookies do Chrome?
Não. Os Partitioned Cookies são indexados pelo site de nível superior, então um site tem um único pote por página de nível superior; o partitionKey na API de cookies é só a chave para ler e gravar esses cookies, e seu único componente é o topLevelSite — não dá para inventar partições novas com ele. O pote de um espaço de trabalho é separado por contêiner, um site pode ter quantos quiser, e a extensão mantém a contabilidade. O primeiro é particionamento de privacidade do navegador; o segundo, uma abstração de sessão da extensão.
O estado do espaço de trabalho continua depois de fechar a aba?
Três casos. A aba sumiu e o vínculo vai com ela. As definições do espaço — nome, proxy, índice de instantâneos — são dados que precisam sobreviver a um reinício e normalmente ficam em storage.local. O estado de login só é recuperável se você salvou um instantâneo; caso contrário, é entrar de novo. O que está em storage.session é limpo ao fechar o navegador, então não trate como armazenamento durável.
A abordagem de janela única afeta o desempenho do navegador?
O incremento vem das abas, não do isolamento. Não se inicia um segundo navegador nem se copia o kernel; o custo é casar regras e reescrever cabeçalhos, uma quantidade constante por requisição. O custo real está no número de abas e nas páginas: com vinte espaços, o que trava é a renderização, não a camada de isolamento.
Dois espaços de trabalho podem usar IPs de saída diferentes ao mesmo tempo?
Não. A configuração de proxy é do perfil e a extensão só consegue reescrevê-la na troca de aba, então a cada instante apenas o espaço em primeiro plano usa a própria saída; os de fundo são bloqueados por regras ou saem direto. Para túneis realmente concorrentes é preciso um cliente com pilha de rede própria.
Fontes e última atualização
Onde este artigo toca comportamento de API, vale a documentação oficial. Os limites de uma extensão mudam com as versões do Chrome — reconfira antes de adotar.
- Chrome for Developers, chrome.declarativeNetRequest — duração das session rules, alcance de condition.tabIds e modifyHeaders no cabeçalho cookie: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — a área session fica na memória, é limpa no reinício do navegador e não é exposta a content scripts por padrão: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey e a semântica de chave dos Partitioned Cookies (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — as configurações de proxy valem para o perfil inteiro do navegador e o PAC recebe apenas URL e host: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — encerramento após 30 segundos ocioso e perda das variáveis globais com o worker: developer.chrome.com/…/service-workers/lifecycle
Última atualização: 11 de novembro de 2026. O texto descreve o caminho de implementação típico dessa classe de extensão; quais APIs e onde cada produto guarda os dados pode variar, e a documentação do produto é que vale para as suas entranhas.