Resumo

  • O novo Community Group pretende formular princípios para importação e exportação de dados de navegador em um Community Group Report. Seu escopo rejeita um padrão rígido de implementação e diz que o grupo não publicará Specifications.
  • O apoio de cinco pessoas abriu o grupo, mas não demonstra representação do setor. Apoiar, entrar, chegar a consenso, publicar, migrar ao processo de padrões, assumir obrigação legal, adotar e testar interoperabilidade são fatos diferentes.
  • Os fluxos documentados pela Apple e pelo Chrome, além do contexto do DMA, mostram implementação e pressão regulatória reais. Eles não dão ao grupo um mandato jurídico nem provam adesão futura dos fabricantes.

A função já existe em um recorte específico

A documentação do iOS 27 permite exportar do Safari favoritos, histórico, extensões, cartões de crédito e senhas. O resultado é um ZIP não criptografado, que a Apple recomenda apagar depois da importação. A ajuda do Chrome para iPhone e iPad orienta a selecionar esse arquivo, visualizar o conteúdo, resolver conflitos de senhas e importar. Já o BrowserKit oferece uma superfície mediada pelo sistema para histórico, favoritos, lista de leitura e extensões.

Esses são fatos fortes justamente porque têm limites. Identificam sistema, versão, categorias de dados, intervenção do usuário e risco de segurança. Não provam um formato universal, cobertura em todas as direções ou compatibilidade entre todos os navegadores. Também não mostram que Apple, Google ou Chrome ingressaram no novo grupo ou prometeram seguir um relatório futuro.

O mandato público do grupo vem antes da implementação. Ele busca reunir desenvolvedores e implementadores para alcançar consenso sobre as necessidades de usuários que levam dados de um navegador a outro. O resultado pretendido é um relatório com princípios de importação e exportação, para melhorar a consistência entre dispositivos, plataformas e navegadores. Ao mesmo tempo, o texto exclui um padrão rígido de implementação e afirma que o grupo não publicará Specifications.

O limite não diminui o trabalho. Ele define o que o grupo pode legitimamente afirmar agora.

Cinco apoios não formam uma posição da indústria

Tom Fish propôs o grupo em 11 de setembro. Dominique Hazaël-Massieux, Johannes Ernst, Bruce Lawson, Chris Riley e Tom Fish aparecem no anúncio como os cinco apoiadores da criação. Segundo a FAQ do W3C, esse é o limiar necessário para iniciar um Community Group.

O número não significa cinco empresas, cinco navegadores ou cinco implementações. Apoiar a criação não é o mesmo que aderir. Participar em caráter pessoal não é falar por uma organização. Participar não é aprovar um texto. Publicar um texto não é comprometer um produto.

Em 20 de setembro, a página pública mostrava um participante, Tom Fish, e nenhuma presidência. É uma fotografia temporária, não um veredito sobre o futuro. Ainda assim, ela impede que o lançamento seja descrito como uma coalizão madura. Não havia presidência, rascunho de relatório, decisão registrada, modelo versionado ou programa de testes visível.

É necessário ter conta no W3C para entrar, mas não ser membro do W3C. A organização ressalta que hospedar um grupo não representa endosso e que a atividade não expressa necessariamente a opinião de seus membros ou funcionários. Infraestrutura institucional e autoridade institucional não são sinônimos.

Do relatório ao padrão há outro processo

A comparação oficial dos tipos de grupo coloca o Community Group Report fora do standards track. Community Groups não criam padrões W3C. Se o trabalho vier a seguir essa rota, uma Working Group com escopo apropriado terá de recebê-lo em um processo diferente.

Isso deixa uma sequência que não deve ser comprimida: discussão aberta, relatório comunitário, padrão formal, obrigação regulatória, compromisso de fornecedor, implementação de produto e interoperabilidade verificada. Cada estado tem autor, autoridade e prova próprios.

Um relatório comprova o que o grupo publicou naquela versão. Um padrão exige processo normativo. Uma obrigação identifica lei, território, entidade regulada e autoridade. Um compromisso exige declaração verificável do fornecedor. Uma implementação exige versões de produto ou API. A interoperabilidade exige as duas pontas, ambiente, critérios de sucesso e falhas registradas.

O nome W3C não preenche evidências ausentes. No sentido inverso, um botão funcionando não prova que um processo multissetorial aprovou seu desenho.

O DMA é uma fonte de autoridade separada

Em maio de 2026, a Comissão Europeia descreveu a portabilidade de dados de navegadores no iOS e no iPadOS como resultado de dois anos de diálogo regulatório relacionado ao Digital Markets Act. O mecanismo é de aplicativo para aplicativo, mediado pelo sistema operacional e pelo usuário, e cobre categorias como favoritos, histórico, senhas, cartões e extensões. A Comissão afirmou que alguns navegadores de terceiros já importam dados do Safari.

Essa força vem do direito europeu. O artigo 6(9) do DMA impõe obrigações de portabilidade a gatekeepers em um âmbito definido e trata de autorização do usuário, ferramentas gratuitas e, quando aplicável, acesso contínuo e em tempo real. Um relatório comunitário não cria essa obrigação e não pode transformá-la em regra global para todo navegador e plataforma.

A regulação pode provocar uma implementação. A implementação pode alimentar uma discussão. A discussão pode organizar princípios. Há influência entre as camadas, mas não transferência automática de mandato.

Um recibo de autoridade da portabilidade

Cada afirmação relevante do relatório deveria vir acompanhada de um recibo. Ele começaria pelo tipo de resultado, status, versão, URL imutável e data; identificaria autores, apoiadores da criação, participantes atuais, representação organizacional, interesses declarados, presidência e editores; e registraria procedimento decisório, objeções e respostas.

Na parte técnica, o recibo indicaria categoria de dados, exportador, importador, direção, gatilho e limites de dispositivo, sistema, navegador, perfil e conta. Formato, criptografia e retenção são indispensáveis, sobretudo para credenciais e pagamentos. Se houver fundamento legal, seria preciso nomear lei, território, entidade regulada, autoridade e início de vigência. A adoção exigiria o texto da promessa do fornecedor e a versão do relatório. A interoperabilidade exigiria versões de produto ou API, ambiente, critério de sucesso, falhas conhecidas, conflitos, cancelamento e retorno.

Campo não demonstrado deve continuar marcado como desconhecido. A hospedagem pelo W3C, o nome de uma grande empresa ou a presença de uma função parecida não completam o registro.

O recibo não torna o grupo uma certificadora. Ele impede que a frase mude de natureza no caminho. “O grupo quer debater” não vira “o grupo publicou”. “Um produto importa” não vira “o fornecedor adotou o relatório”. “Um par passou no teste” não vira “os navegadores são interoperáveis”.

O melhor sucesso de curto prazo seria um relatório versionado e consciente de seus limites: separar credenciais de favoritos, importação de exportação, mão única de mão dupla, e preparar entregas claras para fabricantes, normalização, reguladores e testes. O grupo já tem um mandato útil — convocar, deliberar e relatar. A precisão sobre o que ainda não existe é parte desse valor.

Fontes