Summary

  • O primeiro rascunho público do W3C, em 2015, descreveu a bagunça que um site deixava no navegador: dados espalhados por mecanismos que um script da página não conseguia limpar de uma vez.
  • O rascunho de 2017 deu ao servidor um pedido em formato de cabeçalho, Clear-Site-Data, com escolhas explícitas: cache, cookies, storage, executionContexts e *.

Sair de uma conta parece simples na tela. Nos bastidores, a visita deixa rastros em departamentos diferentes. Um cookie identifica uma sessão. Uma base local ajuda a abrir a página sem rede. O cache conserva arquivos. Outra aba mantém código funcionando. O site pode encerrar a sessão no servidor e ainda deixar o navegador com uma mesa cheia de papéis.

Em agosto de 2015, o W3C publicou o primeiro rascunho de uma ideia de faxina. JavaScript conseguia apagar parte dos dados, mas um cookie HttpOnly foi feito justamente para não ficar ao alcance de scripts. Para eliminá-lo por respostas HTTP, o serviço precisava conhecer os cookies que havia criado e expirá-los corretamente. Cache e armazenamento local exigiam outras rotinas. O botão de sair precisava de uma equipe inteira de limpeza, cada integrante com um molho de chaves diferente.

A solução proposta trocava o endereço do pedido. O site coloca a instrução numa resposta HTTP; o navegador, dono dos compartimentos locais, executa a limpeza. Quem opera o serviço sabe quando encerrar uma sessão ou reagir a uma invasão. Quem guarda as coisas sabe onde cada uma foi parar. Era uma conversa que faltava entre essas duas partes.

O rascunho de novembro de 2017 deu uma lista ao faxineiro. O cabeçalho Clear-Site-Data aceita valores entre aspas: "cookies", "storage", "cache" e "executionContexts". Vários valores podem vir juntos. "*" pede todos os tipos que o mecanismo conhece, inclusive tipos que venham a ser acrescentados. O asterisco é o botão grande; os nomes individuais permitem escolher um pano de chão menor.

Num encerramento comum, o serviço pode pedir a remoção de cookies e armazenamento. A identificação e os dados locais da visita saem juntos. O mesmo texto de 2017 desenha um cenário de emergência: depois de uma invasão, pode ser necessário limpar também o cache e os contextos que continuam executando código. A lista transforma uma decisão de segurança em ações que o navegador pode interpretar. Ela não depende de cada página lembrar onde a visita deixou migalhas.

As gavetas têm territórios distintos. O armazenamento pertence à origem da resposta. Como cookies atravessam subdomínios, o procedimento descrito para eles chega ao domínio registrado. O cache de rede é varrido por host. A resposta que dispara a operação precisa vir de uma conexão segura e autenticada. O navegador aceita um pedido ligado ao site que o enviou; a instrução não vira autorização para vasculhar as gavetas de outro endereço.

Há ainda o funcionário que não recebeu o aviso de saída. Uma aba aberta pode continuar trabalhando com estado antigo. Um worker pode manter atividade depois que o cookie sumiu. Ao incluir "executionContexts", o rascunho manda preparar os contextos afetados e recarregar as páginas depois da limpeza. Limpar o depósito enquanto alguém segue trazendo caixas para dentro seria uma piada ruim; o cabeçalho tenta coordenar as duas pontas.

A faxina radical custa. Apagar cache faz a próxima visita baixar arquivos outra vez. Remover cookies de um domínio registrado pode encerrar sessões em vários subdomínios. Apagar armazenamento pode levar consigo o material que sustentava o trabalho offline. Por isso a lista de tipos é mais interessante que um comando genérico de esquecimento: ela obriga o operador a escolher a escala do ato.

O histórico oficial do W3C registra rascunhos públicos em 2015, 2016 e 2017. Eles capturaram a transformação do navegador em armário de arquivos. Quando a web ganhou memória, sair de uma conta passou a exigir uma ordem de serviço para o armário inteiro.