Resumo

  • A IAB compartilha o objetivo de proteger crianças, mas alerta que controles feitos por serviços, intermediários de garantia etária ou redes podem concentrar dados sensíveis, pressionar a criptografia, reduzir privacidade e empurrar jovens para meios de evasão mais arriscados.
  • O texto pede divulgação mínima e específica para a finalidade, ausência de relato de atividade, sinais não correlacionáveis entre sites, desconhecimento do destino pelo emissor, nenhuma base central de dados sensíveis e interfaces abertas e interoperáveis.
  • Mecanismos no aparelho são classificados como promissores, não escolhidos nem comprovados. A própria IAB ressalta a alavanca dos fornecedores de aparelho e sistema operacional e a necessidade de uso robusto por várias pessoas no mesmo dispositivo.
  • A declaração é aconselhamento arquitetural. Não é lei, certificação, ordem de implantação ou padrão IETF. O RFC 9998 é um relatório de workshop cujas posições de participantes não equivalem automaticamente à posição da IAB ou do W3C.
  • A análise de Daniel Kade propõe um comprovante de substituição: resultado, semântica mínima, recurso e privacidade precisam sobreviver à troca de aparelho, navegador, sistema, método de garantia e fornecedor.

A posição do controle vem antes da taxa de acerto

O debate costuma perguntar se o mecanismo classifica corretamente quem está acima ou abaixo de uma idade-limite. É uma pergunta importante, mas não a primeira. Antes de devolver uma resposta, a arquitetura já escolheu quem pode pedir prova, quais elementos podem ser exigidos, onde o resultado fica, quem observa a atividade e quem consegue negar acesso quando há falha.

Quando cada site faz a verificação, ele ou seu contratado vira coletor. Se o bloqueio está na rede, o provedor de acesso precisa identificar o destino e decidir no caminho da comunicação. Se o sinal mora no aparelho, a identidade pode deixar de circular por todos os sites, mas a camada do dispositivo ou do sistema passa a mediar uma condição relevante. São distribuições diferentes de responsabilidade, exposição a vazamento, poder de barganha e capacidade de corrigir erro.

É por isso que a declaração atual da IAB não oferece um protocolo terminado. Ela muda a pergunta de contratação. Em vez de saber qual fornecedor cumpre hoje uma obrigação urgente, procura as propriedades que precisam continuar verdadeiras qualquer que seja a tecnologia.

Cumprir um desafio não é medir segurança

A cópia publicada na lista de anúncios do IETF registra o texto integral e a data de 24 de agosto. A IAB começa reconhecendo a finalidade de proteção infantil. Sua crítica mira sistemas que podem cumprir formalmente uma checagem e, ainda assim, deixar usuários e Internet mais frágeis.

Um serviço externo de garantia etária pode formar um depósito valioso de identidade e elegibilidade. Fazer cada site estabelecer idade amplia os pontos de coleta e normaliza desafios de identidade durante a navegação. Mesmo que a página receba só uma categoria, e não a data de nascimento, permanecem perguntas sobre correlação, retenção de registros, conhecimento do destino pelo emissor e reutilização.

O bloqueio de rede desloca o problema para a infraestrutura. O provedor precisa reconhecer o serviço, definir granularidade e executar uma decisão no caminho. O RFC 7754, citado pela declaração, trata localização do bloqueio, criptografia, dano colateral, transparência e reparação como escolhas arquiteturais, não como pormenores posteriores à conformidade.

Evasão também pertence ao indicador de resultado. Um jovem que troca o acesso direto por uma VPN gratuita desconhecida, uma credencial compartilhada ou fraudulenta ou um aplicativo de mercado cinzento pode escapar do controle e aceitar um intermediário mais perigoso. O número de desafios concluídos e pedidos bloqueados não mede, sozinho, uma melhora de segurança.

Requisitos incompatíveis entre jurisdições acrescentam fragmentação. Quando países reconhecem provas, fornecedores ou locais de aplicação diferentes, um serviço pode abandonar mercados em vez de implementar todas as variantes. A consequência deixa de ser uma divergência abstrata: torna-se serviço ausente, cliente incompatível e caminhos desiguais pela mesma Internet.

Sete propriedades formam uma arquitetura de separação

A IAB enumera sete propriedades. A divulgação deve se limitar a um sinal etário específico para a finalidade. O mecanismo não deve relatar atividade. Os sinais não devem permitir ligação entre sites. Quem estabeleceu a idade não deve descobrir os sites visitados. O projeto não deve criar um repositório central de dados sensíveis, causar outros danos ou encargos significativos a pessoas de qualquer idade, nem depender de uma interface fechada.

Juntas, as propriedades afastam a ideia de um superserviço de identidade. O emissor pode saber o necessário para estabelecer um atributo, sem ganhar um diário de navegação. O site pode saber o necessário para aplicar uma regra, sem receber automaticamente identidade civil. Dois sites não devem transformar respostas em um identificador durável. Transportar uma conclusão não autoriza a mesma entidade a ser emissora, observadora, intérprete da política e porteira universal.

“Mínimo” precisa virar esquema verificável. Uma resposta binária para uma função não autoriza data de nascimento, idade exata, tipo de documento, parentesco ou histórico de verificações. A finalidade deve aparecer nos campos, no ciclo de vida e no comportamento do protocolo; caso contrário, será uma promessa escrita acima de uma carga excessiva.

“Aberta” também exige mais que publicar o código de um cliente. A interface interoperável precisa de semântica comum de pedido e resposta, negociação de versão, falhas definidas, propriedades de privacidade, testes de conformidade e entrada para implementações independentes. Precisa dizer o que o serviço pode inferir e o que emissor, aparelho e intermediário não podem aprender.

Nada disso prova que uma política seja sábia ou eficaz. As propriedades são limites arquiteturais para jurisdições que escolherem uma regra etária. A engenharia pode mostrar os riscos de centralização ou inspeção sem assumir a autoridade de decidir qual conteúdo uma lei deve restringir.

O aparelho preserva dados locais e concentra novas escolhas

Para a IAB, o caminho baseado em dispositivo parece o mais promissor diante da maturidade tecnológica atual. A expressão não significa seleção nem validação. Nenhum protocolo, sistema operacional, navegador, emissor ou fornecedor foi aprovado.

O benefício potencial é claro. Uma pessoa pode estabelecer uma propriedade etária em contexto guardado no aparelho e apresentar depois somente o sinal estreito pedido pelo serviço. O site não recebe a identidade completa, o emissor não acompanha cada destino e verificações repetidas não precisam criar uma trilha central. A troca pode ser mediada pelo equipamento nas mãos do usuário.

Mas o desenho não fica sem controlador. A plataforma pode decidir quais métodos de garantia aceita, como representa papéis domésticos, se um navegador alternativo obtém acesso equivalente, como se recorre de um erro e quais jurisdições entram. Pode alterar a interface ou encerrar uma versão. O serviço decide quanto confia no resultado; o emissor ainda pode excluir quem não possui a prova reconhecida.

Um aparelho compartilhado revela cedo a fragilidade. Um tablet usado por adultos, adolescentes e crianças não tem a idade de uma única pessoa. Se alternar perfis for confuso, impossível ou fácil de contornar, o modelo de privacidade falha no cotidiano. O suporte robusto a vários usuários, citado pela IAB, é requisito de arquitetura e não acabamento do produto.

A interface aberta impede que mediação do aparelho vire soberania do aparelho. Todo dispositivo, sistema ou navegador conforme deve conseguir executar a troca. O site solicita uma condição definida, não a conta, carteira ou cerimônia proprietária de uma plataforma. Num diagrama de API a diferença parece pequena; no mercado, separa concorrência de implementação de vantagem de distribuição.

Workshop, declaração e padrão são estados diferentes

A IAB e o W3C realizaram o workshop em outubro de 2025. A página oficial do AGEWS diz que o encontro examinaria escolhas técnicas e arquiteturais, construiria entendimento compartilhado e não precisava apontar uma solução única. Privacidade, equidade, centralização de mercado, evasão, custo, precisão, jurisdição e censura estavam entre os fatores.

A chamada de trabalhos excluiu a decisão regulatória sobre qual conteúdo restringir. O foco era a interação das restrições com a arquitetura da Internet e da Web. Houve participação por convite, regra de Chatham House modificada e previsão de um relatório.

Esse relatório tornou-se o RFC 9998 em junho de 2026. É um documento Informational do fluxo IAB, não uma especificação da Internet Standards Track. O próprio relatório afirma que as posições descritas pertencem aos participantes, não refletem necessariamente a IAB ou o W3C e não pretendem representar consenso do workshop.

A distinção evita autoridade emprestada. Um workshop pode levantar uma preocupação sem transformá-la em conclusão institucional. A declaração de 24 de agosto é um novo registro porque contém a posição atual da própria IAB. O RFC 9998 dá contexto, mas não promove cada contribuição a essa posição.

O RFC 7841 explica por que fluxo e categoria importam: nem todo RFC se relaciona a padrões, e documentos fora do fluxo IETF não passam pela Last Call de todo o IETF e pela aprovação do IESG. Um registro confiável separa observação de workshop, declaração da IAB, especificação candidata, padrão aprovado, implementação certificada, mandato legal e implantação.

Aconselhamento arquitetural não legisla acesso

O RFC 2850 define a IAB como comitê do IETF e órgão consultivo da Internet Society, com supervisão arquitetural de longo prazo, acompanhamento e recursos do processo de padrões, ligação e aconselhamento. O RFC 9281 conserva a separação: a IAB fornece orientação técnica, arquitetural, processual e de política, mas não é legislador nacional nem regulador do dever de um serviço.

O limite não esvazia a declaração. Aconselhar antes que a dependência endureça pode alterar uma decisão. A IAB pode mostrar como um mandato tecnológico pressiona criptografia ou centraliza identidade sem reivindicar o poder de editar a lei. O regulador define o resultado público e responde por legitimidade, escopo, recurso e eficácia. O processo de padrões define uma interface. Fornecedores implementam. Serviços aplicam a regra lícita. Usuários contestam erros.

Cada ato pede recibo próprio. A declaração prova uma posição arquitetural. Um documento de padrão prova um estado da especificação. A certificação prova testes definidos. A lei prova promulgação numa jurisdição. Dados de produção provam operação sob condições medidas. Um selo não substitui os demais.

O RFC 3935 acrescenta que padrões IETF descrevem como fazer algo quando alguém alega conformidade; não ordenam nem policiam seu uso. Um futuro padrão de sinal etário não criaria sozinho autoridade legal, acerto político ou sucesso de implantação.

Um comprovante de substituição torna a abertura verificável

A IAB chama de ossificação a dificuldade de deslocar um sistema depois que dependências e incentivos econômicos se espalham. Mandatos voltados ao resultado e interfaces interoperáveis deveriam manter espaço para soluções melhores. Isso só vira prática quando a substituição é demonstrada.

O comprovante proposto por Daniel Kade tem cinco partes. Primeiro, o resultado é descrito fora do fornecedor: usuários, serviços e jurisdição abrangidos, decisão de acesso, benefício de segurança esperado, erros tolerados e recurso. “Usar o fornecedor X” não é resultado.

Segundo, registra-se a impressão do contrato do sinal: campos mínimos, semântica do limiar, contexto de vinculação, validade, proteção contra repetição, não correlação, versão e estados de falha. O sucessor implementa o mesmo contrato público sem copiar uma base privada de identidade.

Terceiro, prova-se diversidade. Pelo menos duas implementações sob controle independente devem produzir ou transportar o sinal conforme. Um serviço não deve precisar de uma integração proprietária por opção, nem a alternativa perder reconhecimento por não possuir a conta do incumbente.

Quarto, ensaia-se a migração. Trocam-se separadamente fornecedor de garantia, aparelho e navegador. Observa-se se a divulgação cresce, se o estado familiar continua seguro, se o serviço interpreta a resposta, se o recurso permanece e se antigos identificadores deixam de funcionar. Sintaxe que só opera até a primeira troca não é interoperabilidade.

Quinto, define-se gatilho de revisão. Rejeição indevida elevada, concentração de vazamentos, exclusão discriminatória, falta de efeito de segurança, pressão sobre criptografia, retirada de serviços ou concentração de fornecedores reabrem a escolha. Rever o mecanismo não abandona a proteção infantil; preserva a capacidade de alcançar o mesmo fim com menos dano.

Passar pelo comprovante não prova segurança de todos, consenso entre países ou fim da evasão. Prova algo mais estreito e decisivo: o resultado público não ficou refém de um controlador técnico.

Fontes

  1. IETF Datatracker: declaração da IAB sobre restrições etárias e segurança on-line
  2. Cópia da declaração na lista de anúncios do IETF
  3. Índice de anúncios da IAB
  4. Registro de declarações da IAB no Datatracker
  5. RFC 9998: relatório do workshop IAB/W3C
  6. Página de estado do RFC 9998
  7. Anúncio da IAB sobre o RFC 9998
  8. Registro oficial do workshop AGEWS
  9. Chamada de trabalhos do AGEWS
  10. RFC 7754: considerações técnicas sobre bloqueio e filtragem
  11. Página de estado do RFC 7754
  12. RFC 2850: carta da Internet Architecture Board
  13. RFC 9281: entidades do processo de padrões IETF
  14. RFC 3935: declaração de missão do IETF
  15. RFC 7841: fluxos, cabeçalhos e textos-padrão dos RFCs